AI Agent Identity Framework: Standards, Reference Architectures, and How They Map Together

AI agents are no longer mere assistants; they now make decisions, take actions, and operate independently. And this explosion is accelerating: non-human identities outnumber human identities 17 to 1 in the average enterprise, and that ratio is growing by 44% per year. The question then arises: how do we know what these agents are, and what they are allowed to do? This is where an AI Agent Identity Framework comes in handy, providing identity, permissions, and an auditable trail for every agent, analogous to identity management solutions for humans. The purpose of this post is to explore what such an AI Agent Identity Framework would look like.

In early 2026, the importance of these frameworks became evident almost right away - the IETF's AIMS working group released the first standard, while NIST's NCCoE working group, the Cloud Security Alliance, and OWASP all released various documents detailing their own proposed approaches. The same year saw a rush to release various identity management products by major vendors.

Before getting into what specific approaches are being taken and how they relate to each other, let's first briefly understand what an AI agent identity framework actually is, and why it became such a contested topic in the first place.

What is an AI Agent Identity Framework?

An AI agent identity framework consists of standards and reference architectures that enable tracking and auditing of autonomous AI agents. Unlike a conventional API key or service account that typically represents a single user or a computer process at most, an agent identity always has to account for the ability of an AI agent to perform operations not as itself, but as various combinations of humans and services. In other words, agent identities always have to be able to represent one or more principals, specify the levels of access they are to operate under, and be able to be terminated upon completion of the task. What makes these identities interesting is their potential to touch every single aspect of enterprise IT, from basic security to auditing and compliance, as AI agents become more powerful and capable of carrying out increasingly complex chains of actions.

Why AI Agent Identity Requires Its Own Framework

Most enterprise security stacks were built around two types of principal: people, who authenticate to systems to perform specific tasks, and services, which have a fixed, static permission set. AI agents don't particularly care to fit into either category, and this presents several problems, among which are:

Agents make decisions autonomously, rather than simply executing a chain of decisions made by a person.

A person makes a request, authenticates, and then executes, perhaps, dozens of requests to different systems to complete the operation. An agent, meanwhile, makes dozens of autonomous decisions in a single chain of reasoning faster than a human could keep up with. Existing IAM frameworks are built around the idea that a single person is making all decisions for an operation and authenticating once, which is fundamentally incompatible with the autonomy of agents.

Standing access dominates temporal access control.

Most agents are given persistent, broad permissions, since more fine-grained temporal access control is difficult to manage for something that needs to perform many operations across many systems. This results in agents having much broader permissions than is necessary for any individual task.

Existing credentials have no concept of a time horizon.

Time-based credentials are useful for limiting the period in which a system can be accessed after authentication, but agents often perform tasks that take much less than the time horizon specified, or substantially more. It is common for the entire set of credentials to be revoked before the agent can complete its task, or for an agent to continue to have access after it has completed its task.

Delegation is not first-class.

In most delegation chains, the ultimate decision is made by an employee, and existing IAM frameworks are built around ensuring that only a specific employee can make a specific set of decisions. An agent, by contrast, rarely makes decisions on its own, and must instead constantly delegate decisions to other agents, which is much more difficult to secure in existing frameworks.

Logs contain actions rather than decisions.

A system making ten authenticated requests would produce ten log entries, but none of them would indicate that they were all part of a larger, unified decision. For auditing purposes, it can be much more important to track individual decisions and the chain of delegation that led to them, but few systems are built to do so.

The fact that four different standards bodies have published agent-centric or agent-specific IAM research in early 2026 suggests that this is a genuine problem, not simply an academic exercise. Specifically, NIST, IETF, CSA, and OWASP have each published relevant agent-specific identity or governance research in early 2026, independently of one another.

The Three Pillars of NIST's AI Agent Standards Initiative

NIST's Center for AI Standards and Innovation (CAISI) recently launched the AI Agent Standards Initiative (AASI). The Initiative has three areas of focus:

1. Industry-led Standards Development

Promoting industry-led development of agent standards and of U.S. technical leadership in international standardization bodies like ISO/IEC and IEEE. That is, harmonizing the various agent protocol standards being developed by OAuth (extensions), SPIFFE/SPIRE, and MCP working groups before fragmentation occurs.

2. Open Source Protocol Development

