Your AI Agents Exercise Authority Nobody Is Governing

Almost every conversation I see about agent security starts in the same place. Someone asks how to stop a prompt injection. Someone else asks how to keep an agent from being tricked into calling the wrong tool. The whole discussion is about attacks reaching the agent: the malicious instruction hidden in a support ticket, the poisoned document in the retrieval index, the compromised integration upstream.

These are real problems. I have written about several of them. But they all sit on top of a question almost nobody asks first, which is what the agent is allowed to do before any attack lands.

The answer is uncomfortable once you say it plainly. An AI agent is not, by itself, an identity. It is software that decides which action to take or request. But every consequential action it takes happens through an identity or a delegated authority: a workload identity, a service account, a borrowed human session, a temporary credential, or an execution service the agent asks to act on its behalf. The moment you let an agent read a database, post to an API, file a ticket, or move money, that action runs on standing authority that someone has to own, scope, and time-box. When that authority reaches sensitive data or consequential actions, you have a high-risk identity in play. It is privileged when it carries elevated administrative or consequential authority. In most organizations, the authority an agent exercises is broad, long-lived, owned by no one in particular, and revisited approximately never.

Agent, identity, credential, and authorization are four different things, and the industry collapses them

The first move is to stop treating these as one thing, because the collapse is where the governance gap hides. A glossary page will tell you an agent "is a non-human identity." That is market shorthand, not a clean technical statement, and the shorthand is what lets the real object of governance slip out of view.

Read the table top to bottom and the conflations become obvious. The agent is not the identity: the same agent can act through several identities, and one identity can be shared by several agents. The credential is not the identity either. A leaked token proves an identity to whoever holds it, which is exactly why a stolen credential is dangerous, but the token and the identity are different objects with different lifecycles. Vendor "machine identity" counts often mix accounts, workloads, keys, tokens, and certificates, so treat them as machine-identity ecosystem counts rather than a clean census of distinct actors. That distinction matters when you go to govern them, because you secure an authenticator differently than you govern the actor it authenticates.

The relationship between an agent and the authority it exercises is many-to-many, and that is the part most security writing skips. A coding agent might act through a dedicated workload identity for repository access and a separate delegated human session for the ticketing system. A support agent might borrow the identity of the human who invoked it for some actions and use a shared service account for others. A finance agent might never hold a long-lived credential of its own at all, and instead ask a brokered execution service to perform each transaction under a freshly issued, scoped grant. The agent is one thing. The set of identities and delegated authorities it can act through is another. The governance object is the binding between them.

The thing to govern is the agent-to-authority binding, not the agent and not the credential

Once you see the binding as the object, the inventory question sharpens. The number that should worry a CTO is not how many agents are in production. It is how many distinct authority grants those agents can exercise, who owns each one, and whether anyone can name them.

Start with scale, because scale is where the argument becomes hard to wave away. Machine identities already outnumber human identities in most enterprises, and not by a little. CyberArk's 2025 Identity Security Landscape, a vendor survey rather than an enterprise census, reports more than eighty machine identities for every human, with a large share carrying privileged or sensitive access and most organizations lacking identity security controls for the AI systems now multiplying them. Those figures are survey responses counted against a vendor's own definition of "machine identity," so read them as direction and order of magnitude, not audited fact. The same directional signal shows up across the vendor reports in this category: the non-human population is large, growing faster than the human one, and, in the practitioner work I do, substantially ungoverned.

Agents accelerate the binding sprawl rather than the identity count alone. Every agent you stand up needs to act on something to be useful, so every agent acquires one or more authority grants. A coding agent needs repository access and a way to open pull requests. A support agent needs to read customer records and update tickets. A finance agent needs to query the ledger and, at some point, to initiate a transaction. Each of those is an authorization with a scope, attached to some identity, proven by some credential. Multi-agent systems compound it, because the orchestration layer, the tool servers, and the individual sub-agents can each carry their own bindings.

So the hard version of the inventory question is simpler to ask and harder to answer: for every consequential action your agents can take, can you name the identity it runs as, the human or team that owns that authority, and when the grant was last reviewed? In most organizations the answer is no, and the reason is not a tooling failure. It is a lifecycle failure.

