A Teardown of Claude Tag's Agent Identity conceptSign in

Sign inBook demoTry PromptQLpath]:stroke-[#030712] ml-1" width="23" height="22" viewBox="0 0 23 22" fill="none" xmlns="http://www.w3.org/2000/svg">

25 Jun, 2026<br>8 MIN READ

A Teardown of Claude Tag's Agent Identity concept<br>figure:first-child]:mt-6 [&>.h2-wrapper:first-child]:mt-6 [&>p:first-child]:mt-6">strong]:text-[#111111] font-normal leading-[166%] tracking-[-0.17px] [&>.button]:mt-4 last:pb-0 mb-7">Anthropic's recent post on strong]:text-[#349864] [&>strong]:hover:text-[#2C5610]">Agent Identity for Claude Tag is, to put it mildly, a bad idea.

For the uninitiated, "Agent identity" is the idea of giving a multiplayer AI agent a static set of privileges that are defined per-channel or per-group ACL, regardless of who is interacting with it. This means that either the AI is useless or is a "confused deputy" security risk waiting to blow.

Calling "Agent Identity" a new paradigm is disingenuous when the more secure and more useful approach of enforcing user-identity is a one line fix. Instead of making HTTP calls directly to the tool with a fixed service account, pass an HTTP client that adds the user's credentials for that tool.<br>strong]:text-[#111111] font-normal leading-[166%] tracking-[-0.17px] [&>.button]:mt-4 last:pb-0 mb-7">Unfortunately for Anthropic, providing this alternative would mean that the entrypoint would have to be a different (diy or otherwise) tool that provides security features on internal IT resources.<br>strong]:text-[#111111] font-normal leading-[166%] tracking-[-0.17px] [&>.button]:mt-4 last:pb-0 mb-7">Let me break down the post's key claims and points.<br>Claim #1: "Act as user" breaks down because it doesn't allow increasing agent autonomy

Agents now schedule their own tasks for later and respond to events long after the person who asked has logged off.<br>strong]:text-[#111111] font-normal leading-[166%] tracking-[-0.17px] [&>.button]:mt-4 last:pb-0 mb-7">Have the agent keep a long-lived token to act on behalf of the user when accessing data or a service. For external services, OAuth server-side authentication is literally built to solve this problem.<br>Claim #2: "Act as user" breaks down because it's not clear who's permissions should be used in a shared thread

...e.g., a channel where three engineers and a PM are debugging together. But 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.<br>strong]:text-[#111111] font-normal leading-[166%] tracking-[-0.17px] [&>.button]:mt-4 last:pb-0 mb-7">Have the agent take the permissions of whoever it is responding to. This is what a human would do and is a natural and expected experience. If the PM asks to update the spec, allow it. Disallow the engineers. If the PM wants to update DNS, disallow it, but allow the engineers.<br>Claim #3: [Agent identity…] is unusual, but we think it is a necessary step toward an access model that works for autonomous, multiplayer agents

strong]:text-[#111111] font-normal leading-[166%] tracking-[-0.17px] [&>.button]:mt-4 last:pb-0 mb-7">It is definitely unusual. But it's definitely not a necessary step for anything. In fact, later on in the post, they say:<br>an identity-aware overlay for organizations with more complex clearance structures. This will add user-level checks on top of an agent’s scope, so Claude only acts when both the channel's profile and the requesting user's own permissions allow it.<br>strong]:text-[#111111] font-normal leading-[166%] tracking-[-0.17px] [&>.button]:mt-4 last:pb-0 mb-7">Lol, wut. Just use user-identity in the first place.<br>Claim #4: Channels are a security boundary for scoping memory and access

strong]:text-[#111111] font-normal leading-[166%] tracking-[-0.17px] [&>.button]:mt-4 last:pb-0 mb-7">> Memory and access respect those boundaries: what Claude learns in a private channel never appears in the wider workspace.

strong]:text-[#111111] font-normal leading-[166%] tracking-[-0.17px] [&>.button]:mt-4 last:pb-0 mb-7">This is not a feature. This is what we already have today by building agents per channel. This is a bug. The feature in a multiplayer AI would be to allow an AI to safely learn from private channels and apply it in other places.

Claim #5: Agent Identity makes it easy to secure and audit

strong]:text-[#111111] font-normal leading-[166%] tracking-[-0.17px] [&>.button]:mt-4 last:pb-0 mb-7">> …because Claude acts under its own service accounts, those actions also land in each connected system's own logs.

strong]:text-[#111111] font-normal leading-[166%] tracking-[-0.17px] [&>.button]:mt-4 last:pb-0 mb-7">Again, this is not a feature. This is a huge problem because there is no security / audit process that is built around "the slack channel". Security / audit is built around users and data. If something goes wrong, saying that it went wrong in the frontend-engg slack channel is not helpful.<br>So why is Anthropic shilling such an obviously bad...