Community-maintained open source protocol development and maintenance for agents. NIST is supporting this effort through its partnership with the National Science Foundation under the Pathways to Enable Secure Open-Source Ecosystems program; no single agent protocol is favored

3. Security and Identity Research

Advancing research in areas of AI agent security and identity to enable new use cases and trusted adoption in critical infrastructure and other economic sectors.
This third area of research is critical to the success of our overall initiative and has informed the NIST Center for Networking and Cybersecurity's (NCCoE) work on the concept paper for an AI Agent Interoperability Profile.

The NIST AI Agent Standards Initiative and NCCoE Concept Paper

The NCCoE released a concept paper titled “Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization” that highlights a possible NCCoE project to implement identity standards and practices in AI agents.

The basic approach.

Instead of building a brand new set of infrastructure, the paper proposes extending the frameworks already operating in an enterprise, including: OAuth 2.0 and OpenID Connect; SPIFFE/SPIRE System for Cross-domain Identity Management; Next Generation Access Control; Zero Trust architecture (SP 800-207); Digital identity guidelines (SP 800-63-4)

Scope and timeline.

A demo project by NIST will target internal enterprise agents, which can be controlled and monitored by an organization, generating an implementation guide rather than solely a set of guidelines.

Unresolved problem it flags

A standard OAuth flow, with On-Behalf-Of tokens, works for a single delegation, such as when an agent processes an action on behalf of a human user.

Multi-hop Delegation becomes an issue when agent A delegates authorization to agent B, which then delegates to agent C, which still represents an unanswered question to NIST.

The Four Focus Areas - Incorporating Non-Repudiation and Auditable Logging

The concept paper organizes its request for input in 4 areas. Together, they form a minimum architecture NIST demands from any agent identity system to cover.

• Identification: Determining whether an entity is an AI agent and managing the metadata relevant to its control over the range of possible agent actions, including whether particular actions require human-in-the-loop approval or are permitted to act on their own.

• Authorization: Using OAuth 2.0 extensions and related policy-based access control mechanisms to establish and enforce rights and entitlements for AI agents.

• Access Delegation: Binding user identities to AI agents in a manner that enables audit trails that adequately associate each action performed by an agent with the humans or institutions that are responsible for its actions.

• Logging & Transparency: Associating particular AI agent actions with the non-human entities that perform them to ensure visibility and accountability.

CSA Cross-Framework Mapping: AICM, OWASP ASI, NIST AI RMF

The MAESTRO Seven-Layer Architecture

CSA has proposed the MAESTRO (Multi-Agent Environment, Security, Threat, Risk, & Outcome) as a threat modeling framework for Agentic AI, allowing security engineers and developers to localize and mitigate risks across an agent’s operational stack. In its latest version, it holistically covers the entire lifecycle of an AI function by dividing it into seven interrelated layers,
enabling threat localization to a particular layer and layer-specific risk mitigation, instead of applying the same model to all layers, as is usually practiced. The seven layers are as follows:

• Foundation Models – pretrained and fine-tuned large language models performing core reasoning;

• Data Operations – data labeling, pipelines, and storage;

• Agent Frameworks – orchestration of agents;

• Deployment and Infrastructure – containerization and hosting;

• Evaluation and Observability – integrity checks and observation;

• Security and Compliance – confidentiality, control, and auditing;

• Agent Ecosystem – multi-agent orchestration and external item interactions.

The most noteworthy observation is that the model’s Layer 6 (Security and Compliance) is a cross-layer control and assurance domain, which means that security and compliance controls cut across all other layers, rather than being implemented at a single layer or set of layers. In other words, the Security and Compliance layer is where the implementation of the controls postulated by the AICM takes place.

Which Layer Enforces Which Control (Agent Frameworks vs. Deployment Infrastructure vs. Security/Compliance)

The three layers mentioned in the previous section have rather different control enforcement responsibilities, which often leads to conflation of controls at higher and lower levels of orchestration.

• Agent Frameworks enforce control at the orchestration level, specifically, by defining what tasks individual agents can delegate to which other agents and what level of authorization is required to perform such delegation on each level of the stack, thereby directly addressing the access delegation control standard described by NIST and the WIMSE-based agent identifiers standard advanced by the IETF.

• Deployment and Infrastructure enforce control at the workload level, specifically, by defining what isolation mechanisms (such as SPIFFE/SPIRE-based attestations) are required for hosting agents and how the network segmentation is structured for these agents, thereby directly implementing the zero-trust control framework at the level of orchestration infrastructure.

