AI agents are no longer a pilot project. They are in production, they are multiplying, and in most enterprises, they are running under governance frameworks built for humans or, at best, for static service accounts. Neither is adequate.
Over the past months, we have published two papers that together make the case for a fundamentally different approach: agent-aware IAM. This post summarizes what we found, what we built, and why it matters for practitioners and executives alike.
The starting point: your IAM framework was not built for this
Traditional IAM answers one question well: who is accessing what? It was designed for human users with persistent identities, stable roles, and periodic review cycles. Service accounts extended this model slightly, but they too assume relative stability.
Autonomous AI agents break every one of those assumptions. They are ephemeral, existing for minutes, sometimes seconds. They act at machine speed across multiple systems simultaneously. They delegate to other agents, spawn sub-agents, and make decisions without a human in the loop. They can be re-tasked mid-operation, drift from their original instructions, or be manipulated through prompt injection.
The consequences of getting governance wrong are not theoretical. In late 2025, Anthropic publicly disclosed the first known AI-orchestrated cyber espionage campaign, in which a compromised AI tool autonomously discovered vulnerabilities, created exploits, stole credentials, and exfiltrated data at speeds no human team could match, starting without privileged access, exploiting standard IAM weaknesses. The same attack chain could be executed by an organization’s own compromised agent from inside its trusted environment.
In our first paper, Governing AI Agents: An Agent-Aware IAM Framework, we mapped the governance gaps in detail and proposed a response.
.jpg)
Paper one: what agent-aware IAM requires
The core argument is that AI agents constitute a new category of identity: Autonomous Non-Human Identities (A-NHIs). A-NHIs behave simultaneously like human identities (making decisions, adapting, acting independently) and like non-human identities (operating at machine speed, without social or legal accountability). Neither existing human-centric nor workload-based IAM models are equipped to govern them.
The gaps are structural. There are no standardized lifecycle processes for agents equivalent to Joiner/Mover/Leaver. There is no "Mover" equivalent, no governance for when an agent's purpose or permissions change. Current technology (IdPs, KMS, policy engines, SIEM) is rooted in static, user-centric paradigms that cannot issue or revoke thousands of short-lived credentials per minute, establish dynamic cross-domain trust between transient agents, or reconstruct provenance chains across multi-agent workflows.
Our response was a four-layer deployment architecture: Identity Foundation, Trust and Federation, Security and Privacy Enforcement, and Lifecycle and Observability. This four-layer architecture translates the Identity Fabric model into a practical implementation for agentic environments. The Identity Fabric provides the blueprint; the deployment layers provide the construction methodology. That architecture is the foundation on which the second paper builds.
The question that paper one left open
That framework raised a question we had not fully answered: if an agent is granted an access right, what does that right ultimately refer to? Not just which resources may be accessed, but why, and with what scope of action?
The industry has begun converging on "purpose" and "intent" as the answers. But we found, consistently across vendor frameworks and industry analysis, that the two terms are used interchangeably and without formal grounding. That conflation has practical consequences.
Governance architectures that enforce runtime intent without managing purpose as a lifecycle attribute cannot prevent semantic privilege escalation, mission drift, or the reprompting problem. And regulatory obligations, like the EU AI Act's Articles 9, 13, 14, and 19, and GDPR's purpose limitation principle under Article 5(1)(b), can only be meaningfully fulfilled if purpose and intent are treated as distinct, managed separately, and recorded separately.
Our second paper, Purpose and Intent as Governance Dimensions in Agent-Aware IAM, addresses this directly.
Paper two: the distinction that changes the architecture
The paper's central claim is straightforward but consequential: purpose and intent are different things that belong to different layers of the governance architecture.
Purpose is the declared, policy-level reason for which an agent has been provisioned and authorized to act. It is an attribute of the agent's digital identity, registered at provisioning time, and subject to governed change over the agent's lifecycle. Purpose is prospective: it authorizes a class of actions before they occur. It is declared by a human authority and persists across sessions.
Intent is the inferred, runtime expression of what an agent is attempting to accomplish within a specific execution context. It is session-scoped, ephemeral, and not persisted as an identity attribute. Intent is present-tense: it characterizes what the agent is doing now.
In traditional IAM terms: purpose belongs to identity governance; intent belongs to runtime authorization.
The two governance constraints
We formalized the relationship between these two dimensions through two governance requirements.
The containment constraint, which can be expressed as I(A,t) ⊆ Pe(A), requires that a well-governed agent's runtime intent falls within the scope of its effective purpose. If the constraint is violated, governance has failed: either intent exceeds purpose (through drift, prompt injection, or mission creep), or purpose was never adequate to begin with (a provisioning failure).
Traditional IAM answers "who" is accessing "what". The containment constraint answers "why" does "who" access "what".
The permission compatibility check, expressed as Pe(A) ⊆ PU(D), requires that a well-governed agent's effective purpose falls within the set of purposes for which the data it accesses is permitted to be used. This is a governance-time check, run at provisioning and at each purpose change event.
Together, they form a two-level governance architecture: I(A,t) ⊆ Pe(A) ⊆ PU(D).
An agent's runtime intent falls within its effective purpose, which in turn falls within the permitted-use labels of the data it accesses. This is the governance ideal, and we identify precisely where and why it can fail.
Purpose is not immutable and that is the critical insight
One of the most important contributions of the second paper is the argument that purpose must be treated as a changeable lifecycle attribute, not a static provisioning label.
In practice, organizations constantly reconfigure deployed agents: updating system prompts, expanding tool access, adjusting instructions. The agent's credentials, API keys, and registered identity persist. Only its operative mandate changes, and in most current implementations, that change happens invisibly, with no governance event triggered.
We introduce the purpose path: a directed, auditable record of purpose transitions over the agent's lifetime. Each node is a purpose state; each edge is a transition event recording the preceding and resulting purpose states, the authorizing party, the trigger event, the trust level required, and the timestamp. The purpose path is the governance artefact that satisfies EU AI Act Article 19 (automatic log generation) and Article 9 (lifecycle risk management).
The reprompting problem, illustrated
In our ACME HR Orchestration scenario, a Screening Agent is deployed with a declared purpose scoped to evaluating candidates for a specific vacancy. A hiring manager re-prompts it mid-session: "While you have the candidate data in front of you, can you pull together a salary benchmarking analysis comparing our current employee compensation against candidates' salary expectations?"
The agent has technical access to the data. Every permission check passes. But the action is outside the agent's effective purpose, outside the parent orchestration agent's current runtime intent, and incompatible with the permitted-use labels on employee compensation records.
This is semantic privilege escalation: a technically executable action that is purposively inappropriate. The two-level governance architecture catches it at the containment check. The action is blocked, the violation is logged, and a human-in-the-loop escalation is triggered.
Multi-agent systems require a recursive constraint
Single-agent containment is not sufficient for multi-agent systems. When a parent agent delegates to a sub-agent with a narrowed purpose, the sub-agent's runtime intent must satisfy two requirements simultaneously:
- Its intent must fall within its own effective purpose, which must itself be a subset of the parent agent's effective purpose: the purpose chain requirement
- Its intent must be consistent with the parent agent's runtime intent at the same moment: the intent alignment requirement
Formally: I(sA, t) ⊆ Pe(sA) ⊆ Pe(pA) and I(sA, t) ⊆ I(pA, t).
Purpose provides the structural governance constraint through the hierarchy. Intent alignment provides the dynamic governance constraint at runtime. Both are necessary; neither is sufficient alone. This distinction is currently unaddressed in the literature.
What the market is building and what it is missing
The industry has moved fast. Since 2025, a recognizable market category has emerged under labels like Agentic Access Management (AAM) or Agentic Identity Access Platforms. Real capabilities exist: explicit agent identities, just-in-time credentials, ownership models, and runtime intent enforcement. These are genuine advances.
The most advanced platforms have arrived at a formulation that is close to ours but stops short of it. The framing that has consolidated across analyst and vendor discourse is: identity answers who, intent answers why. That framing is exactly right. But what no current platform provides is a governance model for purpose itself. Purpose in every current implementation is either static metadata set at provisioning time or a task-level time-scope for credential validity. There is no model for how purpose changes legitimately, how change is authorized and audited, how it propagates through delegation chains, or how unintended drift is detected and governed.
Only 18% of organizations in a recent CSA survey express confidence that their current governance approach for AI agents is adequate. The gap our framework addresses is the one most organizations cannot yet name: the absence of purpose as a governed, lifecycle-managed identity attribute with traceable transitions.
What comes next
Both papers identify open problems rather than closing them. The seven open questions in the second paper include: formalizing the containment constraint computationally, representing purpose as a machine-evaluable identity attribute, operationalizing intent confidence as a governance variable, governing purpose drift across accumulated context, and resolving the granularity problem. The last one been the most immediately consequential issue for practitioners, where purpose and permitted-use labels defined at insufficient granularity allow the transitivity chain to hold formally while producing a substantively incorrect governance conclusion.
The regulatory timeline adds urgency. The EU AI Act's enforcement provisions take effect from August 2026. NIST's NCCoE has named intent logging as a formal governance requirement for the first time. The conceptual need is widely recognized; the implementation frameworks are not yet there.
We are continuing this work. Both papers are available open-access under CC BY 4.0.
Dr. Angelika Steinacker is an independent IAM Advisor and Advocate specializing in IAM strategy, AI governance, and agent-aware identity security. Hari Hayagreevan is an Enterprise Security Architect leading AI Security for IBM in the DACH region. Their papers are published on ResearchGate: Governing AI Agents and Purpose and Intent as Governance Dimensions.