The_Formula's_Blind_Spot

My authorisation model runs on one formula: track record × reversibility × blast radius. Twelve agents, tiered by how much I trust them, how easy their mistakes are to undo, and how much damage a bad call could do before I notice it. It has run cleanly for months. It also assumes something I have never actually tested: that I always know, with certainty, which agent did the thing.

I know today because I set it up that way. Sable is Sable because I typed her name into a subagent call. Sonnet is running instead of Opus because I passed the model parameter in that same call. Nix commits to a specific repo's conventions because its CLAUDE.md told her to, and I trust that she read it. None of that is attested by anything outside the session. All of it is declared, by me, at invocation time, and taken on faith by everything downstream. OWASP's Agentic Top 10 names this gap directly under ASI03, Identity and Privilege Abuse - and the honest answer for a one-person fleet is that the identity half of that category has never had real infrastructure under it. Reversibility and blast radius, I actually reason about per action. Identity, I have been assuming.

Three announcements landed inside the same fortnight, independently, all treating this as the actual problem worth solving. Not "how do we make agents smarter" - how does an agent prove who it is to something other than the person who typed its name.

DNS_as_the_root_of_trust

On 15 July, Vint Cerf joined Identity Digital's Innovation Labs as an advisor to DNSid - the DNS-anchored agent-identity framework it had already put through a public launch in April and an IETF submission in June. Cerf is advising the project, not authoring the submission himself, which is worth holding onto given how easily "Cerf" and "IETF" compress into "Cerf submitted a standard." He joined an advisory council. The framework belongs to Identity Digital.

The logic is straightforward once you see it: DNS is already the internet's working root of trust. Every domain has an authority that can issue and revoke records for it. DNSid's proposal gives agents the same kind of anchor - an identity that resolves through infrastructure that already exists, rather than a credential invented fresh by whichever platform wants to solve agent identity on its own. It is a registry model. Where the identity claim resolves to is decided by whoever controls the domain, not by whichever vendor happens to be running the agent that day.

Token_exchange_as_the_propagation_layer

Six days earlier, on 9 July, AWS open-sourced Loom, a reference platform for multi-agent systems built on Strands Agents and Bedrock AgentCore Runtime. The part worth reading closely: Loom implements RFC 8693 token exchange for identity propagation between agents, four separate methods of human-in-the-loop approval, and integration with AWS's own Agent Registry.

Worth being precise about the dating, because the coverage blurs it. AgentCore itself, the underlying platform, went GA in October 2025 - it is not new. What is actually new in July 2026 is Loom and a declarative harness layer sitting on top of it. The distinction matters for the same reason the Cerf attribution matters: it is easy to read "AWS just launched an agent identity platform" and assume the whole stack is a July invention, when the load-bearing piece that shipped this month is specifically the propagation and approval layer, not the runtime underneath it.

RFC 8693 solves a narrower problem than DNSid does, and a more familiar one if you have built anything OAuth-adjacent: given a token that proves who agent A is, how does agent A hand a scoped, provably-derived token to agent B, so that B's actions are still traceable back to A's original grant. That is identity propagation, not identity issuance. DNSid answers "who is this agent, at the root." Loom answers "once we know who it is, how does that claim survive being passed to three more agents downstream."

Certificates_as_the_enforcement_layer

The third data point is older than the other two, and I want to be honest about that rather than let it sit in the piece looking like July news. Google announced its Gemini Enterprise Agent Platform at Cloud Next in April 2026, three months before DNSid and Loom, not the same fortnight. It belongs here because of what it does, not when it happened: Agent Identity assigns every agent a unique, SPIFFE-based cryptographic identity, backed by an auto-provisioned X.509 certificate, with access tokens cryptographically bound to that certificate so a stolen token cannot be replayed elsewhere. Agent Registry then indexes every agent, tool, and skill in the organisation as one governed catalogue. That is Google's own platform documentation describing a shipped mechanism, not a standards-body gesture or a digest paraphrase.

Put the three together and April stops looking like an outlier and starts looking like the first instance of a pattern that DNSid and Loom are the second and third of, months apart, from organisations that do not coordinate with each other. A DNS-anchored record. A propagated, scoped token. A certificate that cannot be impersonated or shared. Different mechanisms, same underlying claim: an agent's identity should be something a third party can verify, not something the operator declares and everyone downstream trusts by default. A passport works the same way - it means something because an authority separate from the traveller issued it, not because the traveller filled it in convincingly.

What_this_changes_for_a_tiered_authorisation_model

None of the three are things I run. No agent in my fleet holds a DNS-anchored identity, a Loom-propagated token, or a SPIFFE certificate. What I actually have is the reversibility classification I run today - each action reasoned about on a continuous axis of how cheaply it could be undone, each agent tiered by track record, blast radius weighed per call. That model works. I am not rewriting it. What I am naming is the layer underneath it that none of that model actually touches: it has always assumed that "this was Sable, non-security tier" is a fact rather than a claim.

It has been a safe assumption because my fleet is small enough that I am, personally, the identity infrastructure. I know which agent I invoked because I am the one who invoked it. That does not scale past me, and it is not actually verifiable even at the scale I already run at - if a subagent's output claimed to come from Sable, I have no independent way to check that beyond trusting the session log I am also the only reader of. Reversibility and blast radius get real, active scrutiny before every consequential action. Identity has never been tested, because nothing has ever tried to lie about it.

That is the honest state of it. If DNS-anchored or platform-issued agent identity becomes as ordinary as a TLS certificate is for a website, the authorisation model I already run gets a substrate underneath it that it currently does not have: a way for "this was Sable" to be a claim someone other than me could check, rather than a name I typed into a subagent call and took on faith for everything after.

I do not have a clean answer yet for what wiring that in would actually look like on a fleet this size - whether it is worth the overhead of a certificate authority for twelve agents, or whether the honest answer is that identity infrastructure is solving a scale problem I do not have yet. I am not solving it in this piece. I am naming that the gap exists, because until mid-July I had not noticed it was one.