• Security and Compliance layer cuts across the stack; CSA’s AICM addresses it directly as a management layer, providing a comprehensive control framework that can be mapped to the existing control domains of individual vendors. AICM is actually an extended version of the Cloud Controls Matrix developed by CSA, listing 247 control objectives within eighteen security domains. Therefore, by implementing AICM, an organization can directly address the cross-layer control and assurance needs articulated by the Security and Compliance layer.

Where NIST AI RMF Fits In

NIST AI RMF (Risk Management Framework) fits in as a process framework for organizational risk management, within which the implementation of AICM can be mapped to actual control procedures. In essence, it is a four-step framework (Govern, Map, Measure, Manage) that guides organizations in institutionalizing their AI risk management practices, with AICM serving as a control framework that directly operationalizes the “Measure” component of the framework, which instructs the organization to “map AI systems to organizational risk levels.” When applied to the agent orchestration framework, it translates to a specific question for each control objective in the AICM: whether the control is implemented by the given agent or is the responsibility of the vendor who provides this agent.

By publishing the crosswalk of controls between AICM and NIST AI 600-1, CSA enables organizations to directly operationalize the “Measure” component of the NIST AI RMF via the AICM.

OWASP’s ASI Integration and Mapping

Unlike NIST AI RMF, OWASP’s ASI (Attack Surface Identification) is not a framework, but rather a list of known attack vectors targeting various aspects of AI systems. These aspects range from model properties (such as adversarial robustness) to data (e.g., data poisoning) to orchestration (e.g., adversarial supply chains). Attack surface identification helps prioritize risk management investments according to the attack likelihood and negative impact on each component.

This makes OWASP ASI similar to the AICM, except that the latter is a vendor-agnostic control framework, whereas OWASP lists threats addressed by individual vendors’ controls. Specifically, many of the attacks listed in the OWASP ASI are directly incorporated into the AICM as control objectives. For example, detecting prompt injections is explicitly mentioned as one of the controls to be implemented by the model security domain. Therefore, for most of the OWASP ASI controls, organizations can follow the AICM implementation guide.

NIST AI RMF is a process framework for organizational risk governance; CSA’s MAESTRO architecture serves as a technical risk management framework, enabling risk localization within the agent orchestration stack, and CSA’s AICM is a control framework that directly operationalizes risk management practices by providing a standardized list of control objectives within eighteen security domains. By virtue of listing attack vectors, OWASP ASI can be mapped to the AICM control objectives.

How to Build a Compliance Readiness Audit Trail

An audit trail for a compliant agent deployment must necessarily collect much richer information than would be common for a traditional human-entered audit trail, because the questions an auditor would ask of it are very different:

Tie every action to an agent identifier, not just a service account.

Every action taken by an agent must be attributable to a WIMSE-style identifier beyond whatever service account the agent may be running as; if the logs simply state that an action was taken by “service-account-47”, that’s insufficient to the needs of an agent-auditor, who will want to know which particular agent instance executed the action, what task it was performing, and who the human supervisor was who authorized that task to be performed.

Record Delegation Chains End-to-End

Any delegation of authority between agents must be logged in such a way that the full delegation chain can be reconstructed at any point in the past; Agent A delegating task B to Agent C to perform must result in logs that clearly show that it was Agent A that initiated task B, not Agent C, even though Agent C may have been the one that directly acted. This is precisely the scenario that both the NIST and IETF working groups have identified as one of the hardest problems to solve in auditing agent systems.

Bind actions to Non-Repudiable proof and not just log entries.

Logging statements must provide non-repudiation of authorizations, so far as it is technically possible to do so. A statement that “task X was authorized by principal Y” in a log entry is not sufficient evidence that such authorization actually occurred, unless the log entry itself cannot be changed without such change being explicitly noted. Wherever it’s feasible to do so, use signed SVIDs or other tokens with proven, auditable chains of custody, rather than mere log entries, to assert that a particular task was authorized by a particular supervisory agent.

Map existing logs to AICM control IDs.

Wherever feasible, current audit trails should be annotated with control IDs from AICM. Even though AICM itself is not yet formalized as a standard, it already publishes a crosswalk to NIST AI 600-1, and thus represents a reasonable baseline to aim for in terms of control objectives. This is a good idea because an auditor who is familiar with AICM’s control objectives will find it much easier to understand a defense that leverages AICM control IDs to annotate a log, even if the justification for control selection was based in large part on assumptions about a future standard.

