Why Your AI Should Not Log In As You

Open the dashboard of an AI agent your team built last quarter and you will almost always find the same setup. The agent is logged in as alice@company.com, with alice's full permissions to the database, the code repo, the Slack workspace, and the customer billing tool. Alice has admin rights because alice is a senior engineer. The agent, by inheritance, also has admin rights to everything alice can touch.

This feels efficient. The agent uses the same credentials alice uses. Setup took five minutes. The team moves on to building the actual workflow.

Six months later, an incident happens. Production gets pushed at 3am. Someone's monthly billing report goes out wrong. A customer secret leaks into a Slack thread. The audit trail is checked. Every entry says alice did it. Alice did not.

The conflation problem

When an AI agent uses a human's account, two completely different actors get squashed into one row in every log. A human with judgment, accountability, and a memory of yesterday. And a model running a workflow at machine speed with no memory across sessions and no concept of personal consequence. They share the same name in the database, the same email in the audit trail, the same blame in the incident review.

The audit trail post argued that AI agents need their own audit record because they fail differently from code. This post is the sibling argument: AI agents need their own IDENTITY because they ACT differently from humans. Authentication answers who acted. Audit answers what they did. Both halves are needed. See the audit trail post for the other half.

Three properties of an AI agent's identity

Forget for a moment which IAM you use. Imagine the cleanest description of what an AI agent's identity should be. It collapses to three properties.

This is not your IAM vendor's problem to solve alone

Identity vendors are good at humans. They are good at service accounts. AI agents are a new principal type that does not quite fit either old box: long-running but stateless, autonomous but constrained, fast but auditable. Every major IAM platform is racing to add agent-shaped primitives right now. Microsoft Entra ID is retiring service-principal-less authentication, and competing platforms are publishing similar guidance.

The good news is that this is not a fight between identity vendors and AI vendors. It is a place where both win. A clear agent identity makes the IAM vendor's product more useful, because they get a new principal class to govern. It also makes the AI vendor's model more deployable, because enterprises feel safer letting a model touch real systems when the system can answer the question "who acted, exactly?"

The boundary you need lives one layer above your IAM and one layer below your AI. It is where the agent gets its scoped identity issued, used, and revoked.

The hidden cost of the expedient setup

The reason teams keep shipping agents on borrowed human logins is not laziness. It is that the expedient path is invisible. There is no error. There is no compile failure. The agent works. The pain shows up later, in one of three ways.

One. The first incident. Someone has to explain to leadership why the engineer named in the audit log claims they did not do the thing the audit log says they did. The audit log was technically correct. It just recorded the wrong actor.

Two. The first audit. SOC 2 or ISO 27001 or any framework that requires identity attestation suddenly cares whether your service principals match your actual actors. They do not.

Three. The first scale moment. The agent that worked fine for ten users a day now runs a thousand times a day, against half your tooling, with everyone's shared admin login. Anyone who joins or leaves the team finds their login behaving in strange ways. Rotation becomes a quarterly project.

This is not just for Fortune 500

The temptation, especially for small teams, is to assume agent identity is enterprise paranoia. It is not. AI-first startups feel the pressure to separate their agents from their founders' accounts faster than enterprises do, because there are only two or three founders, every action shows up in their personal name, and the next investor due-diligence will ask about it. The smallest teams have the loudest blast radius. Optionality on identity is exactly the same shape as optionality on model: keep the surface narrow so swapping the actor is cheap.

Where UniversalBench fits

UniversalBench gives your AI agent its own scoped credentials to your systems through the vault. Your IAM stays your IAM, whichever one you have chosen. The agent gets the smallest possible identity surface, with credentials that the model itself never sees in plaintext. When the agent's job changes, the scope changes. When the agent is rotated out, its credentials are revoked in one step. The boundary holds even when you switch models, swap your IAM provider, or move from a startup to an enterprise contract.

We do not replace your identity provider. We do not generate JWTs your IAM cannot understand. We make the agent a first class principal on top of the identity stack you already trust. Works with Claude, ChatGPT, Gemini, and any MCP compatible AI. See the safe database access post for how the vault fits in to the larger picture.

How to start without breaking your current setup

If your current agent is on a borrowed login, the migration is gentler than it looks. Four steps.

One. Inventory. List every place an agent currently logs in as a human. Database, code host, ticket tracker, billing, Slack, calendar. Most teams find five to ten surfaces.

Two. Issue. Create a distinct principal in each system for the agent. Name it after the agent's job, not after a person. "billing-report-agent" beats "alice-ai".

Three. Scope. Give that principal the smallest set of permissions the workflow actually needs. Resist the urge to grant admin "just in case." If the agent needs more later, expand explicitly.

Four. Rotate. Make the agent's credentials short-lived from the start. Even a 24-hour token is dramatically safer than a permanent key. Wire rotation into the vault, not the calendar.

Common questions

I am not on Microsoft Entra. Does this still apply? Yes. The Microsoft retirement is the loud version of an industry-wide shift. Okta, Auth0, Google Workspace, AWS IAM, every major identity platform is moving in the same direction. The principle is universal, the deadline is most acute on Entra.

Can I just give the agent a service account and call it done? A service account is the start, not the end. You also need scoped capabilities, short-lived credentials, and an audit trail that names the agent as the actor. A long-lived service account with admin rights is not much safer than a borrowed human login.

What if multiple agents share the same workflow? Give each agent its own identity even if they share a workflow. Two billing report agents with separate principals are dramatically easier to debug than one shared principal that suddenly runs at double the rate.

How does this interact with MCP servers that use a single API key? The MCP key should belong to the agent, not the company, and should authorise only the calls the agent's job needs. If your MCP gateway holds one organisation-wide key for every agent, you have re-created the borrowed-login problem at a different layer.

An AI agent that uses your login is a contract you did not sign. An AI agent with its own identity is a colleague your company can hire, scope, and let go of. The difference between those two relationships is small in setup time and enormous in everything that comes after.