> ## Content Index > Fetch the complete content index at: https://insights.cloudacio.com/llms.txt > Use this file to discover other available public pages before exploring further. # Give every AI agent an owner before it gets a credential - URL: https://insights.cloudacio.com/agent-owner-scope-revocation-before-credential/ - Published: 2026-10-28T00:03:11.000Z - Updated: 2026-11-09T15:51:22.000Z - Description: Surveys keep finding the same gap: nearly everyone is confident their agent controls are sound, and about a third can show it. Three decisions close most of that gap, and all three are cheaper before the credential exists than after. - Author: Juan Pablo Olivera - Tags: AI, #author-juan-pablo-olivera Almost every company running AI agents believes its controls are fine. Very few can demonstrate it. In Okta's [AI Agents at Work 2026](https://www.okta.com/newsroom/articles/ai-agents-at-work-2026-agentic-enterprise-security/?ref=insights.cloudacio.com) survey of 292 executives with authority over IT, security, data or engineering, fielded in March 2026, 96% were confident their identity and access management could secure non-human identities. Only 34% said their organisation always applies the same controls to agents as to employees. JumpCloud asked [250 IT decision-makers](https://jumpcloud.com/resources/56614-q4-2026-pulse-report?ref=insights.cloudacio.com) at companies of 200 to 2,500 people something different in July 2026 and got the same shape: 99% were confident they could audit AI activity, 37% held the records an audit would require. ![Bar chart comparing confidence with capability across three surveys: 96% confident IAM secures non-human identities versus 34% always applying the same controls as humans (Okta, 292 executives); 96.4% confident the agent inventory is complete versus 35.9% requiring registration before deployment (Guild.ai, 362 decision-makers); 99% confident they can audit AI activity versus 37% holding the records an audit requires (JumpCloud, 250 decision-makers).](https://storage.ghost.io/c/62/8f/628feacd-48cf-4de5-85ac-9760eb6467c8/content/images/2026/11/confidence-gap.svg) Three independent surveys, three samples, the same gap. They were fielded between March and August 2026 and cannot be summed or averaged, but the pattern repeats regardless of who asks. That gap is not a tooling shortage. Six identity vendors shipped or announced agent governance products in about six weeks this autumn. What would close most of it is not a product but three decisions: 1) who owns this agent, 2) what is it allowed to touch, and 3) how do we stop it. Each is nearly free before you issue the agent a credential, and expensive after. ## Owner: a name, not a team Gravitee asked [750 CIOs, CTOs and heads of platform](https://www.gravitee.io/state-of-ai-agent-security?ref=insights.cloudacio.com) in the UK and US, in April 2026, how accountability for agent behaviour is handled. Only 7.2% had a named individual formally accountable. The rest called it unclear, shared but undefined, or never discussed. Its [previous wave](https://www.gravitee.io/blog/state-of-ai-agent-security-2026-report-when-adoption-outpaces-control?ref=insights.cloudacio.com) had asked *who* was accountable and got confident answers, the CTO at 28.2% and the CISO at 26%. Asking *how* showed those answers had been aspirational. A distribution list is not an owner. When an agent does something nobody intended at two in the morning, ownership decides whether anyone picks up the phone. The cleanest definition I have seen puts accountability on whoever granted the access rather than whoever wrote the code, which also covers the case where the builder left and someone else approved the token. ## Scope: the agent inherits whatever you had The default failure is credential borrowing. The agent runs as the person who launched it, so no downstream system can tell agent action from human action, no investigation attributes anything correctly, and the agent holds every permission that person holds rather than the ones the task needs. Microsoft documents this as a product limitation. In the on-behalf-of flow the token subject is the user, so [Entra's Conditional Access docs](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-on-behalf-of-agents?ref=insights.cloudacio.com) state that selecting an agent identity as the policy subject does not cover agent requests made on behalf of that user. Donald Farmer, writing on [agent identity management](https://www.techtarget.com/ai/tip/Secure-your-agentic-AI-with-identity-management?ref=insights.cloudacio.com), puts the consequence more bluntly. If an agent uses an employee's login, you cannot revoke the agent without locking out the employee, and the logs show only the employee's name. PocketOS is the clearest illustration I know. On Friday 25 April 2026, as [The Register reported](https://www.theregister.com/software/2026/04/27/cursor%5Fopus%5Fagent%5Fsnuffs%5Fout%5Fstartups%5Fproduction%5Fdatabase/5224442?ref=insights.cloudacio.com) with direct quotes from the founder and the platform's CEO, a coding agent hit a credential mismatch in staging and decided to fix it. It found a Railway API token in a file it could read. That token had been created for adding and removing custom domains through the CLI, but Railway did not offer scoping on API keys, so it could do anything the account could. The agent called a legacy endpoint missing the delayed-delete protection the dashboard has, and erased the production database. Railway kept volume-level backups inside the same volume, so those went too. The newest recoverable copy was three months old, and the outage ran past 30 hours. Three parties failed there. The agent guessed, the platform shipped unscoped tokens and an unprotected endpoint, and the backups lived inside the thing they were backing up. The agent's own account said it guessed that deleting a staging volume through the API would be scoped to staging, that it did not verify, and that nobody had asked it to delete anything. Not a fleet of rogue bots. One agent with more access than anyone realised. ## Revocation: measure it, since the spec does not promise it Morning Consult surveyed [362 US IT decision-makers](https://www.guild.ai/blog/news/ai-agent-management-gap?ref=insights.cloudacio.com) for Guild.ai in August 2026\. Agents run in production at 96% of their companies, and of four basic controls, an automated way to stop one came last. ![Column chart of controls in place for AI agents among 362 US IT decision-makers: 96% have agents in production, 42.7% a centralised dashboard, 39.8% logging or audit trails, 35.9% require registration before deployment, 31% an automated kill switch.](https://storage.ghost.io/c/62/8f/628feacd-48cf-4de5-85ac-9760eb6467c8/content/images/2026/10/controls-in-place.svg) One survey, one denominator, so these compare directly. Agents run in production at 96% of these companies. The ability to stop one automatically is the rarest of the four controls. Even teams that have a kill switch tend to trust it more than they should, since calling the revoke endpoint does not mean the agent has stopped. The OAuth revocation spec ([RFC 7009](https://www.rfc-editor.org/rfc/rfc7009?ref=insights.cloudacio.com)) lets a provider kill the long-lived token while the short-lived ones it already handed out keep working until they expire, and the endpoint answers OK even for a token it has never seen. Newer standards like [CAEP](https://openid.net/specs/openid-caep-specification-1%5F0.html?ref=insights.cloudacio.com) exist to push the revocation out to every system that trusts the token, and that gap is what this autumn's new products are selling into. OpenCode's breach in October shows the same problem from another side. Provider keys for OpenAI, Anthropic and Google saved in its Console may have been exposed, and deleting a key from the tool that held it revokes nothing, since the key keeps working until you revoke it at the provider. Console's spend caps did not help either, because they only apply to traffic through its own gateway. In fairness, OpenCode disclosed within hours, and any hosted gateway that holds your keys has the same design. So run the exercise. Pick your highest-privilege agent, revoke its credential and time how long it takes until it really cannot act, checked at every system that accepts that credential and not only where you revoked it. Until you have that number, your kill switch is a hypothesis. ## There is no standard to wait for The reasonable objection is to wait for a standard. It would be a long wait, and it would not bring anything new. The IETF's [draft on agent identity](https://datatracker.ietf.org/doc/html/draft-ietf-wimse-aims-00?ref=insights.cloudacio.com), written by people from six companies including AWS and OpenAI, deliberately invents no new protocol and describes how to apply the standards we already have. Its one firm requirement is that every agent has its own identity and its own credential, which is where this post started. Governments have also written down what good looks like. In October, NIST, the NSA and CISA published [ten voluntary practices](https://www.nist.gov/news-events/news/2026/10/key-practices-incident-readiness-and-response-super-intelligence-training?ref=insights.cloudacio.com) for agent incidents, and three of them match this post. Revoke the credentials an incident touched and shut affected agents down automatically, check that the shutdown actually works before restarting them, and rehearse it. ## This week If you run four agents with fifteen people, do not buy an agent identity platform. Open a spreadsheet with five columns: agent name, owner, purpose, what data and systems it can reach, which vendor it runs on. One credential per agent, never a human's. Minimum permissions for the stated purpose. Keys out of any file an agent can read. A 90-day expiry a person has to renew. Thirty minutes a month reading the list aloud with someone else in the room, since that is when you notice the row nobody can explain. Buy tooling when the agents touch payment data, health records or anything else regulated, or when you can no longer recall every agent from memory. Then answer Farmer's four questions for each row... who owns this agent, what can it access, what can it do, and can you prove what it did. He puts them before an agent gets access to any business system. The fourth is the one an auditor asks, and the audit figure above says it is the one you are least likely to have. While you are in there, decide who has the authority to stop an agent in the middle of the night, and write the name down.