AI Identity
An AI Identity is the governed identity of an AI agent, model or assistant, making it possible to know who acts, on whose behalf, on which resource and within which limits.
- Synonym
- AI agent identity
Definition
An AI Identity is the identity representation assigned to an AI agent, a model-driven assistant or an autonomous software component, so that its actions can be attributed, constrained, traced and governed. It is more than a directory record: an agent acts, calls tools, reads data and triggers real effects. The useful question is therefore not only “does this agent exist?” but “is this specific action, in this specific context, allowed?”.
Why it matters
An AI agent chains actions at a speed and volume no human matches. Without a governed identity, its access cannot be attributed, its permissions accumulate and an incident can no longer be reconstructed. AI identity is what makes autonomy acceptable in an enterprise.
Beyond inventory: governing AI identity at runtime
Listing agents is a first step, necessary but not sufficient. An AI agent does not behave like a fixed application: it composes actions, calls tools, sometimes acts on behalf of a user and sometimes on its own account. Two runs of the same agent can target very different resources.
Useful governance therefore happens at the moment of the action. It means deciding, request by request, whether the requested action is allowed given the agent, the delegated user, the target resource, its sensitivity and the execution context. That control relies on externalised policies, evaluated by a decision point (PDP) and applied by an enforcement point (PEP) placed in front of the API or the tool.
The suitable authorization models are those that can take attributes and context into account: ABAC, PBAC and hybrid policies. ReBAC remains relevant when the decision genuinely depends on a graph of relationships, for example document sharing, but on its own it does not frame an agent whose scope changes with every request.
- AI identity
Registered agent, known owner, defined lifecycle
- Authentication
Proof of the agent's identity, controlled credentials
- Authorization policy
ABAC, PBAC or hybrid rules, written outside the code
- PDP
Decision taken at the moment of the action, with context
- Allow / Deny
Permit, deny or an attached obligation
- PEP — API, tool, resource
The resource is reached only after the decision
- Behaviour observation
Usable traces, detectable drift
An AI agent is not governed only when it is created: the useful decision happens at the moment of the action.
Agentic IAM
Agentic IAM applies IAM principles to autonomous agents: giving them their own identity, verifiable authentication, authorization policies evaluated at the moment of the action, and continuous observation of their behaviour. It is the logical extension of non-human identity management to components that take initiative.
The three properties of a governed AI identity
Attribution: every action of the agent can be traced back to an accountable human or application owner. An agent that runs under a shared, anonymous service account breaks this property, because an incident can no longer be attributed to whoever is responsible for it.
A bounded lifecycle: the identity and its credentials are time-limited. Tokens expire, access is reviewed and the agent is retired when it no longer has a reason to exist, instead of accumulating permanent permissions.
Accountable traceability: a reliable, timestamped audit trail makes it possible to reconstruct after the fact who did what, on which resource and in which context. These three properties are design requirements for the identity itself; they complement the control layers described above.
The four governance layers of an AI identity
A controlled AI identity rests on four complementary layers: none replaces the others.
- 01Identity governance (IGA)
Register the agent, assign an owner, define its lifecycle, review its rights and retire it once it no longer has a reason to exist.
- 02Access management
Authenticate the agent with controlled credentials, and clearly separate what it does for itself from what it does on behalf of a delegated user.
- 03Fine-grained authorization
Evaluate each action with its context: the policy is held by a PDP and applied by a PEP in front of the API or tool being called.
- 04Runtime security
Observe the agent's real behaviour, trace actions end to end and detect drift in volume, scope or usage.
The Ariovis perspective
An AI agent is not a slightly faster user: it is an identity that acts continuously. We believe an agent should never depend on a shared service account, nor carry its access rules inside its own code. It needs its own identity, externalised policies evaluated at the moment of the action, and observation of its real behaviour. That combination, not the inventory alone, is what makes autonomy governable.
Agentic IAM Governance Framework
AI Identity describes the governed identity assigned to an agent. Agentic IAM describes the mechanisms that govern and control that identity before and while it acts. An AI agent does not merely need an account: it needs a governed identity, a defined mandate and controls over the actions it can actually perform.
- 01
Give the agent a governed identity
Give every agent an explicit identity with a business or technical owner, a stated purpose, a criticality level, a bounded lifecycle, a review date and associated access. This makes the agent part of non-human identity governance rather than leaving it behind a generic service account.
- 02
Control authentication and credentials
Keep secrets, tokens and credentials outside prompts and the agent's autonomous logic, with issuance, storage, rotation and revocation controlled independently. Authentication answers “who is acting?”; it does not yet answer “is this particular action allowed?”.
- 03
Define the agent's mandate, not only its role
An application role can be correctly governed and still grant much more power than the mission entrusted to an agent. Its mandate should make the operational boundary explicit rather than treating every capability attached to the role as usable.
- Resource
- Action
- Tool
- API or MCP server
- Parameters
- Destination
- Purpose
- 04
Make authorization decisions at runtime
Autonomous agents can choose several paths to reach the same goal. When the context justifies it, a runtime decision should evaluate the identity, resource, action, context, risk, data sensitivity and the tool or parameter involved. A Policy Decision Point evaluates the policy; a Policy Enforcement Point applies that decision where the action reaches the API, tool or MCP server.
- 05
Measure and contain the blast radius
The security question is no longer only “can the agent access the system?” but also “what is the most powerful action this agent can actually perform?”. Least privilege, limited scopes, temporary privileges where relevant, fine-grained authorization and runtime controls reduce that power. Auditability, revocation and containment make its use reviewable and interruptible.
- Least privilege
- Limited scopes
- Temporary privileges
- Runtime controls
- Auditability
- Revocation and containment
- Identity Governance
- Legitimacy and lifecycle
- Authentication
- Proof of identity
- Secrets / PAM
- Credential and privilege control
- Runtime Authorization
- Decision on a precise action
- Enforcement
- Application of the decision
- Audit / visibility
- Evidence, review and containment
Common pitfalls
- Running AI agents under generic service accounts, with no owner and no individual attribution.
- Stopping at an inventory of agents and assuming governance is done, while nothing controls the action at the moment it is requested.
- Encoding access rules in prompts or in the agent code, which makes decisions invisible, unauditable and impossible to evolve.
- Treating agent authorization like that of a classic application, when its scope of action changes from one request to the next.
Resources
- Secure AI agents: identities, mandates and actionsAn operational use case for governing identities, mandates and actions.
- An administrator role is not a security policy for an AI agentWhy an agent's effective mandate must be narrower than a broad application role.
- Agentic IAM Runtime Architecture BlueprintA runtime architecture connecting identity, context, policy, enforcement and audit.
- Ariovis × AxiomaticsPolicy-based authorization and runtime decision-making in a coherent IAM architecture.
Going further
- ReBAC or PBAC: which authorization model?How to choose between a relationship graph and contextual policies.
- Externalising the authorization decisionMove access rules out of application code to make them auditable.
- Hermes in the enterpriseAn enterprise agent, its tools, and where the decision must be taken.
- AxiomaticsOur partner for dynamic, policy-based authorization.
Explore this category
These concepts matter most inside a real project.
The first conversation helps establish your context, the systems involved and the next useful decision.