TL;DR: AI agents are being granted broad delegated access through OAuth-style trust models that were designed for static software, not runtime decision-making, according to Cakewalk’s analysis. The core failure is assumption collapse: access reviews and signup-time consent do not govern agents that act dynamically across human, agent, and system boundaries.
At a glance
What this is: This is an analysis of why current access governance fails when AI agents operate between humans and target systems, with the key finding that static grants and delayed reviews do not control runtime agent behaviour.
Why it matters: It matters because IAM, IGA, PAM, and NHI programmes all depend on knowing who or what is acting, what it can reach, and when authority is exercised, and agentic access breaks those assumptions.
By the numbers:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
👉 Read Cakewalk's analysis of Human → Agent → System access governance
Context
Agent access governance is the problem of controlling what a delegated software actor can do after it has been given permission to act. The article argues that current models break because they assume access is granted once and then reviewed later, while AI agents make decisions at runtime across shifting contexts. That is an agentic AI identity problem, not a conventional app integration issue.
The access chain described here runs through a human delegator, an acting agent, and a target system. Once those three are separated, the old OAuth pattern of one consent event covering many future actions becomes too blunt to manage identity security, accountability, and enforcement together.
That is why the article frames Human → Agent → System as the layer practitioners now have to govern. The starting point is typical of the current market: organisations keep extending machine-to-machine access patterns into agentic workflows even though the behaviour model has changed.
Key questions
Q: What breaks when AI agents are governed like ordinary service principals?
A: The main failure is that ordinary service-principal governance assumes a stable workload with predictable lifecycle and entitlement patterns. AI agents can inherit access from a blueprint, act through user-shaped interfaces, and change their operational state at runtime, so the control model no longer matches the behaviour. Teams need a separate governance view for the agent runtime, not just for the underlying credential object.
Q: Why do AI agents complicate privilege management for IAM teams?
A: AI agents can authenticate, call tools, and act with delegated authority, which means they behave like non-human identities with real execution power. That makes simple credential protection insufficient. IAM teams need policy, lifecycle, and monitoring controls that account for autonomous action, not just login events.
Q: How can security teams tell whether agent access is actually under control?
A: Look for evidence that the team can trace every tool call, secret use, and cross-system action back to a named owner and a valid approval path. If an agent can reach messaging, browser, and infrastructure tools without a revocation chain, access is not truly governed. Control exists only when the runtime can be stopped as fast as it can act.
Q: Who is accountable when an AI agent uses delegated access incorrectly?
A: Accountability should follow the delegated authority chain, not stop at the agent label. The relevant owners are the teams responsible for the human identity, the service identity, the workflow, and the policy that allowed the action path. If those responsibilities are not explicit, incident review will be incomplete and remediation will focus on the wrong layer.
Technical breakdown
Why OAuth grants break down for agentic access
OAuth was built to let an application obtain scoped access on behalf of a user, usually with a stable purpose and predictable call pattern. In agentic workflows, the application is no longer a fixed script. The agent may choose actions dynamically, change tool usage based on context, and exercise delegated access long after the original consent event. That means the grant still exists, but the reasoning that justified it may no longer match the live session. The technical problem is not OAuth itself. It is the mismatch between static consent and runtime agency.
Practical implication: treat signup-time consent as insufficient for agentic systems and govern each call path at runtime.
The human, agent, system triangle
The article’s three-actor model is a useful way to think about agent access because each edge answers a different control question. The human edge establishes delegation and accountability. The agent edge governs what the software can do in motion. The system edge determines what the target will accept in a given context. If any one edge is invisible to the policy layer, the decision becomes incomplete. That is why existing access management layers can leave large gaps even when they record the original grant and the later audit trail.
Practical implication: evaluate whether your access layer can see the delegator, the agent, and the target system in the same decision.
Why runtime policy needs to replace one-time approval
A one-time approval model assumes the risk profile is stable from the moment access is granted to the moment it is used. Agentic access breaks that assumption because the request can be created, reshaped, and executed without a new human decision gate. Runtime policy is therefore the control plane that matters. It has to evaluate the requested action, the delegating human, and the target system together, then produce a repeatable decision that can be audited later. Without that, organisations can log behaviour but still fail to govern it.
Practical implication: move from static permissioning to per-action enforcement with auditable policy decisions.
Threat narrative
Attacker objective: The attacker aims to convert delegated access into reusable credentials, internal visibility, and monetisable breach impact.
- Entry begins when a human grants an AI platform broad OAuth access, which creates a delegated path into enterprise systems without future review at the moment of use.
- Escalation follows when the attacker rides that delegated access into workspace and internal environments, then enumerates environment variables, API keys, tokens, database credentials, and signing keys.
- Impact is achieved when stolen data is monetised or reused for deeper compromise, while the organisation is left trying to reconstruct runtime actions from a trust model that only recorded the original consent.
Breaches seen in the wild
- Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
- Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Static OAuth consent is the wrong control for agentic access. The article shows that a single approval event cannot safely govern a software actor that makes runtime decisions, selects actions dynamically, and reuses access across changing contexts. That is not a minor implementation gap. It is an assumption failure in the consent model itself, and practitioners should stop treating agent access as ordinary third-party app access.
Human → Agent → System is the right identity topology for this problem. The useful control question is not just who authenticated, but who delegated, what the agent can do, and which target system is in scope at the moment of execution. That three-way view is stronger than app-centric IAM because it preserves accountability while exposing the actual enforcement point. Identity teams should map agent governance around the triangle, not around the login event.
Runtime enforcement is the named gap this article exposes. The industry has spent years perfecting grants, logs, and reviews, yet the access decision still often happens too early. Once an agent can act later, with different context and without a new human gate, the review cycle becomes forensic rather than preventive. Practitioners should recognise that the missing layer is live policy evaluation at the point of action.
Agent access governance is becoming a core NHI discipline, not a niche AI problem. The same lifecycle questions that apply to service accounts now apply to agent identities, but the behaviour is more volatile and the accountability chain is longer. That shifts the work from simple secret control toward delegated access governance across IAM, IGA, and PAM. Teams that keep those domains separate will miss the failure pattern this article describes.
Access review assumes stability, and autonomous decision-making erodes that assumption. Access review processes were designed for access that persists long enough to be observed, certified, and revoked. That assumption fails when an agent can obtain, combine, and exercise authority in runtime sequences that outpace the review cycle. The implication is that governance models must be rethought around live delegation, not merely re-certified access.
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 report.
- 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, according to SailPoint.
- For a broader control lens, OWASP NHI Top 10 frames the runtime risk areas practitioners need to map first.
What this signals
Runtime delegation will become the decisive control boundary for agentic programmes. The organisations that keep treating agent access as a variant of third-party SaaS approval will accumulate blind spots faster than they can review them. A more durable model is to bind delegation, runtime policy, and accountability into a single decision path, then audit that path as a control object rather than a log artefact. With 80% of organisations already reporting out-of-scope AI agent behaviour, the governance problem is no longer hypothetical.
Human, NHI, and agent governance are converging into one lifecycle discipline. The same questions about ownership, offboarding, and entitlement scope now apply across service accounts and AI agents, but the agent layer adds runtime drift that traditional access review was never built to catch. Teams should prepare for identity programmes that join IGA, PAM, and agent policy enforcement instead of operating them as separate tracks.
The next control maturity step is not more alerts. It is policy that can explain why a specific delegated action was allowed at a specific moment, and whether that decision still holds when the system or context changes.
For practitioners
- Map every agent grant to its human delegator Record who approved the grant, what the agent may do, and which systems it may reach. Keep those three fields bound together in the policy layer and in the audit trail so accountability survives later investigation.
- Replace one-time consent with per-action authorisation Evaluate each tool call at runtime against the delegating human, the requested action, and the target system. Do not rely on the original OAuth approval to govern later behaviour in production.
- Separate agent tokens from agent context Store session credentials outside the model context so prompt injection or context leakage cannot directly expose reusable secrets. The agent should be able to act without being able to enumerate its own tokens.
- Review every integration for implicit future access Find cases where a single integration approval grants broad downstream reach into workspaces, databases, or internal tools. Re-scope those integrations so future access is explicit rather than inherited from first consent.
Key takeaways
- Agentic access breaks the assumption that a single consent event can govern all future actions.
- The real control gap is runtime enforcement across the human, agent, and system boundary, not just better logging.
- IAM, IGA, and PAM teams need to treat delegated agent access as a live policy problem, not a static integration problem.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | The article focuses on agent access governance and runtime misuse of delegated permissions. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Delegated credentials and token handling are central to the access chain described here. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management is directly challenged by broad agent delegation. |
| NIST Zero Trust (SP 800-207) | The article’s runtime enforcement model aligns with continuous verification and explicit policy decisions. |
Map agent delegation paths to OWASP Agentic AI risks and prioritise runtime controls over signup-time approval.
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.
- Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
- Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.
What's in the full article
Cakewalk's full analysis covers the operational detail this post intentionally leaves for the source:
- The end-to-end access layer design for Human → Agent → System governance, including how delegation and accountability are bound together.
- The runtime evaluation model for per-action decisions, including how the gateway reads the human, the agent, and the target system on each call.
- The separation of agent tokens from agent context, which reduces the risk of prompt injection exposing reusable credentials.
- The implementation details behind sensitive environment variable handling and session-scoped permissions in the access gateway.
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 August 26, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org