Sunday, August 23, 2026
Four developments arrived close enough together this week to expose a structure that has been forming underneath the agent conversation for a while. MCP’s maintainers acknowledged that an authorization model centered on a human approving access in a browser no longer fits cloud agents operating after that human leaves. [1] An individual Internet-Draft proposed evaluating consequential actions against mutable runtime state rather than treating a valid credential as permanent permission. [4] Google moved agent identities further into the policy and service-perimeter machinery used to govern ordinary cloud infrastructure. [2], [3] At the same time, a correction to the LiteLLM supply-chain story showed how compromise can propagate through software trusted to enforce all of those boundaries. [5]-[8]
None of those events proves that a new agent-security architecture has arrived fully formed. Several of the mechanisms involved are old, some of the standards work is preliminary, and vendor implementations remain uneven. The useful signal lies somewhere else. The pieces we once collapsed into “the user has access” are being forced apart because autonomous execution puts distance between the person who delegates authority, the machine that exercises it, the state under which an action remains permissible, and the external consequence that follows.
We have spent most of the AI-agent conversation talking about capability. The harder infrastructure question is authority, because useful agents are increasingly being connected to systems where a selected action can become a real consequence.
Access Was the Easier Problem
Traditional access control has a shape we understand. Identify a principal, authenticate it, grant some permissions, record access, and provide a way to revoke the credential. The implementations can become fiendishly complex, but the governing idea remains coherent because deterministic software largely executes choices that were fixed before runtime. Developers decided which code path existed. Operators decided where the software ran. Identity and access management decided which resources the workload could touch.
Agents move some consequential selection out of that static arrangement. They receive an objective and decide portions of the path while running. They may choose a tool, sequence several calls, retry after failure, decide another agent is better suited to part of the work, or continue operating long after the human who initiated the task has turned attention elsewhere. Nothing mystical happened to the machine. We simply moved more decision-making into runtime and then connected that runtime to systems capable of changing the world outside the model.
That shift is enough to break several convenient assumptions. If the person and the acting machine are different principals, we need to preserve both. If an authorization granted earlier can become invalid because budgets, approvals, or risk conditions change, standing access cannot settle every action. If the action produces an external effect, the permission record does not tell us whether that effect actually occurred. If compromised software sits beneath the enforcement point, even a correct policy may become fictional. Those are different failures, so they need different controls.
Know Which Machine Is Acting
The MCP roadmap captures the first fracture because its original interaction model makes the contrast unusually visible. A person sitting at a browser can authenticate and authorize a client, then remain close to the transaction that follows. Cloud agents break that proximity. The person can delegate work, disappear from the interaction, and leave an autonomous process carrying authority for hours. That process may delegate again. [1]
Preserving only the human identity creates an audit trail that says whose authority entered the system while potentially losing which actor exercised it. Preserving only the agent identity creates the opposite problem. We know which machine acted but lose the human or organizational principal whose authority made the action legitimate in the first place. Useful attribution needs both, plus enough information about delegation to reconstruct how authority moved between them.
Google’s Agent Identity work shows what happens when that distinction starts becoming infrastructure rather than merely an audit label. An agent can exist as a first-class principal. Policy can target that principal, service-perimeter controls can recognize it, and credential systems can treat it independently. Operators gain the ability to constrain an actor at finer granularity instead of treating every autonomous process inside a workload as the same thing. [2], [3]
None of that solves the whole authority problem. It creates the prerequisite for seeing the rest of it. Infrastructure cannot govern an actor it cannot reliably distinguish.
A Credential Cannot Freeze Reality
The next failure occurs when we confuse valid identity with current permission. A purchasing agent may have a legitimate identity and valid access to a payment system. The business may have authorized it to spend up to a daily limit. None of those facts establishes that a particular transaction is permissible at the moment it is proposed because other actions may already have consumed the budget, an approval may have expired, another process may hold a reservation, a kill switch may have been activated, or the transaction may have crossed from reversible to irreversible as conditions changed.
This is where the AADP draft becomes interesting even if the particular protocol never survives the standards process. Its PDP/PEP architecture is old, and that is a feature rather than an embarrassment. Mature engineering should reuse controls that have already survived contact with reality. The agent-era pressure appears in the mutable state being evaluated and in the consequences attached to the decision. [4]
Standing capability answers whether an agent generally has access to a class of action. Runtime authorization answers whether this action, with these arguments, under these conditions, remains permissible now. Those decisions operate on different clocks, and forcing both into a credential because credentials are convenient does not make reality static. It merely hides the change from the control expected to govern it.
This distinction also exposes why “we’ll use RBAC” is an incomplete answer to agent governance. Role-based access control can establish that a purchasing agent belongs to a role allowed to invoke a payment tool. It does not, by itself, know that nine previous purchases consumed today’s budget or that an emergency declaration revoked the authority ten seconds ago. The role can remain correct while the action becomes wrong.
Permission Is Not Proof of Execution
Even current authorization leaves us one step short. Suppose an agent receives permission to transfer $10,000. The authorization engine records that the action may proceed. The agent invokes the payment system and the network connection times out before a result comes back. The organization knows the action was allowed, but it does not yet know whether the money moved.
This is a distributed-systems problem wearing agent clothing. The external side effect can succeed while acknowledgement fails. Retrying can repeat the side effect, while treating uncertainty as failure converts missing evidence into a new action. If an autonomous system is allowed to make that recovery decision itself, we have automated the path from ambiguity to duplicate consequence.
That is why AADP’s reporting side is more important than it first appears. Permit state, execution state, and external effect cannot be treated as one thing. The system needs a durable record of what it intended to permit, what execution was attempted, and what evidence came back. When the result is unknown, unknown must remain a legitimate state until reconciliation resolves it. [4]
Governance that records permission but cannot establish execution governs intention rather than consequence. Production systems eventually force that distinction because the world outside the policy engine does not care what the system meant to do.
Revocation Is the Test
Human oversight often becomes too vague to be useful. A governance program says humans remain in control because a person can review dashboards, approve high-risk actions, or intervene when necessary. Those are useful capabilities, but observation and occasional approval do not establish control by themselves. Control requires a defensible way to withdraw authority.
Can we stop one agent without taking down every agent around it? Can we revoke a delegation that was valid yesterday? Can we invalidate an approval after operating conditions change, close the tool path, rotate the credential, and prove the revocation reached every system carrying the old authority? If an action was already in flight when the stop occurred, can we reconstruct whether the consequence crossed the boundary before revocation took effect?
Those questions are less inspiring than “human in the loop.” They are also the questions an incident commander will need when the machine is doing something the organization no longer wants.
This is where operational sovereignty becomes useful language. Sovereignty does not mean owning every server or refusing cloud services. A self-hosted system can fail the sovereignty test spectacularly if nobody knows how to revoke the root credential. A third-party platform can provide strong operational sovereignty when its dependencies are understood, its authority can be bounded, its actions reconstructed, and trust withdrawn cleanly. The test is control of consequence, not possession of hardware.
A system you can observe but cannot meaningfully revoke is not fully under your control. That is not philosophy imposed on engineering. It is what the incident looks like when somebody finally has to stop the thing.
The Software Beneath the Policy Can Still Lie
The corrected Trivy and LiteLLM chronology pulls up the floorboards beneath this otherwise respectable architecture. Imagine we build the clean system. Human and agent identities remain distinct. Delegation is explicit. Runtime policy evaluates consequential actions. Execution produces evidence. Revocation is designed and tested. The diagrams are gorgeous, security architecture has declared maturity, and everyone starts using the word “governed” with increasing confidence.
All of it still runs on software. The identity broker is software. The policy enforcement point is software. The MCP server is software. The gateway routing tool calls is software. The container runtime is software. The CI pipeline building those components is software, and the security scanner deciding whether an artifact should pass is software too.
The Trivy incident demonstrates why that last category cannot be treated as administrative background. A compromise in trusted software-delivery infrastructure exposed credentials and persisted long enough to propagate into downstream projects. LiteLLM became one downstream casualty rather than the starting point of the broader exposure. The AI component inherited a trust failure originating elsewhere in the delivery chain. [5]-[8]Sources
That leaves runtime governance with a provenance problem underneath it. If the artifact enforcing authorization is compromised, the policy can remain perfectly correct while enforcement becomes false. Logs can report what malicious code wants them to report. The agent can be properly identified and the decision properly signed while the machine beneath those controls lies about what actually happened.
Artifact trust therefore belongs inside the authority model because authority is ultimately exercised through artifacts. Org charts do not change that. Putting Software Supply Chain, IAM, AI Governance, Platform Engineering, and Security Architecture under different vice presidents does not persuade production to honor the same administrative boundaries. Production does not care where the reporting lines are.
The Authority Stack
After those four stories, the shape becomes clear enough to name. Machine authority is becoming a stack, and each layer exists because the previous layer cannot answer the next operational question.
The human principal establishes whose interests and authority ultimately enter the system. The agent principal identifies which autonomous actor is exercising some portion of that authority. Delegation records what moved between them and which limits survived the transfer. Standing scope defines which resources and tools the actor may generally approach. Runtime authorization decides whether a consequential action remains permissible under current conditions.
Execution records the attempt to create an external effect. Evidence establishes what actually happened, including partial and unknown outcomes. Revocation terminates authority when trust changes. Artifact trust asks whether the software enforcing all of those boundaries is itself worthy of trust.
None of these controls substitutes for the others because the failures are different. Strong identity can authenticate a bad action. Strong authorization can approve an action whose external result becomes uncertain. Perfect evidence can document a machine the organization cannot stop. A flawless revocation design implemented by compromised software becomes elaborate theater.
This is why “agent guardrails” has become such an inadequate phrase. It collapses independent control surfaces into something that sounds like a fence around a model. The actual problem is closer to custody. Authority enters the system, moves, changes state, becomes action, produces consequence, and eventually has to end. We need to know what happened to it at each transition.
The Price Is Part of the Design
There is a reason organizations prefer simpler stories. This architecture costs money.
Agent identity adds lifecycle management, sponsorship, credential infrastructure, and audit requirements. Runtime authorization adds state, policy engines, decision latency, consistency problems, and another critical dependency. Durable execution evidence adds storage, reconciliation logic, privacy concerns, and operational ownership. Revocation has to propagate quickly enough to matter and has to be tested under failure. Artifact trust drags software provenance, build isolation, signing, dependency management, and CI hygiene directly into the governance conversation.
Every new control can also become a new crown jewel. A central policy service authorizing high-value actions must remain both available and correct. If it fails closed, agents may stop legitimate work during an incident. If it fails open, an outage in the control plane becomes an authorization holiday. Evidence stores can become sensitive repositories containing a detailed history of what autonomous systems attempted. Delegation graphs become harder to reason about as more agents and principals participate.
There is no free architecture hiding behind the phrase “responsible AI.” The organization either pays some version of this control cost or reduces the authority it gives the machine. The second option is perfectly respectable. An agent allowed to recommend a payment needs less authority infrastructure than one allowed to move the money. An agent drafting an infrastructure change needs less than one holding production credentials.
Give the machine only the consequence surface you are prepared to govern. That is also governance, and often it is the cheapest reliable control in the architecture.
Is This Just IAM With AI Branding?
A skeptical security architect can look at this entire argument and reasonably object that most of the mechanisms are old. They are right. Identity federation is old. Workload identity is old. PDP/PEP is old. Proof-of-possession is old. Policy enforcement is old. Service perimeters are old. Supply-chain compromise is painfully old. Distributed systems discovering that “timeout” does not mean “nothing happened” is old enough to have its own archaeological layer.
That is good news. The agent field does not need another excuse to pretend the rest of computing began when large language models became fashionable. Mature controls should be reused where their assumptions still hold, and discarded only when the new operating model actually breaks them.
The novelty claim is narrower. Agents alter the topology in which those controls have to operate. The human may no longer be present when execution occurs. The actor exercising authority may be an autonomous principal distinct from the human who delegated it. Delegation can move across machines. Actions can depend on mutable state accumulated by earlier actions. The system can select consequential operations after deployment rather than following only deterministic paths fixed by developers.
Those changes do not invalidate IAM. They increase the load IAM and adjacent controls must carry. Old steel. New load. The engineering task is recomposition, not reinvention.
The Override Problem
There is one place where every clean governance diagram eventually meets the actual world. Somebody will need to break the glass.
A patient may need care while the normal approval system is unavailable. A cyber incident may require an immediate containment action outside ordinary policy. A payment may not be able to wait for a failed control-plane service to recover. A disaster can remove the normal decision path entirely. Systems designed without emergency authority eventually develop emergency authority informally, which is another way of saying somebody creates a hole and hopes nobody notices how permanent it became.
Break-glass access is therefore part of the authority architecture rather than an embarrassment outside it. The override needs an owner with the authority to invoke it. It needs scope so emergency access does not silently become universal access. It needs a reason, a time limit, evidence, and a witness. It also needs a defined route back to ordinary authority after the emergency ends.
Most importantly, the override itself must remain attributable. If we spend months making machine authority legible and respond to the first serious incident by handing an untraceable master credential to whoever happens to be awake, the architecture has revealed exactly how much we believed our own doctrine.
Humans remain in the system because responsibility remains human. Autonomy changes execution. It does not dissolve ownership.
Build the Machine
The answer is not to retreat from agentic systems until they become harmless enough to govern with ordinary application permissions. That would throw away much of what makes them useful. I want agents that can continue working after I leave, delegate specialist tasks, investigate incidents, coordinate systems, move data, transact, provision infrastructure, and do useful work at machine speed. There is no virtue in forcing a human to click through every operation merely because our control architecture never matured past the browser.
But capability is only half of the deployed system. The other half is custody of authority. If the machine can carry authority, give the actor an identity. If authority moves, preserve the delegation. If conditions can change, evaluate consequential action against current state. If execution occurs, retain evidence of the result. If trust changes, make revocation real. If software enforces the boundary, prove what software entered that trust path. When somebody overrides the entire structure, put a name, a reason, and an expiration on the decision.
We should build the machine, and we should be able to answer for what we allowed it to do.
Artifacts are cheap, judgement is scarce.
Per ignem, veritas.
Sources
[1] D. Soria Parra and D. Delimarsky, The New MCP Roadmap, Model Context Protocol Blog, August 22, 2026
[2] Google Cloud, IAM release notes, Identity and Access Management, August 14, 2026
[3] Google Cloud, Agent Identity overview, Identity and Access Management, updated August 17, 2026
[4] S. Saha, The Agent Action Decision Protocol (AADP): Per-Action Authorization for AI Agents, Internet-Draft draft-saha-aadp-01, work in progress, August 20, 2026
[5] I. Arghire, Trivy, Not LiteLLM Behind the 2,500 Org Compromise, SecurityWeek, August 14, 2026
[6] Aqua Security, Trivy Security incident 2026-03-19 conclusion, GitHub Discussion #10462, March 30, 2026
[7] CloudSEK, 2,500+ Companies and 434,000 CI/CD Pipelines Exposed in the Largest AI Supply Chain Breach of 2026, CloudSEK, August 11, 2026
[8] BerriAI/LiteLLM, [Security]: litellm PyPI package (v1.82.7 + v1.82.8) compromised - full timeline and status, GitHub Issue #24518, March 24, 2026