Why AI Agents Need Their Own Identities
Sharing a service account or piggy-backing on a user breaks attribution, audit, and least privilege for AI agents. Each agent needs its own identity.
Why AI Agents Need Their Own Identities
The Core Idea
Every AI agent that takes action in your environment — calling APIs, accessing data, sending messages, modifying records — needs a dedicated, uniquely identifiable identity.
Not the user's identity. Not a shared service account. Not an unscoped API key.
Its own.
Why It Matters
A unique identity per agent is the foundation for:
- Attribution — knowing which agent did what.
- Authorization — applying least privilege per agent.
- Audit — clean logs that map actions to agents.
- Lifecycle — creating, modifying, retiring without affecting others.
- Incident response — containing one agent without breaking others.
- Compliance — meeting frameworks that require per-actor identification.
What Goes Wrong With Shared Identities
1. Lost Attribution
Two agents share a service account. Audit log shows the SA called an API — but which agent? Which use case? Which user delegated?
2. Over-Permissioning
Shared SA accumulates permissions for every agent that uses it. Each new agent adds more; no agent can be tightly scoped.
3. Inability to Revoke
You discover Agent A has a vulnerability. You can't disable its identity without breaking Agents B, C, D that share it.
4. Compliance Gaps
Auditors ask, "Which identity took this action and why?" You can't answer cleanly.
5. Multi-Tenant Bleed
Shared identity used across customers / tenants → cross-tenant data exposure if scoping fails.
6. Unknowable Blast Radius
Shared identity = aggregated blast radius across all agents using it. Compromise one prompt-injected agent and you've compromised the union.
What Goes Wrong When Agents Use a User's Identity
1. Ambient Permissions
User has access to many systems beyond what the agent needs. Agent inherits all of it.
2. Lost Distinction
Audit log shows actions as the user. Was it the user or the agent? Did the user authorize this specific action?
3. Compromise Blast Radius
User compromise = agent compromise (and vice versa).
4. Authorization Confusion
Approval flows that ask "did you do this?" can't distinguish user from agent.
5. Data Boundary Issues
User authorized to access broad data; agent should only access narrow slice for the use case.
What "Own Identity" Means in Practice
Cloud / SaaS Identity
- Microsoft Entra ID: dedicated app registration / managed identity per agent.
- Google Cloud: dedicated service account per agent.
- AWS: dedicated IAM role per agent.
- SaaS (Salesforce, ServiceNow, Workday): dedicated user / connected app per agent.
Authentication
- Federated where possible (Workload Identity Federation, OIDC, mTLS).
- OAuth 2.0 client credentials with rotated secrets where federation isn't possible.
- No long-lived static API keys where avoidable.
Authorization
- Least-privilege scopes per agent.
- Tools and data explicitly enumerated.
- Where the agent acts on behalf of a user, use OAuth on-behalf-of (OBO) flows with bounded scopes.
Naming and Tagging
- Predictable naming (e.g.,
agent-<purpose>-<env>). - Tags: owner, business unit, classification, model used, version.
Lifecycle
- Created via approval workflow.
- Reviewed periodically.
- Retired when use case retires.
Real-World Examples
1. Shared Connector → Per-Agent Identity
A finance team's three agents (Invoice Reader, Expense Approver, Vendor Lookup) all used a shared Salesforce integration user with broad permissions. After splitting into three connected apps, each with minimal scope, the audit trail became clean and effective permissions dropped 75%.
2. Copilot vs Custom Agent Confusion
Microsoft 365 Copilot and a custom Power Automate agent both ran under the same service principal. Audit logs blurred the two. Splitting into separate principals enabled distinct policies and clearer incident response.
3. Agent Inheriting User Permissions
A user's broad SharePoint access flowed into an agent acting on their behalf. Adversary triggered the agent (prompt injection in a shared document) → confidential SharePoint sites accessed. Bounded the OBO scope to specific sites; mitigated.
4. Multi-Tenant SaaS Agent
A SaaS vendor's agent operated under a single identity across all customers. A bug allowed cross-tenant data lookup. Per-tenant identity isolation introduced; bug class eliminated.
Best Practices
- One identity per agent; never share.
- Federation / OAuth for credentials; no long-lived keys.
- Least-privilege scopes, tool-by-tool, data-by-data.
- Bounded OBO when acting on behalf of users.
- Naming convention and tagging.
- Owner per agent.
- Approval workflow for new agent identities.
- Periodic review (quarterly).
- Decommissioning playbook when use case retires.
- Audit log per agent identity, integrated with SIEM.
Checklist
- Each agent has its own identity?
- No shared SAs / connected apps across agents?
- Federation / OAuth used?
- Least privilege per agent?
- OBO bounded for on-behalf-of flows?
- Naming and tags consistent?
- Owners documented?
- Approval workflow live?
- Quarterly review?
- Decommissioning playbook?
How Forestall Helps
Forestall identifies:
- Shared identities used by multiple agents.
- Agents using user identities (OBO without bound scope).
- Agents without owners.
- Permissions bloat per agent.
- Stale agent identities.
Frequently Asked Questions
Doesn't one-identity-per-agent create sprawl?
Yes — and that's why governance, owners, and lifecycle matter. The cost of sprawl is far less than the cost of shared identity blowups.
What about agent ensembles / multi-agent systems?
Each role/agent in the ensemble should have its own identity. The orchestrator may have its own broader identity governing the ensemble.
Can I scope a shared identity instead?
You can — but you lose attribution. Most teams find per-agent identity cheaper to maintain than per-action attribution analysis.
What about ephemeral agents?
Use just-in-time identities (federation tokens, short-lived OAuth) tied to the agent's logical name and lifecycle.
What if the platform doesn't support per-agent identity?
Push the platform vendor; meanwhile, isolate scope as much as possible and enrich logs to attribute actions to specific agents (correlation IDs).
Conclusion
Every AI agent needs its own identity. It's the foundation for attribution, least privilege, audit, lifecycle, and incident response. Shared identities and user-impersonation hacks may seem easier but create exactly the blind spots that turn agents from productivity boosters into outsized risks. Govern agent identities like any first-class identity — and your agentic AI program will scale safely.
Give every AI agent its own governed identity.
Forestall discovers shared identities used by agents and helps you split them into per-agent identities.