Runtime authorizationTechnology partner — fine-grained, dynamic authorization
Holding a right is not enough
to know whether the action should be allowed.
An identity governance platform knows who holds which right. An access management platform knows who just authenticated. Neither can decide, at the exact moment of an action, whether that action should really happen in this context.
That gap, observed on our own engagements, led us to fine-grained dynamic authorization — and then to Axiomatics, after several months of study and hands-on testing.
- A conviction page, not a product brochure.
- Our position stays independent: not every system needs an external authorization engine.
The starting point: a structural limit of classic IAM
An IGA platform governs the legitimacy of a right very well: who holds it, why it was granted, for how long, who approved it, and how it must be reviewed.
An access management platform secures the entry point very well: it authenticates the user, protects the journey and enforces access policies to applications.
But some decisions can only reasonably be made at the exact moment the action is executed — because they depend on the specific resource, the situation and the context, not only on the requester's profile.
Questions a role cannot settle on its own
Each of these questions relies on information that only exists at the moment of the action.
- Can this doctor open THIS patient record, right now?
- Can this banking advisor view THIS client, when a personal connection exists between them?
- Can this application use THIS data in THIS context?
- Can this user perform THIS action from THIS environment?
- Is this AI agent allowed to call THIS tool, with THIS data, for THIS purpose?
The question is no longer just "does the requester have the role?" but "in this specific context, should this specific action really be allowed?".
That is precisely the territory of fine-grained, dynamic authorization.
RBAC is essential. It simply cannot express everything.
We design, teach and implement role models. RBAC remains the best tool to structure and govern a very large volume of entitlements, and it will stay that way.
Our conviction is more nuanced: RBAC organizes rights very well, but some use cases need more context before a decision can be made correctly.
RBAC
Deciding through roles
The decision mainly relies on role membership. Readable, governable, auditable — and sufficient for most entitlements in an organization.
RBAC in the glossaryABAC
Adding attributes and context
The decision takes into account attributes of the requester, the resource, the action and the environment.
ABAC in the glossaryReBAC
Understanding relationships
Some decisions depend on how people and objects are connected: owner, manager, delegate, membership.
ReBAC in the glossaryPolicy-based
Making the rule explicit
The business and security rule becomes an explicit, centralized policy instead of conditions scattered across application code.
PBAC in the glossary
"Advisors may view client records."
"… unless the advisor has a personal relationship with this client, except where explicitly authorized."
The first sentence is a role. The second is a contextual policy: it involves a relationship, an exception and a decision taken at the moment of access. This is the type of scenario Axiomatics documents publicly to illustrate the shift from role-driven logic to attribute-enriched logic.
The point is not to stack acronyms, but to recognize the limit: the moment a decision no longer fits inside a role.
An interesting technology is not enough to make a partner.
We did not add an "Authorization" box to our catalogue. The path was longer, and that is what gives the partnership its value.
The revelation
In ten years of IAM, I had never truly understood what vendors were telling me about authorization. When it finally clicked, it was a revelation — and that revelation set everything that followed in motion, all the way to this partnership.
— Matthieu Filizzola, Founder Market analysis
It was while studying Gartner's analyses on the evolution of IAM and authorization that we started looking closely at Axiomatics.
Study
We analyzed the technology, audited the approach, and examined the authorization models and how they fit into existing architectures.
Testing
We tested the platform for several months: policies, attribute sources, enforcement points, and how decisions actually behave.
Challenge
We confronted the use cases with our own IAM engagements, to separate what genuinely belongs to runtime authorization from what is better handled elsewhere.
Meeting the people
We met their teams, talked at length, had dinner together, and compared our views on the market and the future of IAM.
Strategic alignment
We had validated the technology. What remained was whether we wanted to build with the people behind it, and whether their strategy matched ours. It did.
Partnership
Today the relationship goes beyond a logo: regular exchanges, joint talks and appearances, and a shared reading of where authorization is heading.
We wanted to understand what they were building, why they were building it, and where they believed IAM was going.
What we liked about their strategy
Axiomatics stands for fine-grained, policy-based, dynamic, externalized and context-aware authorization across applications, APIs, microservices and data. The company presents itself as the originator of a runtime approach to fine-grained authorization, largely grounded in ABAC.
Its "Orchestrated Authorization" strategy aims to separate and centralize decision logic instead of letting every application reimplement its own rules. That is exactly the point that resonates with us.
Our conviction: critical authorization rules should not be scattered as hundreds of opaque conditions across applications, APIs, microservices, scripts and business developments.
Govern entitlements
Decide who should legitimately hold what, and why.
Authenticate
Reliably establish who is acting.
Decide authorization
Evaluate, at the moment of the action, whether it should be allowed in this context.
Enforce the decision
Apply that decision where the action actually happens.
What this separation makes possible
- More consistency across applications
- Centralized policies instead of duplicated ones
- More controllable rule changes
- Genuinely context-aware decisions
- Better auditability
- The ability to explain why an action was allowed or denied
This does not mean an externalized architecture is required everywhere: for many systems, classic mechanisms remain perfectly appropriate. We recommend this approach when business complexity, resource sensitivity or the dynamic nature of the decision justify it.
Four layers, four different questions
These building blocks do not replace one another: they answer distinct questions, and the architecture lies in how they connect.
01
Governance
IGA — for example Netwrix Identity Manager
Who should have which rights?
Granting, justification, duration, review and lifecycle of entitlements.
Identity Governance services02
Authentication and access
Access Management — Ping Identity, Entra ID depending on the architecture
Who is signing in?
Authentication journeys, SSO, federation, MFA, application access policies.
Access Management & CIAM services03
Runtime authorization
Axiomatics
Should this specific action be allowed in this specific context?
Policy evaluation at request time, based on attributes, relationships and context signals.
Fine-grained Authorization services04
Enforcement
Application, API gateway, microservice, data layer (PEP)
Where is the decision actually applied?
The point where a decision becomes a real effect: allow, deny, filter, mask.
One request, one policy, one decision
Without diving into any XACML dialect: conceptually, the mechanism holds in three steps.
- WHOWhoThe identity acting — human or not — and its attributes.
- WHATWhatThe targeted resource and its own characteristics.
- ACTIONActionThe requested operation: read, edit, export, execute.
- CONTEXTContextEnvironment, timing, channel, relationships, risk signals.
- PURPOSEPurposeWhy the action is requested, when that information is available.
The decision point (PDP)
The policy evaluates these elements. Axiomatics can consume signals from various sources — identity systems, security solutions and organization-specific attributes — to evaluate the rule against the context.
- PermitThe action is allowed in this context.
- DenyThe action is refused, with the corresponding traceability.
- + enforcement detailsDepending on the architecture, the decision can carry the information the enforcement point (PEP) needs: filtering, scope, masking.
PDP: policy decision point. PEP: policy enforcement point. Two distinct roles — deciding is not enforcing.
Going a little deeper: ALFA
Axiomatics is closely associated with ALFA — Abbreviated Language for Authorization — a language designed to express authorization policies far more readably than raw XACML XML.
This detail matters: a readable policy can be reviewed, discussed with the business, governed and maintained. It is a practical condition of auditability.
- Attribute-based policies
- Relationship-aware logic
- Hierarchical structures
- Combination and precedence mechanisms
Authorization is no longer only about users
Information systems are no longer populated only by people. Applications, services, workloads, APIs, machines and AI agents also request access to data, tools and business actions.
For an AI agent, being properly authenticated says nothing about what it should be allowed to do. The question becomes: what can this agent do, on which resources, in which context, with which data and for which purpose?
- humans
- applications
- services
- workloads
- APIs
- machines
- AI agents
This is why we see runtime authorization as a particularly relevant component of agentic architectures. Axiomatics publishes on AI, LLM and agent topics — but remains first and foremost an authorization platform: AI is a use case, not the definition.
A relationship that lives somewhere other than a logo wall
The exchanges continued well past the evaluation phase: we talk regularly with their teams, we speak at events together, and we share our reading of how IAM and authorization are evolving.
The photo was taken at the European Identity and Cloud Conference 2025 in Berlin — the kind of moment where a technology relationship turns into actual joint work.
- Several months studying, auditing and testing the platform
- In-depth exchanges with their technology and strategy teams
- Joint talks and speaking engagements
- Axiomatics present in our authorization architectures and services
We prefer an honest page to a wall of customer logos: we publish no Axiomatics reference that has not been explicitly confirmed by the customer concerned.
Since 2025, Axiomatics is a Leonardo company
Leonardo announced the acquisition of Axiomatics in 2025, and the company now appears as "a Leonardo company". The move was presented around Zero Trust, fine-grained dynamic authorization, critical environments and trusted cybersecurity.
For a European player like Ariovis, that is a relevant piece of context. We draw no conclusions beyond what has been publicly announced.
What Ariovis brings, beyond the tool
A good authorization policy does not start by writing ALFA code. It starts by understanding the business, the resource, the identities, the rules, the risks and the exceptions.
Before the technology
- Identify the decisions that are genuinely complex
- Map the existing rules
- Separate what belongs to roles, attributes, relationships or context
- Decide what stays in the application and what deserves to be externalized
- Identify attribute sources
- Define policy governance
Design and build
- Design the authorization architecture
- Identify enforcement points
- Build the policies
- Integrate the decision engine
- Connect context sources
- Integrate PEPs and test decisions
Sustain and transfer
- Document policies and their rationale
- Organize their maintenance and lifecycle
- Support developers, architects, security and business teams
- Train teams on access models
Our advisory position
Not everything deserves an authorization engine.
Externalizing a simple, stable rule owned by a single application does not necessarily create value — it adds a dependency and operational complexity.
Technology must stay proportionate to the problem. That is a core Ariovis conviction, including when it leads us not to propose an authorization engine.
Fine-grained authorization becomes genuinely valuable when
- Rules are numerous
- Context changes the decision
- Several applications must enforce the same policy
- Data is sensitive
- Business rules evolve frequently
- Access depends on relationships between people or objects
- Decisions must be explainable
- Agents or autonomous systems reach powerful tools
If none of these criteria apply, we say so — and we stay with the mechanisms already in place.
Frequently asked questions
Does ABAC replace RBAC?
No. RBAC remains the best way to structure and govern a large volume of entitlements, and we keep designing and teaching it. ABAC, ReBAC and contextual policies complement the role model where the decision depends on attributes, relationships or circumstances a role cannot carry.
What is the difference between identity governance and runtime authorization?
Identity governance decides the legitimacy of a right: who should hold it, why, for how long, and how it is reviewed. Runtime authorization decides how that right is actually used at the exact moment of an action, based on context. They complement each other and do not overlap.
Are runtime authorization and authentication the same thing?
No. Authentication establishes who is acting; authorization determines whether the requested action should be allowed. A perfectly authenticated user or agent can legitimately be denied a specific action in a specific context.
How did Ariovis choose Axiomatics?
Studying Gartner's analyses on the evolution of IAM and authorization is what led us to look at Axiomatics. We then studied the technology, audited the approach and tested the platform for several months, before long discussions with their teams about their strategy. The partnership came at the end of that path, not before.
Should every authorization rule be externalized?
No, and we advise against it. For many systems, classic mechanisms remain perfectly appropriate. Externalization becomes valuable when business complexity, resource sensitivity, the number of applications involved or the dynamic nature of the decision justify it.
Is Axiomatics an AI agent security product?
No. Axiomatics is a fine-grained, dynamic authorization platform for applications, APIs, microservices and data. Securing AI usage and agents is a particularly interesting use case, publicly addressed by the vendor, but it is not the definition of the product.
An access decision does not always fit inside a role.
When your role model starts carrying exceptions, conditions and special cases, it usually means part of your rules now belongs to contextual authorization. Let's talk about your context — including whether an authorization engine is unnecessary.