Last month I wrote about how the standards are moving towards delegation, not impersonation. And now Anthropic went the other way and built agent identity on service accounts. I've hit loads of friction with that model since I started building agents on service accounts myself. I think it's simple but incomplete. But it's really built for old-school enterprises already drowning in service accounts. The ones who know exactly how that story ends.

Anthropic put Claude inside Slack this week. It's called Claude Tag. You @Claude in a channel like a coworker, it reads the thread, runs the task, posts back. It's a nice product. But buried in it is an identity decision that cuts against pretty much everything the rest of the field has been saying for a year and I've been sitting with it.

Quick recap of where I stood. Last month I argued the most important decision in agent identity is delegation, not impersonation. Don't let the agent borrow Alice's token and just become Alice. Keep her as the subject and put every agent that touched the request in the chain.

To be clear, that was never "act as the user." The agent still gets its own identity in my model. It's a non-human identity, same family as a service account. Alice doesn't become the actor and the agent doesn't borrow her login. The difference is only whether that identity stays tied to the human who asked, or stands on its own.

And I wasn't alone on this. Pavel Anni at Red Hat said it cleanly: "instead of becoming you, the agent receives a scoped set of privileges." Uber ships it in production across thousands of agents, with a token that carries the whole actor chain:

{ "sub": "alice", "act_chain": ["alice", "oncall-agent"], "aud": "mcp-gateway" }

That's their writeup, riding on OAuth Token Exchange (RFC 8693). The whole field basically converged here. Delegation. Keep the human in the token.

And now Anthropic shipped the opposite.

Claude Tag doesn't act on behalf of anyone. It acts as itself. Its own service accounts, set up by an admin, one per connected tool. No personal credentials in play, ever. Noah Zweben, who wrote it up, reframes the whole question. Not "what can this user do?" but "what can this agent do in this compartment?" And the compartment is the Slack channel.

They're not wrong to do it. In a shared channel with three engineers and a PM all talking, whose token should Claude even use? There isn't a clean answer. So they stopped pretending there was one.

So who is it, at the database?

A person in the channel who has zero access to the prod repo tags Claude. "Go read the repo, find the slow query." Under the model I've been preaching, the database sees Alice, riding a delegation chain: { "sub": "alice", "act_chain": ["alice", "claude"] }. Alice is right there in the token, accountable.

Under Claude Tag, the database sees the channel's service account. Alice isn't in the picture anymore. The channel is.

Same action, two very different lines in the audit log:

# delegation: the human is in the record
actor=claude  on_behalf_of=alice  action=repo.read  object=prod-db

# acts as itself: the compartment is the record
actor=svc-claude@platform-eng  action=repo.read  object=prod-db

Your auditor doesn't ask which channel did it. They ask who. That second line has no answer. Pick a standard. PCI DSS, say. It wants every action tied to a named individual. No shared accounts. Knowing you owe that is due diligence. Producing the name when asked is due care. A channel service account is a shared account by design. There's no name to give. "The channel did it" is not the answer you hand a regulator after an incident.

You can read this two ways. One way, a person with no repo access just pulled data out of the repo by asking a bot. Anthropic's way, an admin granted that channel that access on purpose, Claude never borrowed Alice's credentials, so a shared channel "can never serve as a backdoor into someone's private documents." The blast radius is the channel and the channel is the thing you reason about. It really does depend on who's doing the security review.

The steelman, because I think they might be right

The delegation camp, me included, has a blind spot. We assume there's always a human to delegate from. But long-running, multiplayer agent work often doesn't have one. You can't put an approval prompt in front of an agent that's been running for six hours while everyone's asleep. So "acts as itself" is an answer to a case the rest of us mostly hand-waved past. I'm not here to dunk on it.

It's worth being precise here, because three things keep getting mushed together. Impersonation: the agent borrows Alice's token and becomes her. Everyone agrees that's a trap. Acts as itself: the agent gets its own identity and the human drops out of the record. That's Claude Tag today. And a third way: the agent has its own identity and still carries the human who asked. So the fight was never whether the agent should have its own identity. Agents are non-human identities, they already outnumber the humans in most companies many times over, of course they get their own. The fight is whether that identity floats free of the human, or stays tied to them. Acts as itself cuts the tie.

And there are two things the compartment gets right that I glossed over. One is shared memory. If the agent only ever sees what Alice sees and Alice logs off for the day, the next person can't ask it to pick up where it left off, the agent just gets amnesia. The shared room is what gives a team a shared memory to work in. Two is that delegation isn't clean in a crowded room either. If the agent fetches a log on the lead engineer's token, the PM sitting in that same channel just got indirect access to systems they were never meant to touch. So it isn't that the compartment is bad and delegation is good. Both models leak in a multiplayer room, just in different places.

What still keeps me up

A couple of things, really.

1. Attribution: I spent a whole post hammering one sentence: can you answer who did what, when and why for a single agent action. Anthropic logs every call. The open question I can't settle from the docs is whether the log names the human who asked or only the compartment. For a bank under SoD controls, that's not a small gap. That's the whole audit finding.
2. The deputy: The channel's service account carries whatever scopes an admin gave that channel. Read-only warehouse in one channel, write in another. So channel membership quietly becomes the authorization boundary and anyone in the room borrows whatever the room can reach. That's a classic confused deputy. Eric Broda frames the bigger version of it: auth proves the actor, the sandbox shrinks the blast radius, but something still has to decide, per action, whether this action belongs in this context. And nothing does, yet.

