Human, agent and system: the governance gap in AI access

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cakewalk's blog post: AI agent access governance is breaking down when human delegation, agent behaviour, and system access are treated as one static consent event.

Why it matters: IAM and NHI teams need a runtime governance model because delegated agent access can outgrow the assumptions behind reviews, audit trails, and one-time authorisation.

Context

AI agent access governance is the control gap this article focuses on. In the model described here, a human delegates to an agent, the agent acts, and the target system receives the call, but current OAuth-style controls do not evaluate that full chain at runtime.

The problem is not that access exists. The problem is that the access decision is often made once, then reused as the agent’s context, capabilities, and target system change. That leaves identity teams trying to govern dynamic behaviour with static consent and audit patterns.

For IAM and NHI programmes, the lesson is that runtime access decisions now matter as much as issuance and review. The article argues that the governance layer must see the human, the agent, and the system together, or it will miss the actual risk path.

Key questions

Q: What breaks when AI client access is governed only by per-app OAuth consent?

A: The IdP cannot see or centrally revoke the relationship between the AI client and the target tool. That creates unmanaged shadow AI, weakens lifecycle controls, and leaves teams unable to answer who can act in which system on whose behalf.

Q: Why do agentic systems create accountability problems for identity teams?

A: Because the decision chain is no longer a simple request and approval flow. Once an agent can select tools, extend tasks, and act without waiting for human intervention, it becomes harder to tell who authorised the specific action that caused the outcome.

Q: How should security teams enforce least privilege for AI agent identities?

A: Start by treating every agent as an NHI with a dedicated identity, a tight permission boundary, and a named owner. Then enforce least privilege in policy, not just in dashboards, so unused access is removed and rare elevation is granted only through JIT workflows. The goal is to shrink blast radius before autonomy creates incident scale.

Q: What is the difference between human consent and runtime authorisation for agents?

A: Human consent is the initial approval to let an agent act, while runtime authorisation is the live decision that a specific action is allowed now. For agents, the distinction matters because the original approval can be valid and still insufficient once context, target system or scope changes during execution.

Technical breakdown

Why OAuth-style consent fails for agent access

OAuth was designed to let a user grant an application limited access to a resource, usually through a fixed consent event and a token that can be reused until expiry. That model works when the software’s behaviour is predictable and the scope is stable. AI agents break that assumption because the same delegated credential can be exercised across changing prompts, tools, and target systems. The issue is not token format alone. It is that the original authorisation decision no longer describes what the actor is doing at runtime, which makes static consent a poor proxy for live intent.

Practical implication: treat delegated agent access as a runtime decision problem, not a one-time consent problem.

The human, agent and system triangle

The article’s three-actor model splits access into delegation, action and enforcement. A human authorises the agent, the agent decides what to do, and the target system determines whether the action is allowed. That triangle matters because each edge can fail independently: the human may be out of the loop, the agent may act in an unexpected context, or the system may accept a request that no longer matches the original intent. The technical mistake is assuming one login or one grant is enough to govern all three relationships.

Practical implication: model agent access around three explicit relationships, not around a single account grant.

Why runtime enforcement has to sit between agent and system

The article argues for a gateway-style control point that evaluates each tool call as it happens. That is different from pre-authorising a broad scope at signup. A runtime decision can consider the delegating human, the requested action and the target system together, which is what static OAuth grants cannot do once an agent starts chaining calls. The architectural point is that agent context is mutable, and mutable context needs per-action policy evaluation if the organisation wants traceable and reproducible access decisions.

Practical implication: place policy checks at the moment of each agent action, not only at credential issuance.

Threat narrative

Attacker objective: The attacker’s objective was to move from delegated access into internal systems and monetisable secrets that could be sold or reused.

1. Entry began with a compromised vendor laptop that exposed an upstream OAuth grant path into customer environments.
2. Credential abuse followed when the attacker used a stored grant to enter the Vercel Workspace and internal environment.
3. Escalation came through access to environment variables, API keys, tokens, database credentials and signing keys.
4. Impact was attempted data theft and sale of the stolen material on a criminal forum for $2 million.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• 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.

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

Static consent is the wrong governance unit for agent access: OAuth-style authorisation was designed for software that behaves within predefined bounds, not for actors that reinterpret context at runtime. Once an agent can change what it does, the original consent no longer describes the access in use. The implication is that identity programmes must stop treating signup-time approval as the control boundary for agent actions.

The human, agent and system model is the correct unit of governance: Access decisions now span delegation, runtime behaviour and target-system enforcement at the same time. That is why account-centric audit trails miss the real risk: they record who signed up, not who caused the action path at execution time. Practitioners need a model that makes the delegating human visible during each decision.

Runtime governance is a category shift, not a feature request: The article’s triangle shows that one grant can cover many future calls unless the control layer evaluates each call independently. That breaks the old assumption that least privilege can be fixed at provision time. The implication is that agent governance has to be enforced at action time, or it will remain descriptive rather than preventive.

Agent access is now part of the identity security perimeter: The article is describing a control plane that sits between human intent and system execution. That brings NHI governance, access management and auditability into one problem space. Practitioners should treat agent access as an identity architecture issue, not as an application integration detail.

Human accountability has to survive delegation: When the agent acts, the account alone is not enough to preserve responsibility. The delegating human must remain part of the access decision if organisations want answerable audit trails and workable compliance evidence. Teams that cannot tie runtime action back to a current owner will struggle to govern autonomous or semi-autonomous access at scale.

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.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Runtime governance is the missing layer: Access review cadences assume privilege survives long enough to be certified, but agent access can change context and target systems inside a single workflow. That makes issuance-time and action-time controls more important than periodic review for agent programmes.

Human delegation has to stay visible: If the delegating human is not preserved in the runtime decision path, organisations lose the ability to explain or defend the access that was exercised. The control problem is not just authorisation, but preserving accountable ownership across the full chain.

The security signal here is that access control is moving from static grant management to decision management. Teams that still treat AI agents like ordinary software integrations will miss the point where governance actually fails.

For practitioners

• Map delegated agent access paths Inventory where users can grant agents access to data, tools, and downstream systems, then document which grants persist beyond the original session or task.
• Move policy checks to runtime Require each agent tool call to be evaluated against the delegating human, the requested action, and the target system before execution.
• Separate agent tokens from the agent context Keep credentials in a separate vault and revoke them at session end so a compromised context window cannot expose reusable secrets.
• Rebuild audit trails around delegation Record which human delegated the action, which agent executed it, and which system accepted it so accountability is visible at review time.

Key takeaways

• AI agent access exposes a mismatch between static consent models and runtime behaviour, which makes traditional access governance too coarse for delegated actions.
• The article’s human-agent-system triangle explains why accountability, enforcement and delegation have to be governed together instead of as separate identity tasks.
• Practitioners need runtime policy, visible human ownership and per-action control if they want agent access to remain auditable and defensible.

Key terms

• Agent Access Management: Agent Access Management is the discipline of governing AI agents as non-human identities with scoped permissions, lifecycle controls, and auditability. It extends identity governance into runtime execution, where the important question is not only who configured the agent, but what it was allowed to do at the moment of action.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Human-Agent-System Model: The human-agent-system model describes access as a three-party relationship: a human delegates, an agent acts, and a system enforces or accepts the request. The model is useful because it makes visible the points where consent, behaviour, and enforcement can drift apart in agentic workflows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.