Every AI Agent Needs Its Own Identity, Not a Borrowed One

AI agent identity is where good intentions most often meet shortcuts. A developer needs an agent to reach a database, so the agent borrows an existing service account, a person’s credentials, or a key pasted straight into the prompt. It works, the demo goes well, and the shortcut quietly becomes production.

Identity, Access, & Secrets is Domain 2 of the Homegrown Agent Maturity Model for Execution & Risk (HAMMER), and it’s where the homegrown difference is easiest to see. With a bought agent, identity controls usually exist, and your job is to configure and verify them. With a homegrown agent, the control doesn’t exist until your teams build it. Standing up identity issuance is engineering work that nobody will ship on your behalf.

Borrowed Credentials, Shared Consequences

At Level 1, agents run on shared or human credentials, or on hardcoded keys. Privileges are broad and standing, and secrets live in code and prompts. The practical symptom is easy to recognize: revoking one credential breaks several agents, because several agents were using it.

That symptom points to a deeper problem. If five agents share one service account, the logs show the account acting, not the agent. Any investigation starts from a guess. This is the pattern behind identity and privilege abuse, one of the elements cataloged in the OWASP Top 10 for Agentic Applications, and it gets worse as agents gain access to more tools.

Level 2 improves the picture without fixing it. Some agents get dedicated service accounts, but access is granted ad hoc and tends to be over-permissioned. Secrets are only partly vaulted. Most agents can reach far more than they ever use, which is exactly what an attacker, or an injected instruction, would want.

A subtler version of the shared-account problem survives even a dedicated account, because “dedicated” does not necessarily mean “distinct”. On platforms that issue a service principal (the identity an application uses to authenticate) per registered application, teams often register one application per agent and treat the principal as the agent’s identity. It looks like identity governance, and if only one agent ever uses it, attribution works today. But the principal identifies the application, not the agent. Nothing in the directory records that the two are the same, and nothing stops a second agent joining the app. A one-to-one mapping kept by convention is an assumption; one you can prove from live configuration is a control.

What Level 3 Looks Like

The shift at Level 3 is that every agent has its own distinct non-human identity (NHI) in your directory, mapped to a defined role. Secrets are vaulted, and access is reviewed periodically. It sounds basic, and it is. It’s also the point at which attribution becomes possible, because an action can finally be tied to a single agent rather than a shared account.

Two practical tests tell you whether you’re really here:

• Can you name the identity each production agent uses?
• Can you revoke one agent’s access without touching another’s?

If either answer is no, the program is still operating at Level 2.

Even then, attribution is per agent, not per run. When one agent hands work to another, whose permissions travel with the task? Every identity can be distinct and correctly scoped, and the chain can still do something none of them was approved to do. That gap is what Domain 7 (Execution Visibility & Risk) measures, and no identity control closes it on its own.

From Standing Access to Purpose-Bound Access

Level 4 ties least privilege to each agent’s purpose. Credentials are short-lived or issued just in time, and tool and data permissions are attested and monitored for drift. A useful marker is that credentials expire in hours, and a scheduled review flags any permission that has grown since the last one.

Drift is the quiet risk here. Consider an agent built to draft contract summaries. At launch, it can read the contracts repository and write to a drafts folder. Over the following months, a developer adds a calendar tool, then an email tool, each one “temporarily.” Each change passes review on its own. The combination (read contracts, send email) is an exfiltration path nobody approved as a whole. A purpose-bound model catches this because the permissions are compared against the agent’s stated purpose, not just against whatever it had last week.

Where Identity Heads at Level 5

At the top of the model, identities are fully brokered. Permissions are dynamically right-sized to observed behavior, and there are zero standing secrets. If an agent behaves abnormally, its access is revoked automatically, and there are no long-lived secrets left to steal.

Few organizations need Level 5 everywhere, and that’s fine. The model is built for deliberate progress, not perfection. What matters is knowing which level each of your agents sits at, and whether the evidence is real. For identity, real means the logs show which credential each agent actually used, and a search of the environment finds no secrets the vault doesn’t know about. A directory entry is a claim; the logs are the proof. The same posture applies to securing AI agents across the lifecycle: define the identity at build time, enforce it at runtime, and verify it continuously.

Score Your Identity Posture

Identity is often the fastest domain to improve once a team agrees on the target, because the steps are concrete: issue distinct identities, vault the secrets, shorten the credentials, and review drift on a schedule.

Download the HAMMER eBook to see all five levels of Identity, Access, & Secrets, and find out where your agents stand today.