AI agent access should be governed like employee access

At a glance

What this is: This is an analysis of AI agent governance at scale, with a focus on why broad OAuth permissions and borrowed human access create the wrong trust model for autonomous workloads.

Why it matters: It matters because IAM, PAM, and NHI programmes need to govern agent identities by scope, lifecycle, and revocation, not by how harmless the task appears.

By the numbers:

• Roughly 70% of high-value agent projects in zone 3 still fail.
• The identification ceiling for zones 1 and 2 sits at around 35% of processes.
• A field study covered 177 companies running autonomous agents in production.

👉 Read Cakewalk's analysis of secure AI agent adoption at scale

Context

AI agent access governance is the practice of giving software agents their own scoped identity, rights, and revocation path instead of borrowing a human user's permissions. The core problem in this article is not model quality. It is the security gap created when an agent is connected to real systems through broad OAuth grants or long-lived credentials that were never designed for runtime autonomy.

That gap is already visible in third-party access patterns. The article uses the Vercel breach to show how a connected AI app can become the entry point into internal systems when permissions are broader than the task requires. For IAM teams, the lesson is that agent access must be managed as a lifecycle problem, not a one-time integration decision.

The starting position described here is common, not exceptional: a useful app gets connected quickly, granted too much, and then left in place without meaningful review. That is the default operating model most identity programmes still need to unwind.

Key questions

Q: How should security teams govern AI agents that use OAuth access?

A: Security teams should inventory each agent, limit scopes to the minimum required, assign an owner, and monitor its behaviour continuously. They should also define revocation steps before an incident occurs, because delegated OAuth access can become a lateral-movement path when an agent is compromised. Governance should cover discovery, approval, review, and offboarding as a single control loop.

Q: Why do AI agents create new risk in non-human identity management?

A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.

Q: What breaks when AI agents are managed like ordinary machine identities?

A: What breaks is the assumption that access scope can be fully understood from provisioning data and quarterly review. Ordinary machine identities are repeatable; agents are not. If teams only review entitlements, they miss context shifts, delegated actions, and credential creation inside the session.

Q: Should organisations re-evaluate agent access after a third-party app is connected to core systems?

A: Yes. Any third-party integration that touches core identity, collaboration, or data platforms should be treated as a high-priority review item. Re-evaluate the grant, the owner, the scope, and the revocation path before the connection becomes a permanent part of the environment.

Technical breakdown

Why broad OAuth grants become agent identity risk

OAuth is an authorisation framework, not an access governance model. In this article's pattern, the issue is not that OAuth failed cryptographically. The issue is that a third-party app received broad scopes that outlived the original task and could be abused after the app or its vendor was compromised. Once a credential or grant is tied to a human account but exercised by an agent, the organisation loses clarity on who or what is actually acting. That breaks containment, review, and revocation logic.

Practical implication: review every agent-connected OAuth grant as a standing identity and scope it to the minimum task boundary.

Why static access is the wrong control for AI agents

Static access assumes that an identity's permissions can be set once and remain valid throughout the work. AI agents do not fit that assumption well because their tool use, session length, and action sequence can vary by context. When the same agent can read, write, and pivot across systems under a single persistent credential, the blast radius expands from a task to an environment. That is why the article frames access scope, not task complexity, as the main risk variable.

Practical implication: separate agent roles, tool scopes, and credentials so a single compromise cannot traverse the full workflow.

Why revocation and offboarding matter for agent lifecycle

Agent lifecycle governance has to include onboarding, role assignment, periodic review, and explicit offboarding. The article's central point is that the security boundary is not where the agent starts work but where it can be cleanly removed from trust relationships. If an agent cannot be revoked without breaking production logic, then its identity was never truly governed. That is an identity design failure, not just an operational inconvenience.

Practical implication: define revocation criteria before deployment and make offboarding a required control for every production agent.

Threat narrative

Attacker objective: The attacker wanted to exploit trusted application access to move from a connected app into internal corporate systems and expand the blast radius.

