Sunday, August 23, 2026
1. The Browser Is No Longer the Authorization Boundary
The Model Context Protocol was designed around a familiar authorization event. A person is using a client, the client needs access to a resource, and the person is present to approve that access through a browser. Human identity, consent, and the beginning of execution live close enough together that ordinary OAuth machinery can carry most of the load. That is a reasonable model for an assistant waiting for somebody to ask it a question. It becomes much less complete once the caller is an agent that continues working after the person leaves.
On August 22, the MCP maintainers published a roadmap for the protocol’s next stage. One of five priority areas is “agent identity and enterprise-ready security.” Their explanation is more important than the label. They specifically call out cloud agents with their own identities, agents operating for users who are no longer present, and agents delegating narrower authority to other agents. [1] The roadmap does not claim these problems have been solved. It acknowledges that the human-in-the-browser assumption no longer describes the system MCP is being asked to support.
Forge News Breakdown
The proposed direction is conservative in the useful sense. MCP is not trying to invent an AI-specific identity religion. The roadmap points toward existing machinery including Workload Identity Federation, Demonstrating Proof of Possession (DPoP), token exchange, and the Identity Assertion Authorization Grant used in enterprise-managed authorization. [1] Those mechanisms already exist because distributed systems have spent decades learning that bearer credentials, long-lived secrets, and implicit trust become unpleasant once software begins crossing administrative boundaries.
What has changed is the topology around those mechanisms. Imagine a user authorizes an agent in the morning to investigate a production issue. The user moves on to something else. The agent keeps working, decides it needs a specialist, delegates a narrower diagnostic task, and that second agent later calls an MCP server. The original human authentication remains relevant because it tells us whose authority entered the system. It no longer tells the server which autonomous actor is exercising that authority now, whether delegation occurred, or what limits survived the handoff.
A system can therefore authenticate every technical hop while losing attribution across the chain. That is not an exotic attack scenario. It is the predictable result of allowing the actor model to become richer while leaving the credential model flat.
Forged Analysis
This is the first meaningful distinction in the week’s news. Human principal and agent principal are related, but they are no longer safely interchangeable. The human establishes an objective and delegates some capacity to act. The agent becomes the runtime actor choosing how that capacity is exercised. If another agent enters the chain, another actor and another transfer of authority have entered the system.
Identity cannot solve everything that follows, nor should it. Knowing which agent called a tool does not establish whether the call was wise, currently permissible, or within a budget that may have changed since the original delegation. A perfectly authenticated agent can still make a perfectly attributable mistake. The value of identity is narrower and more fundamental. It gives the rest of the infrastructure something stable to govern.
That is why MCP’s decision to build on workload identity and standard token mechanisms is the right direction. The interesting change is not new cryptography. It is the admission that the entity exercising delegated authority must survive as an identifiable actor after the human leaves the interaction.
There is a practical consequence for operators building agent platforms now. If every agent in a system borrows the same user token or disappears behind a generic service credential, the platform may know that access was technically valid while remaining unable to reconstruct which autonomous actor actually chose the action. Authentication succeeds while accountability becomes blurrier with each autonomous hop.
The browser used to be a useful place to collapse those questions because the person and the action happened close together. Agents stretch them apart in time, process, and increasingly across machines. MCP’s roadmap is beginning to account for that distance.
Counter-pressure
Agent identity will not make agents safe. There is a predictable temptation to turn every new infrastructure noun into a governance solution, and the technology industry has already performed that ritual with zero trust, service mesh, policy as code, and enough other ideas to prove we can make cargo cults out of almost anything.
Agent identity tells us which actor arrived and, if the surrounding system preserves the delegation correctly, on whose behalf that actor may be operating. It cannot tell us whether the proposed action is still allowed after the world changes. That decision depends on different state, different failure modes, and a different control surface. MCP has started separating the actor from the person behind it. The next problem begins immediately after that separation.
Forged Take
The operational change is simple enough to state without pretending it is simple to implement. Once the human can leave while delegated authority remains active, identity must follow the machine exercising that authority. If authority can move again, the delegation has to remain inspectable as well. Otherwise autonomous execution is being built on credentials that can tell us where authority started without reliably telling us where it went.
MCP is not finished building that model. Its maintainers have now acknowledged that the old one is too small, which is exactly the kind of admission a protocol has to make before the infrastructure around it can mature.
2. A Token Cannot Know the Budget Changed
A valid identity answers one important question and leaves the next one untouched. An agent can be exactly who it claims to be, possess legitimate access to a tool, and still propose an action that should be denied. The credential may not be stale and the policy may not be misconfigured. The conditions surrounding the action may simply have changed since the authority was granted.
An individual Internet-Draft published August 20 by Shamik Saha proposes a protocol for that gap. The Agent Action Decision Protocol (AADP) separates standing identity and capability from authorization of a specific action under current state. [5] It is early work, not an adopted IETF standard or an IETF consensus position. Its value at this stage comes from framing the operational problem cleanly enough to argue with.
Forge News Breakdown
AADP uses a Policy Enforcement Point (PEP) and Policy Decision Point (PDP) architecture. Neither concept is new. The draft explicitly traces the model to established authorization systems such as XACML, including permit decisions and obligations. [5] Painting “agentic” on PDP/PEP and presenting it as a newly discovered principle would be security theater with better branding.
The interesting work begins with the state being fed into that established architecture. AADP allows a decision to consider cumulative budgets, active reservations, previous executions, approval state, kill switches, and whether the proposed action is reversible. A human approval can also be re-evaluated when execution resumes rather than treated as a permanent blessing that survives every subsequent change in conditions. [5]
Consider a procurement agent authorized to use a purchasing API and allowed to spend up to $100,000 per day. At 9 a.m. the agent is valid, the tool is within its assigned scope, and almost all of the budget remains available. By 3 p.m. other transactions have consumed $92,000. The agent now proposes a $20,000 purchase. Its identity has not changed, its credential has not changed, and its access to the procurement tool has not changed. The answer to “may this action happen now?” has.
A static credential is a poor container for that decision because the decision itself is not static. Once state outside the credential can change the answer, pretending access and authorization remain the same object gives convenience priority over reality.
Forged Analysis
This is where agent authorization begins to separate itself from ordinary discussions about access. Role-based access control can tell us the procurement agent is allowed to use the purchasing service. It cannot, by itself, know that previous transactions consumed today’s budget, an executive approval expired, another process reserved the remaining capacity, or somebody activated an emergency stop. Those are runtime facts, and once the machine is selecting consequential actions at runtime, some portion of authorization has to move there too.
The more interesting part of AADP comes after the permit. The draft expects the enforcement point to report the outcome back to the decision system. Success, failure, timeout, and refusal to execute are separate states. A permit with no corresponding report remains unresolved rather than quietly being treated as unused authority. [5] The result is a durable boundary between the organization’s recorded intent and whatever external effect may have occurred.
Suppose the agent receives permission to transfer money, calls the payment service, and loses the connection before a response returns. The control plane knows it authorized the action. The agent does not know whether the transfer happened. Blindly retrying can turn a network ambiguity into a duplicate payment, because the missing acknowledgement says nothing definitive about the external side effect.
Distributed systems have been manufacturing this particular misery since long before anybody attached an LLM to a tool. Agents change the operating risk because the recovery decision can now also be automated. A system that interprets “I do not know whether the action happened” as “the action failed” can autonomously turn uncertainty into repeated consequence.
AADP’s separation of permit state, execution reports, and uncertain external effects is therefore more important than another permission check. Authorization without reconciliation governs only the intention to act, while production systems eventually demand evidence about what actually happened.
Counter-pressure
The architecture creates its own load. A policy decision service holding current budgets, approvals, reservations, and kill state becomes a critical dependency. Its consistency matters, its availability matters, and the latency it introduces matters. Fail closed during an outage and legitimate work may stop. Fail open and the organization may discover that its carefully designed authorization boundary disappears precisely when the control plane is unhealthy.
The draft also identifies implementation gaps of its own. Some sender-constrained permit behavior, downstream idempotency mechanics, transport requirements, and portions of the budget model remain incomplete or unexercised. [5] That is normal for work at this stage, but it prevents us from treating the proposal as production doctrine simply because the conceptual distinctions are useful.
Governance has a resource bill. State has to live somewhere, remain current, survive failure, and be operated by people who already had jobs before somebody decided the agent should buy things autonomously. A control that cannot survive its own operating cost eventually becomes the thing people learn to bypass.
Forged Take
The useful principle survives whether AADP itself becomes a standard. Identity tells us which actor arrived, while standing scope tells us what that actor can generally approach. Neither proves that a particular action remains permissible under the conditions that exist now.
For consequential autonomous work, that decision cannot be frozen at login time because the world keeps moving after the token is issued. So does the budget.
3. Google Put Agent Identity Inside the Perimeter
Google giving agents first-class identities is not this week’s story. That work was already underway months ago. The August development is less flashy and more useful because Google is making those identities governable through infrastructure controls enterprises already use to constrain serious workloads.
On August 14, Google made two Agent Identity governance capabilities generally available. Organizations can apply custom Organization Policy constraints to Agent Identity resources, and they can place the Agent Identity and Agent Identity Credentials APIs inside VPC Service Controls service perimeters. [2] The distinction is operational. Naming an autonomous actor gives us attribution. Allowing policy and perimeter controls to act on that identity begins turning attribution into enforcement.
Forge News Breakdown
Google’s Agent Identity architecture gives an agent its own cryptographic principal rather than requiring every autonomous actor to disappear behind a shared workload credential. Current documentation describes integration with IAM policies, Principal Access Boundaries, audit logging, mutual TLS, proof-of-possession mechanisms, and VPC Service Controls. When an agent acts on behalf of an end user, the audit trail can preserve both the agent identity and the user whose authority is being exercised. [3]
The August controls push that identity deeper into ordinary cloud governance. Custom Organization Policy can restrict how Agent Identity resources are configured. VPC Service Controls can place the control-plane APIs managing agent identities and credentials inside a service perimeter. [2] Earlier support had already begun allowing agent principals to participate in VPC Service Controls ingress and egress rules, giving the perimeter something more specific than a generic workload identity to reason about. [4]
None of these controls is individually revolutionary, which is almost the point. The agent is beginning to enter the same administrative world as databases, service accounts, networks, certificates, and other infrastructure that enterprises eventually learned not to govern through vibes.
Forged Analysis
There is a large difference between assigning an identity and making that identity useful to the rest of the system. Architecture diagrams are full of beautifully named components that become remarkably philosophical when asked to stop anything. A first-class agent principal becomes operational when other controls can consume it and make decisions against it.
IAM can grant or deny against the actor. A Principal Access Boundary can constrain the resources it may reach even when another policy attempts to grant more. A service perimeter can recognize the principal crossing a protected boundary. Organization policy can constrain how the identity itself is configured. Audit infrastructure can preserve which agent acted while retaining the human principal behind the delegation. Those controls do different jobs, and preserving those distinctions is more useful than pretending “agent identity” solves all of them.
Suppose several autonomous agents operate inside the same application environment but inherit one shared service credential. The cloud can authenticate the workload and may produce excellent logs showing exactly which service account accessed a protected dataset. What the record does not necessarily preserve is which autonomous actor selected that access or which delegated objective produced it.
A distinct agent principal gives the platform a way to carry that difference forward. The surrounding infrastructure can make enforcement decisions at finer granularity and, where the platform supports it, revoke or constrain one actor without necessarily dismantling every adjacent workload. That is blast-radius control, which is where identity architecture eventually ends up when someone has to operate it rather than present it.
Counter-pressure
A perimeter is not a force field. A correctly identified agent inside the boundary can still be overprivileged, badly instructed, compromised, or legitimately authorized to do something harmful. A policy can be wrong, a downstream service can discard identity context, and a chain of delegation can become less reconstructable as it passes through components that understand only fragments of the model.
First-class identity therefore earns the word “governed” only when enforcement survives end to end. Google can make an agent principal available to IAM and VPC Service Controls, but the organization still has to decide what that principal should be able to do, who sponsors it, how long its authority lasts, where its credentials live, and what happens when trust is withdrawn.
Service accounts are not obsolete either. Deterministic workloads still need workload identity, and plenty of agent systems will continue to execute on infrastructure represented by service accounts or comparable mechanisms. The relevant distinction is whether an autonomous actor becomes independently visible where independent accountability and control are required, not whether every older identity mechanism is ceremonially dragged behind the barn.
Forged Take
The August step is useful because it moves agent identity from description toward enforceable infrastructure. A principal that merely tells us what something is provides attribution. A principal that can be bounded by policy, recognized at a perimeter, audited, and revoked gives operators a control surface.
The badge was never the interesting part. What the doors do with it is.
4. The Breach Was Upstream. That Is the Point.
For several days this month, one of the largest numbers attached to an AI supply-chain compromise was attached to the wrong part of the chain. The correction is not an embarrassment to bury. It produces a better story because it exposes how trust actually propagated.
CloudSEK reported on August 11 that its investigation around the LiteLLM compromise had identified potential exposure involving more than 2,500 organizations and roughly 434,000 CI/CD pipelines. [8] Those figures were widely associated with the malicious LiteLLM releases. On August 14, SecurityWeek reported SOCRadar’s reconstruction showing that 2,085 of 2,188 identified organizations had stopped leaking data before the malicious LiteLLM packages were published. More than 95 percent of that identified population therefore appears to have been exposed through the upstream Trivy compromise or persistence from it, rather than through installation of the poisoned LiteLLM packages. [6] That changes which failure deserves the center of the story.
Forge News Breakdown
Aqua Security’s post-incident account places the beginning months earlier. Attackers first gained access on February 27 by exploiting a vulnerable GitHub Actions workflow in the Trivy project and stealing organization and repository secrets. Remediation did not completely remove attacker persistence. On March 19, stolen credentials were used to publish malicious Trivy artifacts, with malicious Docker Hub releases following on March 22. [7]
LiteLLM was compromised downstream in that trust path. The project reported that PyPI versions 1.82.7 and 1.82.8 were malicious and traced the incident to the Trivy security dependency compromise. The packages attempted to steal credentials and other secrets available on affected systems, and potentially exposed users were advised to rotate credentials. [9]
The corrected chronology matters more than the original victim-count framing. Trivy was compromised. Secrets and trusted build relationships allowed the attacker to persist and move. A downstream project inherited that compromise, and malicious downstream artifacts were then published, creating another opportunity for compromise among their consumers. No single box contains that incident because the failure traveled through trust relationships between boxes.
Forged Analysis
Calling this a LiteLLM breach gives us a simple object and a poor mental model. It invites an organization to ask whether it runs LiteLLM, inspect a package version, rotate some keys if necessary, and congratulate itself for completing the incident-response ritual. The corrected timeline asks a harder question. What upstream components are trusted to influence the software that later enforces our AI controls?
Trivy is a security scanner. It sits in the software-delivery chain precisely because organizations trust it to help decide what may move forward. That position often brings repository access, build-system integration, tokens, automation rights, and a place inside CI workflows. Once those privileges become available to an attacker, the blast radius is determined less by the package’s category than by the authority the surrounding system granted it.
That principle does not stop when the chain reaches AI. An agent gateway is software. A policy enforcement point is software. An identity broker is software. An MCP server is software. The container carrying the agent is software, as is the CI system that assembled it and the scanner that certified it.
We can build a beautifully reasoned runtime authorization model and still place malicious code underneath the enforcement boundary. At that point every policy above it may remain syntactically correct while the system implementing the policy lies. The boring supply chain is part of machine governance because software is eventually where machine authority becomes execution.
The Correction Matters
There is another lesson here because the incident cuts against a bad habit in both incident response and AI governance. CloudSEK’s initial analysis associated a broad exposure population with the LiteLLM incident. Later timeline reconstruction narrowed where most of that activity appears to have occurred. [8], [6] The causal model changed because the evidence improved, which is what a healthy control system should do.
If a post-incident review, risk model, or AI governance process becomes invested in preserving its first explanation, new evidence stops being information and starts becoming a political threat. The result can look like certainty from outside while operationally becoming a system that has lost the ability to correct itself. The original attribution was simpler. The revised one is more useful because it tells us which trust boundary appears to have failed earlier.
There is a useful discipline in that correction for our own reporting as well. A large number is not automatically the strongest fact in a story. If the timeline changes what the number can support, the argument changes with it. Evidence gets to move the conclusion.
Counter-pressure
The corrected timeline does not erase the malicious LiteLLM releases, and it does not turn the broad exposure estimates into confirmed victim counts. The LiteLLM packages were compromised, and users who executed them could have exposed credentials. The 2,500-organization and 434,000-pipeline figures remain investigative exposure estimates rather than a verified count of organizations successfully breached through a single vector. [8], [6]
Those distinctions are not pedantry because attribution decides what we repair. If most exposure occurred through Trivy and its upstream persistence, treating LiteLLM as the primary blast mechanism would direct attention toward the wrong first failure. The visible downstream compromise still matters. It simply was not the beginning of the trust chain.
Forged Take
The lesson for AI operators is larger than “watch your Python packages.” Your runtime authority model has a software supply chain beneath it, and that supply chain inherits whatever privileges the organization gives the components inside it.
If the agent is correctly identified, the policy correctly written, and the action correctly authorized by compromised enforcement code, the governance program has not succeeded. It has documented the wrong reality very carefully.
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] Google Cloud, VPC Service Controls release notes, Google Cloud, June 29, 2026
[5] 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
[6] I. Arghire, Trivy, Not LiteLLM Behind the 2,500 Org Compromise, SecurityWeek, August 14, 2026
[7] Aqua Security, Trivy Security incident 2026-03-19 conclusion, GitHub Discussion #10462, March 30, 2026
[8] CloudSEK, 2,500+ Companies and 434,000 CI/CD Pipelines Exposed in the Largest AI Supply Chain Breach of 2026, CloudSEK, August 11, 2026
[9] BerriAI/LiteLLM, [Security]: litellm PyPI package (v1.82.7 + v1.82.8) compromised - full timeline and status, GitHub Issue #24518, March 24, 2026