TL;DR: AI agents can book meetings, provision infrastructure, process refunds, and move money without waiting for human approval, but traditional identity systems still track creation more reliably than runtime authority, according to 1Kosmos. The real gap is that access review and registration-time identity assume privilege remains stable long enough to inspect, while agents can act, expand scope, and persist on static credentials in real time.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on 1Kosmos's blog post: Agent runtime authorization and the finding that registration-time identity alone does not control what AI agents can do at execution time.
Why it matters: It matters because IAM and governance teams must decide how to bind AI agent actions to accountable identities before autonomous or semi-autonomous tools can spend, change, or expose anything sensitive.
By the numbers:
- 76% of business leaders expect employees to manage agents within the next 2-3 years, but most lack the security controls to manage what these agents actually do at runtime.
Context
Agent runtime authorization is the control gap between knowing who created an AI agent and knowing whether that agent should be allowed to act right now. In practical terms, the article is about runtime governance for AI agents that can initiate purchases, provisioning, refunds, and data access without waiting for a human gate.
Traditional identity systems were built around registration-time state, ownership, and periodic review. They struggle when an agent can invoke tools at machine speed, use long-lived credentials, and continue operating after the human creator leaves or changes role.
Key questions
Q: Where does agent runtime authorization fail if teams rely only on registration-time identity?
A: It fails at execution. Registration-time identity tells you who created the agent and who owns it, but it does not stop the agent from using broad credentials later to spend, provision, or read data. Without a runtime check, the permission model stays static while the agent’s behaviour keeps changing.
Q: When do AI agents become a bigger risk than traditional service accounts?
A: They become riskier when they can reason through obstacles, discover alternate tools, and act autonomously with broad permissions. At that point, the issue is not just credential exposure. It is that the identity can improvise its way into a larger blast radius than a static script.
Q: How can organisations tell whether runtime authorization is actually working?
A: Look for three signs: decisions happen fast enough to stay inline, policies use live context instead of stale claims, and every allow or deny produces an auditable record. If teams cannot explain a specific decision after the fact, or if applications bypass the control because it is too slow, the runtime layer is not functioning as intended.
Q: What should organisations do when an AI agent’s owner leaves or changes role?
A: They should immediately revalidate ownership and revoke any credentials that were tied to the departing person’s authority. If the agent can keep using the same access after the owner leaves, it has become an orphaned control problem, not just an inventory problem.
Technical breakdown
Registration-time identity vs runtime authorization
Registration-time identity records who created an AI agent, who owns it, and what lifecycle state it is in. Runtime authorization is different: it evaluates each action at the moment the agent attempts it, so the decision is based on current context rather than static ownership. That distinction matters because an agent can be correctly registered and still be over-scoped, orphaned, or acting outside its intended purpose months later. The control point moves from who the agent is to what it is trying to do right now.
Practical implication: Treat registration as inventory and runtime authorization as the enforcement layer that actually constrains agent behaviour.
Hardwired credentials and static scope
Most agent implementations rely on API keys, service account credentials, or OAuth tokens embedded at setup time. Those secrets are often long-lived, broadly scoped, and usable whenever the agent decides to act, which creates a privilege model that outlasts the original approval context. In identity terms, the problem is not only leakage, but the fact that the credential itself becomes a standing permission channel. Once the human context changes, the credential still behaves as if nothing changed.
Practical implication: Replace persistent agent credentials with time-bound, scoped credentials tied to the specific action being attempted.
MCP boundary enforcement for AI agents
The article describes interception at the MCP boundary, where each tool call is checked before execution reaches the target system. This creates an authorization checkpoint that can require explicit approval, issue a verifiable credential, or block the request entirely. That pattern shifts policy from the agent internals to the control plane around the agent, which is important because the same enforcement logic can govern different frameworks consistently. The result is execution-time control rather than trust in initial setup.
Practical implication: Place policy enforcement between the agent and external tools so every call is validated before it can execute.
Threat narrative
Attacker objective: The objective is to make the agent act with persistent authority that outlives the human approval context and bypasses runtime oversight.
- Entry occurs when an AI agent is created with an owner and credentials that are trusted beyond the original setup moment.
- Escalation follows when the agent later uses those static credentials to perform new actions, such as spending, provisioning, or data access, without a fresh identity check.
- Impact occurs when the agent continues operating after the creator leaves or the risk context changes, creating unauthorized financial, operational, or data exposure.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
- Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agent runtime authority is the missing control plane for AI agents: registration proves provenance, but it does not prove current authority. That gap matters because agents can initiate actions, select tools, and continue operating after the original human context has changed. The practical conclusion is that governance for AI agents has to move from creation-time records to execution-time enforcement.
Static identity assumptions break when agents act at machine speed: traditional IAM assumes a stable operator behind the account long enough for review, approval, and lifecycle cleanup. That assumption fails when an agent can chain actions faster than a human can detect them and can retain credentials after ownership changes. The implication is that access review alone cannot govern agent behaviour.
Hardwired credentials create an identity blast radius for AI agents: a single broadly scoped token can turn a narrow workflow into an open-ended execution path. Once the credential is embedded into the agent, every downstream tool call inherits that scope unless runtime checks narrow it. Practitioners should treat agent credentials as a live control problem, not a setup artifact.
Runtime authorization shifts accountability from configuration to action: ownership records tell you who deployed the agent, but they do not answer who approved the specific purchase, deployment, or data access request. That is why the governance question is not whether the agent exists, but whether the specific act is attributable at the moment it occurs. Identity teams need to govern the act, not only the asset.
Action-level verification is the named gap this article surfaces: agent runtime authorization is the control that closes the gap between authenticated agent existence and authorised tool execution. It is a distinct governance layer because the control decision is made at the moment of use, not at registration. For practitioners, the boundary between ownership and authority is now a security control, not an administrative detail.
From our research library:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- Read next: Zero Trust for AI Agents
What this signals
Governance programmes that stop at agent registration will miss the moment that matters most, which is execution. The control boundary has to move to tool-call time, because that is where a decision becomes an action and where runtime authorisation can still stop it.
Runtime authority gap: AI agents create a control problem that looks like identity management but behaves like live privilege enforcement. Once agents can act, expire, and reauthorise inside a short operational window, the programme has to verify action context instead of relying on static ownership records.
For practitioners
- Map agent actions to execution-time policy Inventory the actions an agent can initiate and classify which ones need approval at the moment of execution rather than at onboarding. Focus first on purchasing, production changes, and sensitive record access.
- Replace persistent agent secrets Remove long-lived API keys and service account tokens from agent workflows where possible, then issue short-lived credentials that expire after a single approved action or narrow time window.
- Enforce tool-call interception Insert a policy layer at the MCP or API boundary so every tool call is checked before it reaches the target system, with block, approve, or step-up outcomes based on context.
- Tie agent access to human lifecycle events Revoke or freeze agent credentials when the human owner leaves, changes role, or loses approval authority, so orphaned agents do not continue operating on inherited access.
Key takeaways
- AI agents create a governance gap when ownership is known but runtime authority is not checked before each action.
- The main exposure is standing access that keeps working after the original human context has changed or disappeared.
- Action-level authorization and short-lived credentials are the controls that narrow the blast radius of agent behaviour.
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on agents acting with excess or stale authority at execution time. |
| Recommendation — Bind every high-risk agent action to current identity proof and stop privilege from persisting past the moment of use. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Runtime authorization depends on action-time identity proof rather than static agent registration. |
| Recommendation — Use action-time authentication checks to ensure each agent tool call is tied to a verified identity. | ||
| NIST AI RMF | MANAGE — AI Risk Management | The topic is about operationalising controls for AI system behaviour across the lifecycle. |
| Recommendation — Operationalise AI governance so agent behaviour is monitored and controlled at execution time. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on limiting what an AI agent may do at runtime. |
| Recommendation — Review and enforce agent authorisations so tool access matches current risk and task scope. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The risk pattern is persistent credential use leading to financial, operational, or data impact. |
| Recommendation — Map agent credential misuse to credential access and impact tactics to prioritise detection and containment. | ||
Key terms
- Agent Runtime Permission: Agent runtime permission is the access an AI agent can use while it is actively executing a task. Unlike a static user role, it can change during a session, so governance must verify scope at the moment of use rather than relying only on onboarding or periodic review.
- Registration-Time Identity: The identity record created when an AI agent is first onboarded into an identity system. It captures who created the agent, who owns it, what it is for, and its lifecycle state. It supports governance and audit, but it does not by itself decide whether a later action is allowed.
- Verifiable Digital Credential: A verifiable digital credential is structured identity data that can be checked cryptographically by a relying party. Instead of relying on visual inspection, the verifier validates issuer signatures and presentation rules, which gives the control a clearer trust basis than an image-based document.
- Shadow Agent: An AI agent deployed without formal registration, identity governance, or security oversight, the agentic equivalent of shadow IT. Shadow agents are more dangerous than typical shadow NHIs because they actively take actions using their credentials.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org