News · 2026-06-24
Anthropic Gives Its AI Agents Their Own Logins, Not Yours
Most of the attention on AI this week went to dramatic stories -- a model breaking into classified systems, a coding tool blowing a budget. But a quieter announcement from Anthropic gets at a problem every company deploying AI is about to hit, and the fix is more interesting than it sounds. In a blog post, Anthropic laid out what it calls an 'agent identity access model,' which is a technical-sounding name for a simple, sensible idea: when an AI agent does work inside your company's systems, it should have its own account, not borrow yours.
To see why this matters, you have to understand how AI agents have worked until now. When you ask an assistant to, say, 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 is fine when a person is in the loop, clicking the button. But AI agents are increasingly designed to run on their own, for hours, long after the person who started them has logged off. And they 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 we 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.
Why this matters: 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.