Theo Browne hit the same gap from the other side and I think he's right. You can't put that decider inside Claude Tag. The harness rides on one lab. You can't reach in to add a gate and what runs behind that service account isn't yours to swap either. So whatever decides whether an action belongs in the room has to sit outside the harness, at the action boundary.

Anthropic kind of answers this themselves, in their own roadmap. What's next, they say, is an "identity-aware overlay": Claude acts only when both the channel's profile and the requesting user's own permissions allow it. Read that again. That's the user's identity coming back into the decision. That's delegation, walking back in through a side door. Aembit already has a name for it, "blended identity", the agent's identity and the human's, both in the call.

And my own blast-radius line has a hole. A channel isn't a fixed wall. Membership churns, the room remembers, so the compartment you reasoned about on Monday isn't the same one your auditor opens in March. Joanne Jang poked at that memory side, a "monotheistic" Claude that knows different things in different channels.

So "acts as itself" might not even be the opposite of delegation. It might just be where you start and delegation is the thing you end up bolting back on once a channel stops being a fine enough line.

Could be wrong. It's three days old and I'm watching one product. Plenty of people wrote it up, HelpNetSecurity, The New Stack, all accurate, all describing what shipped. Nobody really asked the identity question though.

So I will. And if you run agents, run the test yourself. Open your audit log, pick one agent action from today and see whose name is on it. The person who asked? Or just the room it happened in? Then ask which one your auditor can live with.

Here's where even the loudest fans of this model and I land in the same spot. The non-human-identity crowd, the people who've wanted agents to carry their own identity for years, will tell you the same thing: identity tells you who the agent is, not whether what it did was okay. You still need something watching behavior at runtime. The name on the badge was never the hard part. The dark room is everything after it.

What can actually go wrong

This is really a service-account problem. If you've run a big enterprise, you know how service accounts age. Nobody tracks them. They pile up access. They outlive the people who made them. Claude Tag inherits all of that, with an AI on top. A few gotchas, all straight from Anthropic's own docs.

Revoking isn't the off switch you think it is. Delete the access bundle and, in their words, "the credentials are removed; memory, routines and transcripts are not." A running session can even hold a revoked credential for a short window.

The trifecta is open. Claude reads untrusted content, a Slack message or an email or a doc it pulls through a connector. It holds the channel's access to your systems. And it can reach any host on the allow-list. That allow-list is a host-level control, it doesn't really look at the payload and allow-list-only hosts get the request "without credentials". One planted instruction and a usable sink and your data walks out. Nothing in the docs inspects what leaves.

Your access rule has a hole named Owner. You restrict who can invoke Claude and then, verbatim: "Members on a preset role like User or Owner are granted access regardless of role configuration." So the rule you carefully set up doesn't actually touch your most privileged people.

Routines outlive the people. A standing job "keeps running if the creator leaves the organization." Offboarding doesn't stop it. And anyone in the channel can disable a routine, including the one you set up to catch problems. That's the old service-account offboarding nightmare, back again.

The bill counts too. Ambient work can run for hours with no salary cap, so set a spend limit before the first invoice shows up.

I want to keep this fair. Claude Tag is in public beta. Some of these are on Anthropic's own roadmap, the controls that exist are real and most are just off by default. I'm genuinely not saying don't use it. I'm saying turn it on knowing what each switch does and who it quietly doesn't cover.

So before you @Claude into a channel, the questions I'd want answered: what can it reach, what can it spend, what can it leak and what's still alive after you think you've turned it off?

So which one do you actually reach for?

I keep getting asked the practical version of all this, which model to reach for and when. So here is my first cut at a decision tree. It is a draft and I am sure it is wrong somewhere, so tell me where.

The short version. If a regulator needs a human name on the action, you want delegation, the compartment will fail that audit. A single-user personal agent, delegation again, it is the simplest thing that stays accountable. A shared room doing low-risk work like reading or summarising, the compartment is fine, just scope the room to its least-privileged member. A shared room doing something high-risk like writing to prod or moving money, you are into blended, where the room and the human both have to say yes, which is really just delegation walking back in.

And the red line at the bottom is the bit I keep coming back to. Whichever branch you pick, the room is still dark. Identity gets you to the door, not to what happens inside.

This is a first thought, not the last word. If you run agents and you would draw the tree differently, I genuinely want to hear it.

---

Sources: Claude Tag: an agent identity and access model (Anthropic) · Claude Tag: agent identity · Claude Tag: security and data · Zero trust for AI agents: why delegation beats impersonation (Red Hat) · Solving the Agent Identity Crisis (Uber) · OAuth Token Exchange (RFC 8693) · Anthropic's zero-trust agents (Eric Broda, Agentic Mesh) · Blended identity (Aembit) · Anthropic Claude Tag agent identity model (Help Net Security) · Anthropic Claude Tag in Slack (The New Stack) · Agent identity, in four layers (raxIT)

Trying to work out whether your agents act as themselves or on someone's behalf and what your audit log can actually answer after an incident? Talk to our team to discuss your specific deployment context and governance needs.