An Agent Is Not a User: What Claude Tag Gets Right, and the Layer It Leaves Open

The market just admitted agents need their own identity

Anthropic shipped Claude Tag, an identity and access model that gives Claude its own account in the systems it touches instead of borrowing a human’s. That is bigger than a feature release. It is the largest vendor in the space saying out loud what anyone running agents in production already knew: lending an agent your credentials was always a workaround, not a design.

They give two reasons, and both match what we have watched happen on our own broker. The first is autonomy: “the length of a task that an AI agent can reliably complete on its own has been doubling roughly every four months.” A credential lent for a thirty-second lookup is a different risk than one held open across an hour of unsupervised work. The second is shared control: “when more than one person is steering, whose permissions apply? There’s no single choice of person that’d be right all of the time.”

Both land where we did when the first multi-agent deployments arrived: an agent is not a user. It needs an identity of its own.

What Claude Tag gets right

It is well built, and the parts it gets right are the hard parts. Claude gets a per-agent service account, “its own account in each system it touches,” so actions trace to the agent and not to a borrowed person. Access is scoped: a workspace baseline with channel-level overrides. Credentials are injected at the network boundary at request time rather than handed to the model, so a prompt-injected agent cannot read its own keys back out. Egress is allow-listed, where “outbound traffic to any host an admin hasn’t allowed is blocked outright.” Revoke the identity and access ends everywhere, and every action is logged.

The framing is the part we like most. It “replaces the question ‘what can this user do?’ with ‘what can this agent do in this compartment?’” That is the right question. We are not here to argue with the model. We are here to mark where it stops.

Three layers it leaves open

Claude Tag secures an agent at the edge of one provider’s environment. The moment an agent talks to something outside that edge, three layers open up that an account-at-the-boundary model does not reach.

The first is transport. Claude Tag governs Claude’s egress from Anthropic’s boundary. It says nothing about the channel between two agents that do not share that boundary. Put a planner on one host and a worker on another, from a different vendor, and the identity that was scoped so carefully at the edge is gone the instant the message is in flight. What carries it is an ordinary socket with whatever auth the two sides happened to agree on.

The second is identity that keeps holding. An account model answers “who is this agent” at login. It does not re-ask on every action. Copy a token off one agent, replay it from another, and a system that checks identity only at the boundary has no second place to catch it. The stolen token is a valid token.

The third is enforcement at the action. An egress allow-list decides which hosts an agent may reach. It does not decide which topics, which messages, which peers. A call that is allowed to reach a host can do whatever that host exposes. The allow-list is a coarse gate, and past it there is no per-action check.

None of this is a flaw in Claude Tag. It is the edge of what identity-at-the-boundary can do. These layers live below it, on the wire, between agents.

Governance is not enforcement

There is a large and growing category of tools for agent and non-human identity: discovery, posture, lifecycle, anomaly detection across the machine identities in an enterprise. It is useful work. But most of it sits beside the path, not in it. It watches, scores, and reports after the fact. An agent moving at machine speed does not wait for a dashboard to notice. By the time a report flags that an agent published where it should not have, the message is delivered. Governance tells you what happened. Enforcement decides what is allowed to happen. You need both, and you cannot substitute the first for the second.

The tools that do sit in the path are mostly HTTP gateways: a chokepoint per integration, configured one route at a time. That is real enforcement, but it is a wall you rebuild for every door, not a fabric every agent speaks by default.

How we do it, and how the spec makes it portable

We have written about the broker side of this before. Our deny-by-default ACLs and per-org mountpoints mean a new identity can do nothing until a rule grants it, and a credential scoped to one tenant is useless against another. Our {$self} ACL rules bind a topic segment to the connecting identity’s own claim, so a single rule covers every agent:

{
  "topic": "agents/{$self}/card",
  "action": "pub+sub",
  "binding": "agent_id"
}

The agent presents a signed JWT at connect. The broker validates it once, then on every publish and subscribe it checks that the segment in the actual topic equals the matching claim in that token. Identity is established at connect; authorization is re-evaluated on every action. Suppose an agent whose identity is scout tries to publish to agents/analyst/card. The bound segment requires scout, the topic says analyst, and the broker denies it before any subscriber sees the message. Not in application code an agent might skip, and not in tomorrow’s audit log. The channel will not carry the message. Pair that with the short-lived credentials we already issue and a leaked token is bounded by both tenant and time.

That is what closes the three layers: identity that lives in the transport, re-checked on every action, between any agents on the connection rather than at one vendor’s edge. And because it lives in the channel, presence and recovery come from the same place. Agents advertise themselves with retained cards, a dropped agent’s last-will message tells the others it left, and on reconnect it picks up the messages it missed.

The open part is the spec. MQTT.Agent carries MCP tool calls and A2A messages over MQTT 5, and its identity-bound ACL profile writes the rule above into a normative form any MQTT 5 broker can implement: JWT at connect, claim-equals-segment on every action, on-behalf-of delegation as a strict intersection of agent and user authority, signed cards, a hash-chained audit record, and revocation that cuts an identity off across every topic at once. It maps onto Anthropic’s vocabulary almost term for term. Per-context identity is the principal. Egress allow-listing is the topic ACL. Just-in-time grants are the short-lived token. The difference is where it runs.

Where this goes

Claude Tag is proof that agent identity is now a product requirement, shipped by the largest vendor in the space. The next step is to make that identity portable: the same identity, with the same enforcement, whether an agent is calling a tool inside one vendor’s environment or talking to an agent on another host run by another company. Identity that only holds inside one boundary is not yet an identity for agents. It is an identity for that boundary.

That is what MQTT.Agent is for, and it is open on purpose. If you are building agents that have to trust each other across a boundary, read the spec at mqtt-agent.dev and tell us where it is wrong. The standard gets better with more people writing it.