How Akto Fits Into an AI Agent Identity Framework

Akto automatically discovers and catalogs every AI agent, MCP server, and tool in your infrastructure, cloud environment, and on employee laptops. With Akto, continuous red teaming and thousands of integrated exploit probes test your own agents' susceptibility to injection, privilege escalation, data exfiltration, and tool misuse 24x7. Runtime guardrails block risky agent behavior before it can occur, while behavior drift alerts notify when an agent begins operating outside the bounds of normal behavior. Akto's Identity for AI agents product addresses the credential borrowing problem directly by allowing true agent identity creation and management.

Organizations gain immediate insight into their current level of exposure while simultaneously providing a roadmap for raising agent security maturity with Akto's 5-stage maturity model.
The standards bodies are still finalizing their specifications, but Akto is already shipping these capabilities to enterprise security teams at the Fortune 500, solving real-world production agent security problems today. For organizations seeking to comply with emerging frameworks like NIST, IETF AIMS, or CSA MAESTRO, Akto provides the fastest path to achieving audit readiness.

Final Thoughts on AI Agent Identity Framework

Agent identity standards are still emerging. NIST, IETF, and CSA all focus on similar sets of primitives (OAuth, SPIFFE/SPIRE, Zero Trust, policy-based authorization), but leave out crucial multi-hop delegation, aggregation inference, and high-speed revocation capabilities from the specification. This doesn’t mean there isn’t value in getting ahead of the curve. The companies that are building products that will most benefit from these standards are already aligning NIST’s concerns, IETF’s identifier layer, and CSA’s threat model to their own architecture to audit agent actions and tie them to real-world identities - while actively planning to update and adapt their internal control policies as the standard evolves. Whether you build your own solution or leverage an emerging platform like Akto to accelerate your time-to-market, the risk of waiting for the standard to catch up far outweighs the cost of getting something defensible out the door today.

Frequently Asked Questions: AI Agent Identity Framework

1. How Does an AI Agent Identity Framework Work?

It's the set of standards and architecture patterns governing how autonomous AI agents are identified, authenticated, and authorized to act - distinct from the human or service credentials they run on. It covers identification, authorization, delegation, and auditable logging, tailored to how agents actually behave rather than how humans or static services do.

2. What is IETF AIMS, and how does it relate to NIST's approach?

AIMS (Agent Identity Management System) is an IETF Internet-Draft published in March 2026 that composes WIMSE identifiers, SPIFFE/SPIRE credentials, and OAuth 2.0 authorization into a single conceptual model for agent identity. It converges with NIST's approach on the same underlying standards, but its authorization and security-considerations sections remain underdeveloped compared to NIST's framing.

3. What is CSA's MAESTRO architecture, and how does it map security frameworks?

MAESTRO (Multi-Agent Environment, Security, Threat, Risk, & Outcome) is CSA's seven-layer threat modeling framework for agentic AI, running from foundation models up through the agent ecosystem. Its Security and Compliance layer cuts across all others, which is the layer CSA's AI Controls Matrix (AICM) operationalizes into concrete, checkable controls.

4. Which vendors currently offer AI agent identity products?

Major identity vendors including Akto, Okta, Microsoft Entra, Ping Identity, SailPoint, BeyondTrust, and Snowflake have all shipped agent identity products, alongside a few that focus specifically on agent and MCP discovery, testing, and governance.

5. What is the "agent harness" pattern?

The harness is the non-model engineering layer surrounding an LLM, managing context, tool routing, state, and safety constraints. It matters for identity because permission enforcement, credential scoping, and audit logging typically live in the harness, not in the model itself, making harness design a direct security decision.

6. How should organizations choose an AI Agent framework before official standards are finalized?

Build toward the direction NIST, IETF, and CSA are converging on now: OAuth/SPIFFE/WIMSE composition, policy-based authorization while documenting which draft each design decision is based on and setting revisit triggers tied to specific milestones (a finalized NCCoE project, a stable AIMS draft) rather than an arbitrary review date.

Important Links

• AI Security Tools

• MCP Security

• Claude Code Security

• AI Risks

• Bedrock Guardrails

• AI TRISM