An agent needs an identity of its own: something that proves which agent is acting, limits what it can reach, and can be switched off in one place.
This guide covers the three identity models, the lifecycle, and how the same identity drives web controls through an AI agent allow list at the egress point.
Many agents today run under a developer's key or a shared service account. Four problems follow.
Each problem gets worse as the number of agents grows, which is why identity is best fixed early.
Logs show a person or a shared account, not the agent.
Revoking a shared key breaks every agent using it.
A developer's key carries a developer's rights.
Keys outlive the agents and projects that used them.
Most organisations need all three. Pick per agent, based on who the agent acts for.
The choice decides who approves access, whose name appears in logs, and who is accountable for mistakes.
The agent acts for the organisation, as itself.
The agent's runtime proves who it is, with no stored secret.
The agent acts for one person, with a narrow slice of their rights.
Treat each stage as a checkpoint with an owner and a record.
Skipping a stage is how orphaned identities appear. Retirement is the stage most often forgotten.
One identity per agent, named with its registry ID, linked to a human owner.
The agent proves it is itself through workload attestation or a secret kept in a vault, never in a prompt.
Roles and data access match the task. Web page types are set in its policy file.
Minutes to hours, refreshed automatically while the task runs.
Every sign-in and every request carries the agent ID.
Disable the identity, revoke everything, and deny its traffic at egress.
The agent's identity should travel with every request. Then each enforcement point can apply that agent's own rules.
Decides which internal systems the agent may reach.
Decides which tools this identity may call.
Loads this identity's web policy and checks page types.
Identity management usually stops at your own directory. Agents can create identities elsewhere, by signing up on other websites.
Those accounts are tied to your company's email and name, but no internal tool will ever list them.
Delegation is the most common model for assistants, and the easiest to get wrong.
Ask these five questions of every delegated agent before it goes live.
| Question | Unsafe answer | Safe answer |
|---|---|---|
| What rights does the agent get? | All of the person's rights | A task-scoped subset |
| How long does it last? | Until revoked | Until the task or session ends |
| Whose name is in the log? | Only the person's | Both the person and the agent |
| Can it sign up or buy for the person? | Yes, anywhere | Only with the person's approval each time |
| Can the person see what it did? | No | Yes, a list of actions per session |
Most organisations start with agents on the wrong identities. A steady migration fixes it without breaking anything.
List agents using personal keys or shared service accounts.
One per agent, with narrow roles.
Move the agent, then watch its denials for a week.
Only after the agent has run cleanly on its own identity.
Identity touches several teams. Agree who does what before the first migration.
| Task | Owner |
|---|---|
| Create and retire identities | Identity team |
| Choose the identity model | Agent owner with the identity team |
| Approve roles and data access | System and data owners |
| Set web page policy for the identity | Network security |
| Review identities quarterly | Identity team with agent owners |
Each of these is common, and each makes incidents harder to contain.
They end up in logs and model context.
No way to revoke just one.
The agent looks like the person in every log.
A leak stays useful for years.
"research-bot" in one system, "svc-rb" in another.
Accounts agents create elsewhere go unnoticed.
Vendor agents usually act with the identity of the user who switched them on. Push for something narrower.
Raise these four points in the security review before the feature is enabled for everyone.
As the user, or as its own identity?
Limit OAuth scopes and set an expiry.
Ask for logs that distinguish the agent from the user.
With its identity model in the agent registry.
Report these monthly to show identities are under control.
Keep the numbers few and stable, so the trend is easy to read from month to month.
Target: every agent.
Trending down.
Target: zero.
Per agent, from egress logs.
Short definitions for readers new to agent identity.
An account that belongs to the agent itself.
Identity proven by where the agent runs, with no stored secret.
A narrow slice of a person's rights, lent to an agent.
Proof, from the platform, that a workload is what it claims.
How long a credential stays valid.
An account an agent created on another website.
Identity sprawl rarely arrives in one step. It grows quietly, one convenient shortcut at a time.
The pattern below is typical. Spotting which stage you are in tells you how much clean-up is ahead.
A developer connects an agent with their own key. It works, so nobody changes it.
Other teams copy the pilot, and the same key now powers four agents.
Products you already pay for add agent features that act as whoever enabled them.
Their key is disabled, and several agents stop working at once.
Someone asks which agent did what. The logs only show a person who no longer works there.
Creating an identity is easy. Proving, on every request, that the caller really is that agent is the hard part.
Choose the strongest method your runtime supports, and move up the list over time.
| Method | Strength | What can leak | When to use it |
|---|---|---|---|
| Workload attestation | Strongest | Nothing stored | Agents on managed cloud or container platforms |
| Certificate from an internal authority | Strong | A private key, if copied off the host | Agents on servers you control |
| Secret fetched from a vault at start | Medium | The secret, while in memory | Agents that cannot use attestation yet |
| Static key in a config file | Weak | The key, forever | Only as a short bridge during migration |
| Key pasted into a prompt | None | Everything, into logs and model context | Never |
A full identity programme takes time. These five steps reduce risk quickly and need no new platform.
Each one also makes the next audit easier to pass.
Scan prompt templates, agent configs and repositories for secrets, then rotate every one you find.
Pick the key used by the most agents and give each of them its own identity.
Start with a day if an hour feels too tight, then shorten it.
Pass it in a header so the proxy records which agent made each request.
This stops agents creating outside accounts while the rest of the work goes on.
Agent identity work meets the same few objections in most organisations.
Short, practical answers keep the project moving.
Test agents reach real websites and real data. Give them an identity too, with a short expiry.
One identity per agent is more accounts, but each one is simple. Shared accounts are fewer, but impossible to control.
Record the gap in the registry, limit the grant, and raise it at renewal.
Automatic refresh handles long tasks. Breakage during testing shows where refresh is missing.
Auditors now ask about agents in access reviews. Keep this evidence ready so the answer takes minutes, not weeks.
Every agent, its identity, its model and its human owner.
Who approved each role, and when.
Quarterly sign-off by each owner, with changes made.
Identities disabled, with the date and reason.
The page types each identity may reach, under version control.
Egress log lines showing blocked signups and payments, by agent.
Leaders do not need the mechanics. They need to know three things, in plain words.
Use the points below as the opening of a quarterly update.
Each one has its own identity and a named owner.
In one place, without breaking the others.
Logs name the agent, not just a person or a shared account.
The honest fine print — the same two assumptions we publish, plus two operational ones
Deny signup, login and password reset pages on 40M+ domains.
