TL;DR: Broad OAuth grants and static access create the real security failure mode in agent deployments, according to Cakewalk, which argues that AI agents should be onboarded like employees, with scoped identities, defined roles, and revocation at offboarding. The central assumption that breaks is that access can be safely granted once and reviewed later, even though agent behaviour and tool reach can change at runtime.
NHIMG editorial — based on content published by Cakewalk: Talk the Walk How to Adopt AI Agents Securely at Scale: The 4 Zones of Automation
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Issue agents their own scoped identities Stop letting agents operate under borrowed human logins.
- 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.
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.
👉 Read Cakewalk's analysis of secure AI agent adoption at scale →
AI agent access controls: are your scopes and revocation ready?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent access should be governed like employee access