AI agent identity assurance is replacing simple agent mapping

At a glance

What this is: This is an analysis of why identity mapping is not enough for AI agents and why runtime assurance is becoming the control plane for agent trust.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes now have to govern not just who owns an agent, but whether that agent is authorised, authenticated, and reviewable at the point of action.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read 1Kosmos's analysis of AI agent identity assurance and runtime control

Context

AI agent identity is no longer a theoretical issue. Once agents start answering customers, reconciling invoices, and triggering transactions, identity becomes the control plane that decides whether machine action is trusted, constrained, and attributable. The governance gap is that traditional IAM was built for people and static machine identities, not actors that initiate actions at runtime and can move faster than human approval loops.

Identity mapping is a useful first step, but it is not a control model. Linking an agent to a human owner or service account can improve visibility, yet it does not prove the agent should be trusted to act, nor does it guarantee that a real person can intervene when a sensitive decision crosses a policy threshold.

Key questions

Q: How should security teams govern AI agents that act on behalf of users?

A: Security teams should govern AI agents with three layers of control: identity registration, delegated authorization, and runtime assurance. Mapping an agent to an owner is not enough. Teams need cryptographic authentication for the agent itself, explicit approval paths for sensitive actions, and revocation mechanisms that work while the agent is active.

Q: Why do AI agents create more risk than ordinary service accounts?

A: AI agents create more risk because they can select actions dynamically, chain tools, and continue operating without a human deciding each step. That makes static permissions easier to abuse and harder to review after the fact. The risk is not only credential exposure, but also uncontrolled execution under a legitimate identity.

Q: What breaks when identity mapping is treated as enough for AI governance?

A: What breaks is the assumption that knowing an agent’s owner means the organisation can trust the agent’s behaviour. Identity mapping gives attribution, not enforcement. Without runtime policy checks and explicit human approval for high-risk steps, the agent can act beyond intent while still appearing legitimate.

Q: How should organisations decide when an AI agent needs human approval?

A: Organisations should require human approval when the action is high impact, hard to reverse, or crosses a policy threshold that changes the business or compliance exposure. The approval rule should be defined before deployment, then tested in headless workflows so it still works when the agent has no active user session.

Technical breakdown

Agent identity mapping versus agent assurance

Identity mapping assigns an AI agent to a human owner or backing service account so the organisation can label the actor and trace activity. Agent assurance goes further because it asks whether the agent can prove its own identity, operate under explicit delegated authority, and be forced back through a control point when risk changes. The technical difference is between attribution and enforcement. Attribution tells you who the agent belongs to. Enforcement determines whether the agent may execute, under which conditions, and with what cryptographic proof. Practical implication: treat mapping as inventory, not control.

Practical implication: use mapping to discover agents, but require stronger assurance before granting production access.

Why delegated authorization needs runtime checks

Delegated authorization for AI agents often starts with an owner-approved token or scoped credential, but static scope does not guarantee safe behaviour once the agent starts chaining tools and actions. Runtime checks matter because the agent can cross from routine assistance into high-impact activity in the middle of a session. In practice, the control plane needs policy thresholds, step-up verification, and revocation paths that work while the agent is active. Without that, least privilege is only true at issuance time, not during execution. Practical implication: enforce policy at action time, not only at provisioning time.

Practical implication: build authorisation decisions that can be re-evaluated mid-session when agent behaviour changes.

Human-in-the-loop approval for high-impact agent actions

Human-in-the-loop approval is not about slowing every agent down. It is a runtime control for the subset of actions where the organisation needs explicit human accountability, such as funds movement, privileged configuration changes, or cross-domain data release. Backchannel approval patterns let the agent pause and request verification without requiring an active browser session. That matters because many AI workflows run headlessly. The control goal is to preserve automation for low-risk steps while inserting a verifiable human decision where business or regulatory exposure increases. Practical implication: define which actions must be approval-gated before agents enter production.

Practical implication: pre-classify sensitive agent actions and reserve human approval for those decision points.

NHI Mgmt Group analysis

Identity mapping is a visibility control, not an assurance control. Linking an agent to a human owner helps inventory and accountability, but it does not establish runtime trust. The model fails once the agent is allowed to act continuously at machine speed, because attribution after the fact is not the same as preventing unsafe execution. Practitioners should treat mapping as the starting line, not the governance outcome.