Lifecycle controls govern standing access, and most agent bindings get only the first one

A human account in a well-run organization has a lifecycle. A person is hired, and an identity is issued through a defined process. Someone owns it, usually the manager and the IAM team jointly. The access is scoped to the role, reviewed, and narrowed when the role changes. Credentials are managed under policy and retired when the role ends rather than left valid forever. When the person leaves, the account is deprovisioned, and an audit trail shows who had what and when.

Six things happen across that lifecycle: issuance, ownership, scoping, credential management, deprovisioning, and audit. Decades of identity and access management exist to make each one routine. It is the unglamorous plumbing that keeps the compromise of one account from becoming the compromise of the company.

Now look at how an agent's authority usually gets created. An engineer needs the agent to do something, so they generate a token or a key, paste it into a config or a secrets manager, and ship. That is often the entire lifecycle: a grant gets issued and then exists, indefinitely, at whatever scope it was born with. Walk the same six stages against that default and several of them are commonly missing or inconsistently enforced.

Issuance is ad hoc. Human identities go through a request, an approval, and a record. Agent grants get minted by whoever is building the agent, often outside any central process, sometimes as a long-lived personal access token belonging to the engineer rather than to a governed workload identity. An effective issuance discipline routes the agent's authority through the same governed path a human's would, with the request and the approval recorded.

Ownership is undefined. A human account has an owner who is accountable for it. An agent's authority frequently has no named owner at all. The engineer who created it moved teams. The agent was inherited by a platform group that does not know what it does. When something goes wrong, the first hour of the incident goes to figuring out who is even responsible for the grant. Authority without a named owner is not a managed thing. It is a liability waiting for an incident to assign it one.

Scoping is over-broad by default. Generating a tightly scoped grant is more work than generating a broad one, so under deadline pressure the broad one wins. The agent that needs to read three tables gets read access to the whole database. The agent that needs to post to one endpoint gets write access to the API surface. Least privilege is the control that limits how much a compromised agent can do, and it is the control most often skipped, because skipping it is faster.

Credential management lags. Here the popular advice gets the direction wrong, so be precise. NIST's SP 800-63B guidance against forcing periodic password changes applies to human memorized secrets, where forced calendar rotation drove users toward weaker, predictable passwords. It is not a general rule that rotating machine secrets on a schedule is theater. For static machine secrets, periodic rotation remains a reasonable fallback. The stronger design is to eliminate those static secrets where you can, by issuing short-lived, audience-bound, workflow-bound credentials at runtime through federated workload identity, so a leaked secret expires on its own. Agent grants, in practice, get neither. They are issued once as a long-lived token and used until something breaks. A token valid for a year is a year of exposure for anyone who obtains a copy, and copies leak into logs, commit history, developer environments, and third-party integrations in ways no one fully controls.

Deprovisioning is forgotten. When an agent is retired, replaced, or quietly abandoned because the experiment did not pan out, its grants often keep living. The token still works. The access is still granted. The org now holds standing authority with no corresponding system anyone is watching, the machine equivalent of a badge that still opens the building two years after the holder left.

Audit is partial. Human access gets reviewed. Agent grants often do not appear in the same reviews, because the people running access certification do not have those grants in their inventory in the first place. You cannot audit what you cannot see, and most organizations cannot see their full set of machine authority grants.

The pattern is consistent: the binding gets issued and then exists, at whatever scope it was born with, until an incident forces the question.

Authorization is the primary bound on how far the attacks everyone writes about can travel

Here is why this matters more than it first appears. The identity-and-authorization layer is not a parallel concern to the attacks people keep publishing about. For the attacks that do durable, tool-mediated damage, it sits upstream of them.

Consider what a successful attack on an agent actually achieves. An indirect prompt injection succeeds when a malicious instruction, hidden in content the agent processes, gets the agent to take an action the attacker wants. A scope leak succeeds when an agent can be steered into reaching data or systems it should not. A compromised tool in the agent's supply chain succeeds when the agent is induced to call something hostile. Each of those is worth understanding on its own terms, and I have written separately on several.

