Same credential, different right answer
How we Build
The Model Context Protocol’s new roadmap
On 22 August the maintainers of the Model Context Protocol published a roadmap. One of its five priorities is agent identity. They describe the problem plainly. The protocol’s authorisation was built for a person approving access in a browser. The callers now are cloud agents. They act for a user who has left, or hand a narrower slice of their authority to a sub-agent. The named direction is to give each agent an identity built on standards that already exist: Demonstrating Proof of Possession, Workload Identity Federation, standard token exchange. Pasted API keys and long-lived tokens are what those replace. The July release had already removed the protocol’s server sessions, so a server holds no state.
We tell clients that an agent should act as a named identity. Its credential is scoped and short-lived. Its authority narrows each time it passes to another agent, rather than travelling whole. The roadmap is the dominant agent-tool protocol reaching the same position, pushed there by the agents already calling it rather than by anyone’s argument. A client used to ask whether scoped agent identity was a real requirement or a consultant’s preference. The answer now sits on a protocol blog rather than in our deck.
A roadmap is a direction, not a shipped guarantee, and the maintainers mark the delegation path as unfinished. A protocol that offers scoped identity also says nothing about whether a client turns it on. The requirement is about what a client does. The protocol only makes it possible.
How we Assure
An IETF draft for per-action authorisation
On 20 August Shamik Saha published an Internet-Draft, marked work in progress. It defines an Agent Action Decision Protocol. A scoped credential runs two questions together, and the draft pulls them apart: who an agent is and what it may generally do, and whether one specific action, with specific argument values, may run now. The draft’s own illustrations are small ones. An agent authorised to make one payment can attempt a second. A capability as broad as an HTTP client can reach effects its name never declared. The second question turns on state that moves after a credential is issued: cumulative budgets, live reservations, an approval that has lapsed, a kill switch someone has thrown. So the credential can still be valid while the right answer has changed. One rule sits above the protocol’s checks. An irreversible action is never taken without a person.
We hold that every agent acts under its own scoped, short-lived, attributable credential, resolved as it stands. The draft does not argue against that. It argues that the test we set for the statement stops discriminating. Our check reads the credential’s properties: that it exists, is scoped, is attributable. A client can pass every part of it and still let its agents take actions that should now be refused. The credential was decided when it was issued, and the world moved afterwards.
The draft is early. It is one author’s work in progress rather than an adopted standard, and it names its own unfinished parts. A reader could reasonably call the underlying point old. That a credential cannot know a budget changed is a fact distributed systems have lived with since long before agents. The reading is fair. It does not make the point any less true for the client in front of us.
If it holds, we stop offering a scoped-credential audit as evidence that a client’s agents are governed. The check we sell gains a line it does not have. Authority is re-read at the moment of action, against the state that exists then, not only at the moment the credential was cut. The client this reaches has passed the audit and believes its agents are bounded. Its board sees a green report. Its agents can still act on a limit that has already gone.
Trivy, not LiteLLM, behind the compromise
SOCRadar re-examined the data from the LiteLLM supply-chain compromise, and SecurityWeek reported it on 14 August. The firm found per-organisation records for 2,188 entities. For 2,085 of them, ninety-five per cent, data collection had already stopped before the poisoned LiteLLM packages were published on 24 March. That places the exposure earlier, and upstream. It sat in the compromise of Trivy, a security scanner in the build pipeline. The attacker’s first access came on 27 February, through a vulnerable GitHub Actions workflow. Malicious scanner artifacts followed on 19 March. LiteLLM gave the incident its name. It was downstream of all of it.
The estate is the unit of exposure, not the single use case. An organisation that treated this as the LiteLLM incident would have checked whether it ran the package, and on which version. That check looks straight past where nineteen in twenty exposures sat. They sat in a scanner it trusted across every build.
The headline counts from the first report, 2,500 organisations and 434,000 pipelines, are still estimates of exposure rather than confirmed breaches. The reconstruction is one firm’s, reported through a secondary rather than read at source. The direction of the correction is what holds.
The visible casualty carried the name. The trusted scanner carried the exposure.