1. Entry occurred through a third-party AI app connected to corporate Google Workspace with broad permissions, giving the attacker a trusted route into the environment.
2. Credential or grant abuse followed when the compromised app's existing OAuth grant was used to pivot into internal systems without needing to break the perimeter directly.
3. Impact was the expansion of attacker access through a trusted integration path, increasing exposure across internal systems and sensitive data.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent governance fails when organisations treat runtime access as if it were static software entitlement. The article shows that the main risk is not the task the agent performs, but the authority it carries while performing it. That is why access scope, revocation, and role definition matter more than the apparent simplicity of the workflow. Practitioners should reframe agent access as lifecycle-controlled identity, not application configuration.

Broad OAuth grants create identity blast radius before any malicious action occurs. The Vercel example is not just a breach story, it is a governance pattern. A third-party app with wide permissions can inherit the full trust of the connected account, which means compromise of the app becomes compromise of the access relationship. Security teams need to judge agents by reachable systems, not by user-facing function.

Agents should be managed as non-human identities with employee-like lifecycle controls. The strongest position in the article is that agents need their own identity, scoped rights, review, and revocation when the job ends. That aligns with OWASP-NHI and ZTA thinking: trust should be explicit, narrow, and continuously governable. The practitioner conclusion is clear, if an agent cannot be offboarded cleanly, it does not belong in production.

Zone 1 agents can be more dangerous than complex zone 3 workflows. The article correctly shifts attention away from complexity and toward access scope. Low-risk tasks connected to broad credentials are easier to ignore, easier to over-grant, and easier to compromise. That means security teams should prioritise the apparently mundane integrations first, because they are often the highest-blast-radius identities in the stack.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• 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 the OWASP Agentic AI Top 10 matters now, especially for tool misuse and identity abuse.

What this signals

Identity blast radius: AI agents are turning access scope into the primary control variable for IAM teams. The practical shift is away from asking whether a workflow is low-risk and toward asking what the agent can reach, whether that reach is time-bound, and whether the grant can be revoked without collateral damage.

With 98% of companies planning to deploy more AI agents within 12 months and 80% already reporting scope violations, the governance problem is no longer hypothetical. Security teams should expect more connected apps, more delegated access, and more pressure on identity review cycles, which means lifecycle discipline has to move ahead of adoption.

The likely programme change is a tighter linkage between NHI governance, PAM review, and application access management. When an agent acts through an integration, the control plane has to cover token lifecycle, entitlement review, and offboarding together, not as separate workstreams.

For practitioners

• Inventory every agent-connected OAuth grant Map each connected app to the human or service account it inherits, the scopes it holds, and the systems it can reach. Remove any grant that cannot be justified by a current business task, and treat stale connections as standing exposure.
• Issue agents their own scoped identities Stop letting agents operate under borrowed human logins. Create separate identities with task-specific permissions, short-lived credentials where possible, and clear ownership so activity can be reviewed and attributed.
• Make revocation a deployment requirement Define how an agent will be turned off before it is allowed into production, including credential invalidation, token revocation, and cleanup of linked integrations. If offboarding cannot be completed cleanly, the access model is incomplete.
• Prioritise access scope over task complexity Rank governance work by the systems an agent can reach, not by whether the workflow looks low risk. A simple workflow with broad access should be reviewed before a complex workflow with tightly constrained rights.
• Reduce human approval fatigue Limit manual approvals to ambiguous cases and let policy handle routine actions. Repeated prompts train operators to click through, which turns oversight into theatre instead of control.

Key takeaways

• AI agent security fails fastest when organisations over-grant access to seemingly harmless workflows.
• The real control gap is lifecycle governance, because agent credentials must be reviewable and revocable like employee access.
• Security teams should prioritise broad agent scopes and connected-app grants before they expand AI deployment further.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
• Agent Offboarding: The process of formally retiring an AI agent by revoking credentials, detaching tools, closing access paths, and recording evidence that authority has ended. In NHI programs, offboarding is as important as onboarding because abandoned access is still active risk.

What's in the full article

Cakewalk's full article covers the operational detail this post intentionally leaves for the source:

• The four-zone automation model and how the identification ceiling is used to separate suitable from unsuitable agent work.
• The Vercel breach walkthrough showing how broad third-party access can become an internal entry path.
• The employee-style onboarding model for AI agents, including role assignment, review, and revocation.
• The team-level operating model for handling human-in-the-loop escalation without creating approval fatigue.

👉 Cakewalk's full post covers the four-zone model, the Vercel pattern, and the agents-as-employees operating model.

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.