Anthropic introduced an 'agent identity access model' that gives AI agents their own separate accounts and permissions inside corporate systems, instead of having them borrow human employees' credentials. The change means every action an agent takes is logged under its own identity, and its access is scoped to only what the job requires — eliminating the security and auditing problems that come from agents impersonating people.
Key facts
- What: As AI agents start working in teams alongside people, the old 'the bot acts as you' model breaks down. Anthropic's answer: give each agent its own scoped account in every system it touches.
- When: 2026-06-24
- Primary source: read the source
In a blog post, Anthropic laid out the model: when an AI agent does work inside your company's systems, it should have its own account, not borrow yours. Until now, when you ask an assistant to open a pull request on GitHub or post a message in Slack, it does so on your behalf — using your permissions, acting as you. That works when a person is in the loop, clicking the button. But AI agents increasingly run on their own, for hours, long after the person who started them has logged off. They also increasingly work in shared spaces — a team channel that a dozen people steer — where there is no single 'you' whose permissions should apply. As Anthropic puts it, 'Claude isn't acting on behalf of a single user. It has its own account in each system it touches.'
The analogy is a temp worker versus a borrowed badge. The old model is like handing the new contractor your own employee badge so they can get through doors while you are out. It works, but it is a security nightmare: everything they do is logged as you, they inherit every door your badge opens including the ones they should never enter, and if they make a mistake, it looks like you made it. The new model is like giving the contractor their own badge, encoded with access to exactly the rooms their job requires and nothing else. Anthropic's version works at the workspace level: an administrator defines what an agent can connect to — this code repository, this data warehouse, this customer system — and each channel inherits a tailored set of permissions. The agent's identity in a legal team's channel, in their example, simply cannot reach the engineering team's code, because that access was never granted there.
The security payoff is the whole point. Because the agent uses its own service account rather than impersonating a person, a shared channel can never quietly become a back door into someone's private files. Every action the agent takes is logged under its own identity, so when you audit what happened, you see what the agent did as the agent, not a confusing trail that looks like an employee did it. That clean separation matters more as agents gain real power, and it speaks directly to a worry covered in the story about a hidden escape hatch in safety controls — the more autonomy these systems have, the more it matters that their access is bounded and visible.
This is the unglamorous infrastructure that has to exist before 'teams of AI agents working alongside people' becomes something a real company can run without a security team having a heart attack. It is the same shift every technology goes through as it grows up — from a clever demo that borrows a human's credentials to a managed system with its own accounts, permissions, and audit logs. It is also the deeper story under the headlines about agents writing most of a company's code: once the labs themselves rely on agents that author the majority of their production code, those agents need identities, access boundaries, and accountability just like any employee would.
The honest caveat is about where the hard problems move, not whether this is a good idea — it plainly is. Giving each agent its own scoped account is clearly better than the badge-sharing free-for-all it replaces. But it shifts the difficulty onto the humans configuring it. Permission systems are notoriously easy to get wrong: set them too tight and the agent cannot do its job, set them too loose and you have recreated the over-broad access you were trying to escape, just with extra steps. And an agent with its own standing account that runs unattended is, from an attacker's point of view, a new kind of target — a login that is always on and answers to no single person watching it. The model is the right direction. Whether organizations actually configure it carefully, rather than clicking 'allow all' to make the agent work, is the part that will determine if it makes them safer or just busier.
Originally published on Ground Truth, where every claim is checked against the primary source.
Top comments (0)