Notice what the worst case in each one depends on. When the damage runs through a tool the agent can call, it is bounded, first and foremost, by what that agent is authorized to do. An injected agent cannot exfiltrate data its grant cannot reach. A steered agent cannot move money its authorization does not permit. A prompt injection against an agent limited to three specific tables is constrained to that reachable data path, subject still to row-level controls, downstream joins, application bugs, and whatever sits in the agent's context. The same injection against an agent holding broad, long-lived, admin-adjacent authority produces a catastrophe of a different order.

Be precise about the limit, though, because authorization is a bound, not a force field. A prompt injection can still do harm that never touches a privileged tool. It can leak data already sitting in the agent's context, corrupt the analysis the agent hands back, poison the memory it carries into the next session, or manipulate the human who trusts its output. Tight authorization stops none of those. What it does is cap the consequential, tool-mediated damage, the data exfiltration and the unauthorized transaction, which is the class of failure that turns an incident into a disaster.

This is the part the security conversation keeps skipping. We argue about how to keep the agent from being tricked, which is hard and important and never going to be perfectly solved, while leaving unmanaged the variable that decides how far the trick travels once it works. An agent will eventually be fooled. Whether that is contained or catastrophic is mostly a question of what its authority permitted, and whether anyone had been narrowing and time-boxing it.

So the mental model has two moves, in order. Agent security starts with identity: who or what the action runs as, who owns it, how long it lives. It is enforced through authorization: what that identity is permitted to do, per task, at the moment it acts. Model behavior is probabilistic and adversarial, and you will never fully lock it down. Identity and authorization are not perfectly deterministic either, because effective access also depends on application-level enforcement, on delegated and downstream services, on confused-deputy paths and credential chaining, and on whether your inventory and policy are current. But they are far more enforceable, testable, and auditable than model behavior. They are the parts you can write down, check, and revoke.

The breach that does not start with a clever prompt starts with a credential nobody remembered

The incidents that worry me most are not the ones with an elegant exploit. They are the ones that pivot through a credential nobody remembered they had.

The pattern looks like this. An organization integrates a third-party service, or stands up an AI agent, or connects a vendor's automation into its environment. Doing so requires a credential, scoped generously because scoping it tightly was more work and the integration needed to ship. That credential gets stored somewhere, used, and forgotten. No owner is assigned. No expiry is set. It is not in the access review, because nobody put it in the inventory.

Months or a year later, that credential is the way in. Maybe it leaked through the third party. Maybe it ended up in a log or a repository. Maybe the integration itself was compromised and the token came along with it. The attacker does not need a brilliant prompt injection. They need a valid, over-scoped, long-lived credential that nobody was watching, and the organization handed them one at issuance time and never took it back.

The scale risk is already visible. In early 2026 Moltbook, a platform built for AI agents, left a database exposed. Wiz, which disclosed it, reported a misconfigured Supabase database holding roughly 1.5 million Moltbook authentication tokens, alongside private messages that contained some plaintext third-party API keys. Be careful about what that incident does and does not prove. It is not evidence of every lifecycle defect described in this article. It does not establish that those credentials lacked owners, were broadly scoped, or were never rotated, and the immediate cause was a missing database access control, not a demonstrated identity-lifecycle failure. What it demonstrates is narrower and still important: a population of machine credentials can reach enormous scale, and a single authorization failure can expose the whole population at once. The size of the inventory is what turns one mistake into a mass event.

What makes the forgotten-credential class of breach distinctive is that none of the usual security narratives would have caught it. The model was never tricked. The prompt was never injected. The agent, if there was one, behaved exactly as designed. The broader class of failure here is lifecycle failure: credentials that are issued, over-scoped, left unowned, never expired, never deprovisioned, or never audited. The breach walks in through the gap those missing stages leave open. Not every such breach exhibits every defect, and the Moltbook exposure above demonstrates scale and an access-control lapse rather than a full lifecycle audit. But the class is real, and it is the class the lifecycle controls exist to close.

Runtime controls govern each attempted action, and they are five distinct families, not one

The lifecycle is necessary and, on its own, not sufficient. It answers who owns this authority, how broadly it is scoped, and when its credential expires. It does not answer the question that decides what a compromised agent actually does in the moment: at runtime, for this specific action, what is this agent allowed to touch.

