Yes. Give each AI agent its own identity instead of a shared service account or a person's login. A distinct identity lets you scope permissions tightly, tell agents apart in logs, and revoke one agent without breaking the others. A shared account or a borrowed personal token removes all three.
What goes wrong with shared accounts
Picture three agents using one service account. A log shows the account deleted a record. Which agent did it? You cannot tell. To stop the damage you must revoke the shared credential, which breaks all three.
The same problem shows up when an agent borrows an engineer's personal token. Every action looks like the engineer did it, the agent inherits all of that person's access, and the credential leaves the company when the person does.
What an agent identity should carry
| Attribute | Why it matters |
|---|---|
| Unique name or ID | Separates its actions in every log |
| Named human sponsor | Gives accountability |
| Scoped permissions | Limits blast radius |
| Environment tag | Keeps dev agents out of production |
| Expiry or review date | Stops forgotten agents lingering |
| Credential type and rotation | Limits how long a leak is useful |
Own identity versus the user's context
There are two patterns and they answer different questions. An agent acting for a user should run in that user's context, so downstream systems check what that user may do. OWASP lists this as a mitigation: track user authorization and run actions on downstream systems as that specific user with minimum privileges. An agent running a background job on its own behalf needs its own identity with its own narrow rights.
Many agents do both, which is another reason to keep the identity distinct. The logs should show the agent identity and, when relevant, the user it acted for.
Steps to introduce agent identities
- Inventory agents that already exist. You will probably find some using shared or personal credentials.
- Create one identity per agent per environment. A staging agent and a production agent are separate identities.
- Issue the narrowest permissions that let the agent work, and no standing admin rights.
- Store credentials in a secrets manager, not in a prompt, config file or repository.
- Record the sponsor and a review date.
- Switch the agent to the new identity and revoke the old shared credential.
- Confirm the logs now show the new identity on every action.
Common objections
"It is more work." Yes, once. After that, incident response and audits get far easier.
"We only have one agent." Create the identity anyway. You will have more agents next quarter, and migrating habits is harder than starting right.
"The platform handles identity for us." Check what the logs actually record. If two agents appear as the same principal, you do not have separate identities in practice.
Try it yourself
Click through it at your own pace, or open it full screen. Notice which identity a connected assistant uses when it calls a tool.
Safeguard includes agent identity and asset discovery for finding and governing agents. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Can two agents share one identity if they do the same job?
Avoid it. Separate identities keep logs clear and let you revoke one agent alone.
Should a dev agent and a prod agent share an identity?
No. Use one identity per agent per environment.
Sources
Last reviewed: 19 October 2026.
