TL;DR: AI agents are being deployed with service accounts, OAuth tokens, and workload identities that outpace traditional governance, leaving most security teams unable to see tool calls, data access, or sub-agent activity at runtime, according to Permiso Security. The real control problem is no longer permissioning alone but identity attribution and real-time containment across the full agent lifecycle.
At a glance
What this is: This is a product announcement about AI agent runtime security, with the central finding that posture-only controls cannot explain what agents actually do after authentication.
Why it matters: It matters to IAM and NHI practitioners because autonomous agents behave like identities with execution authority, so runtime visibility, attribution, and kill-switch controls become part of governance.
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.
👉 Read Permiso Security's announcement on AI agent runtime identity attribution
Context
AI agent runtime identity attribution is the practice of tying each agent action back to a specific identity, session, and deployment path. The governance gap is that many teams can catalogue permissions but cannot see what an agent actually did once it authenticated, especially when sub-agents, MCP servers, and downstream tools are involved.
For IAM and NHI programmes, that gap is not theoretical. Agents operate with machine speed, human-like access patterns, and multiple identity layers, which makes static entitlement review insufficient on its own. The topic fits squarely alongside broader NHI lifecycle governance, especially provisioning, runtime monitoring, and revocation as described in the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs.
Key questions
Q: How should security teams govern AI agents that use service accounts and MCP tools?
A: Start with ownership, then add runtime attribution and containment. Security teams should know which human deployed the agent, which identity the agent uses, what tools it can invoke, and when to revoke access. If the agent can chain tool calls or spawn sub-agents, governance must cover those paths as well, not just the initial login.
Q: Why do AI agents complicate traditional IAM controls?
A: AI agents complicate IAM because they behave like identities with execution authority, not like static workloads. They can make context-based decisions, call tools dynamically, and move across systems after authentication. Traditional IAM often records permission state but not the actions that create risk, so runtime behaviour becomes the missing control point.
Q: What breaks when teams only manage agent permissions at approval time?
A: Approval-time controls break when an agent’s real behaviour diverges from its intended scope. A model may be approved for limited access, then call extra tools, reach new data stores, or spawn sub-agents that expand blast radius. Without runtime monitoring, teams discover overreach after impact instead of during execution.
Q: What should organisations do in the first 24 to 72 hours after an agent behaves anomalously?
A: Contain the session, preserve the audit trail, and determine which identities and downstream systems were touched. Then review whether the anomaly reflects over-privilege, unsafe tool use, or a mis-scoped deployment pattern. If the agent can still act, revoke access before rebuilding the policy model.
How it works in practice
Why posture tools miss AI agent runtime behaviour
Posture tools answer a snapshot question: what is this agent allowed to access? Runtime behaviour is different because agents can chain tool calls, create sub-agents, and change execution paths based on context. That means the security-relevant state exists after authentication, not before it. If a control plane only records entitlements, it misses the sequence of actions that determines blast radius. In practice, this is why identity governance for agents has to include session-level telemetry, action attribution, and containment hooks, not only policy review.
Practical implication: Practitioners should treat runtime telemetry as part of the control set, not as an optional logging layer.
Identity attribution across tool calls, MCP servers, and data access
Attribution links each run, event, and tool invocation to the initiating human, the agent identity, and any sub-agents created along the way. That matters because a single agent session can traverse cloud resources, SaaS tools, internal APIs, and data stores before a security team notices abnormal behaviour. MCP makes this more visible and more risky at the same time, because tool access is now modular and easy to extend. Without a reliable identity chain, alerts become noisy and incident reconstruction becomes slow.
Practical implication: Security teams need an audit trail that preserves who initiated the agent, what it touched, and which downstream systems inherited risk.
Runtime containment for over-privileged agents
Containment is the operational answer to agents that exceed intended scope. The mechanism is identity-layer revocation or session termination when behaviour crosses a threshold, such as unusual data access, unapproved tool use, or interaction with high-risk infrastructure. That is different from changing a policy after the fact. A runtime control must operate fast enough to shrink the blast radius while keeping a durable record for investigation. For agentic systems, containment belongs in the same workflow as detection, not days later in a ticket queue.
Practical implication: Teams should define the exact conditions that trigger runtime revocation before agents are allowed into production.
NHI Mgmt Group analysis
AI agent runtime security is becoming an identity problem before it is becoming a platform problem. The article shows a market shift from entitlement review to runtime attribution, which is the right direction for agentic systems. Agents do not merely hold access, they execute decisions, call tools, and move across systems in ways that traditional IAM was not built to observe. Practitioners should assume that governance will fail if it stops at authentication.
Runtime visibility creates the first defensible boundary for agentic risk. A posture snapshot can tell you whether an agent may act, but only runtime controls reveal whether it actually did something unsafe. That changes the governance model from static approval to continuous verification and containment. The practical conclusion is that agent security must inherit ideas from ZTA and ZSP while adding identity attribution at execution time.
Identity blast radius is the right named concept for this category. The article’s core insight is that one agent session can touch many systems through tool chains and sub-agents, so the real risk is the spread of effect, not the initial login. Once practitioners think in blast-radius terms, they stop asking only whether access was approved and start asking how far the session could travel if it misbehaves. That is the correct frame for NHI governance.
Agentic AI security will consolidate around shared identity graphs, not isolated point tools. The article reinforces that security teams need one investigative plane for humans, NHIs, and agents if they want to avoid blind spots. Separate consoles and separate workflows increase friction exactly where speed matters. The direction of the market is clear: attribution, detection, and response are converging on identity as the common control layer. Practitioners should plan for integration, not another silo.
From our research:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which makes delayed containment a structural issue, not an exception.
- A practical next step is to pair lifecycle controls with the NHI Lifecycle Management Guide so runtime revocation and offboarding stay aligned.
What this signals
Identity attribution is becoming the minimum viable control for autonomous systems. With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the programme risk is not just over-privilege but untraceable action. Teams should expect auditors and incident responders to ask for session-level evidence, not permission screenshots.
AI agent governance should now be planned as a lifecycle discipline, not a deployment checklist. The controls that matter are discovery, attribution, privilege reduction, runtime monitoring, and fast revocation. That means security teams need to connect identity telemetry to incident playbooks, access review cycles, and change management before autonomous agents scale further.
Agentic AI will force convergence between NHI controls and zero trust thinking. If an agent can change tools, sub-agents, and data targets at runtime, trust must be re-evaluated continuously rather than granted once. That makes the NHI Lifecycle Management Guide and the OWASP Agentic AI Top 10 useful reference points for programme design, especially where tool use is broad and fast-moving.
For practitioners
- Map agent identities to explicit owners Require each AI agent to have a named business owner, a technical owner, and a revocation path before it is promoted into production. That ownership should extend to sub-agents and any MCP-connected tooling so incident response can trace authority quickly.
- Instrument runtime telemetry for every session Collect run, event, tool call, and data-access records at the identity layer so you can reconstruct behaviour after authentication. Focus on the full agent lifecycle, including repository creation, deployment, runtime operation, and containment.
- Set hard containment thresholds Define triggers for session termination, such as access to new production data, unexpected tool expansion, or anomalous downstream reach. The goal is to stop excessive blast radius while preserving an audit trail for review.
- Review agent privileges against actual usage Compare granted scopes with observed behaviour and remove permissions the agent never uses. Prioritise the highest-risk credentials first, especially where service accounts, OAuth tokens, or workload identities back the agent.
Key takeaways
- AI agents create an identity governance gap because their risk emerges after authentication, not at approval time.
- Runtime attribution and containment matter more than static entitlement snapshots when agents can call tools, spawn sub-agents, and touch production data.
- Practitioners should treat agent security as lifecycle governance, with discovery, monitoring, and revocation linked to the same control plane.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agent tool use and runtime abuse map directly to agentic AI identity risks. | |
| NIST CSF 2.0 | PR.AC-4 | Continuous access control is needed when agents act after authentication. |
| NIST AI RMF | GOVERN | Autonomous agents need ownership, accountability, and monitoring governance. |
Tie agent sessions to least-privilege access reviews and revoke excess access quickly.
Key terms
- Agent Runtime Attribution: The process of linking each AI agent action to a specific initiating identity, session, and execution path. It gives security teams a defensible audit trail across tool calls, sub-agents, and downstream systems so incidents can be reconstructed with more precision than entitlement data alone.
- Identity Blast Radius: The range of systems, data, and tools an identity can affect if it behaves unexpectedly or is compromised. In agentic environments, blast radius often expands through chained actions, inherited credentials, and automated tool access, making runtime containment a first-class security control.
- Runtime Containment: A response control that stops an active identity or session when its behaviour crosses an approved boundary. For AI agents and NHIs, containment usually means revoking access, terminating the session, and preserving evidence before the action chain spreads further across the environment.
- Mcp Server: A tool endpoint exposed through the Model Context Protocol that an AI agent can call during execution. MCP servers matter to identity governance because they extend agent reach into internal APIs, data stores, and workflows, which increases the need for attribution and scoped access.
Deepen your knowledge
AI agent runtime identity attribution and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your teams are moving from static NHI controls to autonomous agent oversight, it is a practical place to start.
This post draws on content published by Permiso Security: AI agent runtime identity attribution for AI agents. Read the original.
Published by the NHIMG editorial team on 2026-05-14.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org