A long-lived admin grant with a named owner and a clean audit entry is still a long-lived admin grant. Lifecycle governance gets you a known, owned, time-boxed authority. Runtime control decides how much of that standing authority is live for any given action. They are different controls, and a serious agent program runs both.

The mistake is to lump every runtime defense under one heading. A practical runtime control model can separate at least five concerns, and they do different jobs and fail in different ways. OWASP's agentic-systems guidance recommends related controls across its mitigation playbooks. It organizes them around reasoning manipulation, memory poisoning, tool execution, authentication and identity and privilege, human-in-the-loop interaction, and multi-agent communication and trust. The five families below are my operational grouping of those controls, not OWASP's taxonomy verbatim. Naming them separately is what lets you tell which one you are missing.

Authorization narrows the tools, resources, and actions the identity can reach at the instant it acts. Transaction control is the separate family that decides when limits, approvals, idempotency, or human review are required, so that even a fully authorized, perfectly owned agent cannot be steered into an irreversible action without a human in the loop. Treat those as two controls, not one. Authorization decides whether the actor may invoke an operation at all; transaction control adds approvals, limits, rate, sequencing, and idempotency before an irreversible action executes. Isolation, when enforced across context, memory, credentials, tools, and data stores, keeps a compromise in one session from spreading across all of them. Detection is what turns a silent breach into a noticed one. Trust keeps a multi-agent system from being subverted through a forged message between its parts. None of the five removes the need for the lifecycle. Each one narrows a different path the standing authority could otherwise take.

Deployment evidence is what proves both the lifecycle and the runtime controls are actually present

The reassuring part of all this is that the answer is not a new product category. You already run an identity program for humans. The move is to bring agent authority inside it, and to make the binding a condition of deployment rather than a question you ask after an incident.

The order of operations matters, and the first step is the one most organizations skip. You cannot govern what you cannot see, so before any control can run, someone has to discover and catalog the identities, grants, and credentials the agents already hold, including the ones a platform or vendor issued opaquely. For many readers this is where the real work starts, because the person who approved the agents may have no line of sight into the authority those agents were granted. If you do not know what you have, every policy you write governs a fiction.

From there, the lifecycle controls and the runtime controls each leave evidence, and the deployment gate is where you check for it. An agent does not reach production until its authority has a named owner, a scoped grant, a short or revocable credential, and a place in the audit inventory, and until its runtime controls (authorization, transaction limits, isolation, detection, signed trust where it operates among other agents) are configured rather than assumed. That gate is not a security team saying no. It is a delivery discipline that makes the safe path the default path, the same way a required code review or a passing test suite does.

A caution on reuse, because it is tempting to overstate it. You can reuse the principles of your human IAM program, issuance, ownership, scoping, lifecycle, deprovisioning, audit, but the machinery usually does not transfer wholesale. Machine authority at agent scale typically needs automated discovery, federation, runtime issuance, and programmatic revocation that human-oriented IAM tooling was not built to deliver. Reuse the operating model. Expect to extend the tooling.

Agent security is not only a model-behavior problem, and the parts you control are the ones that decide the outcome

If you take one thing from this, let it be the order. The instinct, when agents start touching real systems, is to reach for an agent firewall, a prompt-injection scanner, a model-level guardrail. Those have their place. But they are defenses on the attack surface, trying to win an adversarial game against a probabilistic system, which means they will sometimes lose.

Identity and authorization are the parts you can write down and check. Who the agent's action runs as, who owns that authority, how long it lives, and what it is permitted to do, per action, at the moment it acts, are decisions you make and can audit. They are the ones that determine what happens on the day, and there will be a day, when one of the attack-surface defenses fails.

So the question to put in front of your next agent deployment is not which model, and not which guardrail. It is the governance question: for every consequential action this agent can take, who owns the authority it runs as, when does that authority expire or get revoked, and what is it permitted to do right now. An organization that can answer those for the agents it runs has moved the tool-mediated authority problem into a governable identity-and-authorization program its existing operating model already knows how to manage, while model behavior, context leakage, memory, and human manipulation stay separate controls it still has to run. The agents are not the new thing to secure. The authority they exercise is, and it has been the whole time.

Frequently Asked Questions