The assumption that least privilege can be fixed at provisioning time is breaking down for AI agents. That assumption was designed for stable actors whose intent and scope are known before execution begins. It fails when an agent can chain tools, shift task context, and request new actions mid-session. The implication is that least privilege for AI agents is no longer only a design-time question.

Runtime approval is becoming the dividing line between autonomous convenience and governed action. An agent that can trigger sensitive activity without a verifiable human decision creates a control gap that IAM alone cannot close. The practical consequence is that identity, policy, and workflow governance now have to converge at the point of action, not only at onboarding.

Agent-to-agent trust needs the same discipline that NHI programmes already apply to third-party machine identities. When agents exchange credentials or delegated proof across systems, the risk is not just impersonation but uncontrolled propagation of authority. That makes lifecycle control, delegation scope, and revocation just as important for agents as they are for service accounts. The implication is that NHI governance patterns now extend naturally into agentic systems.

Agent assurance is the named concept this market needs. The real problem is not whether an AI agent has an identity label, but whether that identity can be authenticated, governed, and interrupted at runtime. Once organisations accept that distinction, programme design shifts from ownership records to enforceable control over action, delegation, and human override.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap is why practitioners should also read OWASP Agentic AI Top 10 for the control patterns that address tool misuse, delegation, and runtime abuse.

What this signals

Agent assurance is emerging as the practical boundary between visibility and control. Enterprises can catalogue agents quickly, but they cannot rely on labels alone when the actor can change context and act continuously. With 80% of organisations reporting agent scope overreach, the programme signal is clear: review cycles built for static identities will not catch runtime drift.

Runtime governance now has to align identity, policy, and workflow design. If approval rules are only defined in the IAM layer, agents will still be able to execute outside intended bounds inside the application or orchestration layer. That means security teams need to map where delegated authority is granted, where it is challenged, and where it can be revoked across the full control path.

The category is moving toward cryptographic proof, policy thresholds, and human override for high-consequence actions. Teams that delay this shift will end up with inventories of AI actors but no defensible way to prove who authorised what, when, and under which conditions.

For practitioners

• Separate agent inventory from agent authorisation Register AI agents as first-class identities, but do not grant production permissions until each agent has explicit delegated authority, an owner, and a defined approval path for sensitive actions.
• Require runtime step-up for high-impact actions Use backchannel approval, biometrics, or device-based verification when an agent attempts privileged changes, transaction execution, or cross-domain data release.
• Replace static trust with revocable proofs Bind each agent to cryptographic credentials that can be revoked quickly when behaviour changes, ownership changes, or the agent exceeds its intended scope.
• Define approval thresholds before deployment Classify which agent actions require human sign-off, then test those thresholds in headless workflows so the approval path still works when no browser session exists.
• Extend access reviews to delegated agent behaviour Review not just who owns the agent, but which tasks it executed, which systems it touched, and whether the delegation chain still matches the current business purpose.

Key takeaways

• AI agent governance fails when organisations stop at mapping and never reach runtime assurance.
• The evidence points to a real control gap, with most organisations already seeing AI agents act beyond intended scope.
• Practitioners should design approval, authentication, and revocation controls around the point of action, not just the point of onboarding.

Key terms

• Agent Assurance: Agent assurance is the set of controls that prove an AI agent is who it claims to be, is acting within delegated authority, and can be interrupted when risk changes. It extends beyond inventory and ownership to runtime authentication, authorization, and human override for high-impact actions.
• Delegated Authorization: Delegated authorization is permission granted to an agent to act on behalf of another principal under explicit conditions. For AI agents, the key requirement is that the delegation remains bounded, revocable, and auditable while the agent is executing, not only when access is first issued.
• Human-in-the-loop Approval: Human-in-the-loop approval is a control pattern where a person must verify or authorise a sensitive action before it completes. In agentic systems, it is used selectively for actions with higher business, legal, or security impact, especially when the workflow runs without an active user session.
• Agent-to-agent Trust: Agent-to-agent trust is the mechanism by which one machine actor validates another before exchanging data, credentials, or delegated actions. It depends on cryptographic proof, policy enforcement, and revocation because autonomous collaboration can spread authority faster than human review cycles can track.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by 1Kosmos: AI agent identity assurance and runtime trust. Read the original.