Every AI agent that reads a database, opens a ticket, sends an email or changes cloud infrastructure needs an identity. That identity may be a service account, workload identity, API key, OAuth client, access token or certificate. Collectively, these are non-human identities—and they are becoming one of the most important security boundaries in agentic systems.
The issue is not simply the number of credentials. AI agents can choose tools, chain actions and operate at machine speed. A credential that once supported one predictable integration may now be used by a model across a flexible workflow. If permissions are broad or ownership is unclear, a prompt injection or compromised tool can turn credential misuse into cross-system impact.
The Cloud Security Alliance’s 2026 research describes how AI adoption magnifies existing non-human identity problems involving visibility, ownership, credential lifecycle and token sprawl. This guide translates that challenge into practical architecture, testing and governance steps.
What is a non-human identity?
A non-human identity is a digital identity used by software, machines or automated workloads rather than a person. Common examples include:
- Service accounts used by applications and background jobs.
- API keys issued to integrations or scripts.
- OAuth clients, refresh tokens and access tokens.
- Cloud workload identities and assumed roles.
- Machine certificates and mutual TLS identities.
- Kubernetes service accounts.
- CI/CD runners and deployment identities.
- Bots, robotic process automation and AI agents.
An identity is more than its credential. It has an owner, purpose, permissions, trust relationships, creation path, rotation method, logs and retirement date. Security failures often occur because organisations manage only the secret while ignoring the lifecycle around it.
Why AI agents raise the risk
Traditional machine identities usually perform a defined operation: copy a file, query a table or deploy a build. An AI agent may decide which operation to perform after interpreting a natural-language request and untrusted data. This creates several differences.
First, the execution path is dynamic. A support agent might search customer records, update a case and send a message during one task, then use a different sequence during the next. Static allowlists based only on application name may be too broad.
Second, the agent can receive indirect instructions. A malicious line in a document or ticket can influence how it uses an otherwise valid token.
Third, agents may delegate to sub-agents or external tools. Authority can spread across multiple identities and systems, making it difficult to reconstruct who initiated an action.
Finally, pilots often run with convenient shared service accounts. Those permissions can quietly become production dependencies before security teams establish ownership, rotation and monitoring.
The most common identity failure modes
Shared, over-privileged service accounts
One credential is used by several agents or workflows because setup is faster. It becomes impossible to attribute activity accurately, revoke one workflow without breaking others or apply task-specific permissions.
Create separate identities for distinct agents and environments. A research assistant does not need the same authority as a deployment agent. Production and development must never share credentials.
Long-lived API keys
Static keys are copied into environment files, notebooks, workflow tools and prompt configurations. They may remain valid after the original owner or application changes.
Prefer short-lived, automatically issued credentials. Where static secrets remain necessary, store them in a secrets manager, rotate them automatically and monitor every use. Never place secrets in prompts or tool descriptions.
OAuth scope inflation
An integration requests a broad scope because it is easier than determining the minimum. An agent that needs to read a calendar may receive permission to edit events, contacts and mail.
Review scopes at the operation level. Separate read and write clients when possible. Use incremental authorization so additional authority is granted only when a user requests a feature that requires it.
Lost user context
The front end authenticates a person, but downstream tools run only as the agent’s service account. The target API cannot determine which user requested the action, so it grants the agent’s full authority.
Preserve user and tenant context through the workflow. The target system should authorize the user, agent, action and resource rather than trusting the agent’s identity alone.
Orphaned identities
An experiment ends, but its tokens, roles and service accounts remain active. Nobody owns the identity, and normal access reviews overlook it.
Require an owner and expiry at creation. Connect identities to a service catalogue and automatically disable them when the workload is retired or ownership disappears.
Credential exposure in telemetry
Prompts, tool arguments, traces and error messages can contain authorization headers, signed URLs or tokens. Observability platforms then become an unexpected secret repository.
Redact credentials before logging. Restrict trace access, define retention and test whether secrets appear in model-provider logs, analytics tools or support exports.
A secure identity architecture for AI agents
Give every agent a distinct identity
The identity should represent a specific workload, environment and owner. Names should make purpose clear. Avoid credentials shared across unrelated tools or teams.
This improves attribution and containment. If one agent is compromised, responders can revoke it without disabling the entire automation estate.
Use short-lived, workload-bound credentials
Prefer federation and workload identity over stored secrets. Bind tokens to the intended service, audience, environment and session. Use brief expiry and automatic renewal so stolen credentials have a limited useful lifetime.
Where supported, sender-constrained tokens or mutual TLS can reduce replay. The exact mechanism varies by platform, but the principle is consistent: possession of a copied bearer token should not be sufficient forever from any device.
Apply least privilege at three levels
Agent permissions should be constrained by:
- Tool access: which tools the agent may call.
- Operation access: which actions within a tool are allowed.
- Resource access: which tenants, records, repositories or environments may be affected.
A model instruction such as “do not delete records” is not enforcement. The API must deny deletion when the identity lacks permission.
Preserve delegated user identity
When an agent acts for a person, pass verifiable user context and re-authorize at the target. This prevents a low-privilege user from borrowing the agent’s broader service authority.
Record both actors in logs: the human principal who initiated the task and the non-human principal that executed it. For delegated chains, retain the complete lineage.
Put an authorization gateway before tools
A central tool gateway can enforce schema validation, policy, rate limits, approvals and logging. It should make deterministic decisions using identity and business context, not ask the model whether an action is allowed.
High-risk operations should require a separate confirmation that displays the exact target and effect. An agent must not be able to generate both the request and the evidence of approval.
Design revocation and isolation from the beginning
Security teams need a fast way to disable one token, tool or agent without a broad outage. Test the kill switch. Verify that cached tokens, queued jobs and active sessions stop working after revocation.
Our guide to zero trust for AI agents expands on continuous authorization and runtime enforcement.
Building a non-human identity inventory
An inventory is useful only if it supports decisions. For each identity, capture:
- Unique identity and credential type.
- Business and technical owners.
- Agent, workload and environment using it.
- Creation source and approval record.
- Target systems and OAuth scopes or roles.
- Data classifications it can access.
- Whether it can read, write, delete, deploy or administer.
- Credential issue, rotation and expiry dates.
- Last-used time and normal usage pattern.
- Dependencies that would be affected by revocation.
- Incident contact and shutdown procedure.
Discover identities from cloud IAM, secrets managers, source repositories, CI/CD platforms, API gateways, SaaS administration consoles and endpoint telemetry. Compare the discovered set with the service catalogue. Differences reveal shadow automation and forgotten experiments.
Security testing methodology
Test discovery and ownership
Can the organisation identify every identity used by the agent? Are tokens created dynamically visible? Does each identity have an active owner? Attempt to find credentials in code, configuration, build logs, prompt traces and collaboration tools.
Test horizontal authorization
Use two ordinary users or tenants. Ask the agent to access, modify or export the other identity’s objects. Change identifiers in direct tool calls. A successful request with the wrong tenant context indicates that the backend is trusting possession of an ID or the agent’s broad role.
Test vertical authorization
Starting with an ordinary role, attempt administrative operations through natural language, alternate tools and direct APIs. Verify that approval and server-side policy block the action even if the model chooses the correct admin tool.
Test token scope and audience
Try using a token against another service, environment or endpoint. Verify expiry, audience validation and scope enforcement. Check whether refresh tokens can obtain more authority than the original grant.
Test replay and revocation
Capture a benign test request and replay it after logout, expiry, role change and explicit revocation. Confirm that queued jobs and agent memory do not preserve usable credentials.
Test indirect prompt injection
Place a harmless instruction in a document or tool response asking the agent to reveal a synthetic secret or perform a prohibited read. The objective is to confirm that untrusted content cannot redirect identity use.
Test logging and detection
Generate unusual cross-tenant requests, rapid tool calls, failed privilege escalation and access from a new environment. Confirm that logs include human identity, agent identity, tool, action, resource, policy decision and outcome.
Detox’s AI agent red teaming checklist contains additional scenarios for connected agents.
Monitoring signals that matter
Traditional login alerts are not enough for non-human identities. Look for behavioural and lifecycle signals:
- A dormant identity suddenly becoming active.
- A token used from an unexpected workload or region.
- New tools or resources accessed for the first time.
- Read-heavy behaviour followed by an external write.
- Repeated authorization failures and identifier changes.
- Unusual token issuance, refresh or scope expansion.
- Activity after an owner, agent or integration was retired.
- An agent accessing secrets unrelated to its declared task.
- High-impact actions without a corresponding approval event.
Baseline normal behaviour by workflow, not merely by IP address. Agents may operate from shared cloud infrastructure, so task, tool and resource context are often more informative.
Incident response for a compromised agent identity
Prepare the response before deployment. A practical playbook should:
- Pause the agent and block new tool calls.
- Revoke active tokens, refresh tokens, sessions and derived credentials.
- Disable or quarantine the workload identity.
- Preserve prompts, tool calls, policy decisions and target-system logs.
- Identify the initiating human or external input.
- Determine which systems and data the identity could reach.
- Review actions performed during the exposure window.
- Rotate downstream secrets that may have been read.
- Remove poisoned memory, documents or tool definitions.
- Retest controls before restoring service.
Revoking one API key may be insufficient if the agent exchanged it for other tokens or created persistent access. Trace the complete credential chain.
Governance metrics for leadership
Useful metrics measure control, not the sheer number of identities:
- Percentage of agent identities with named owners and expiry.
- Percentage using short-lived credentials rather than static secrets.
- High-risk agents with documented least-privilege reviews.
- Time required to revoke an identity and stop active sessions.
- Orphaned or inactive identities awaiting removal.
- Tokens found in code, prompts, traces or logs.
- Agent actions carrying verified user and tenant context.
- Coverage of horizontal and vertical authorization tests.
These measures show whether the organisation can prevent, identify and contain misuse.
How penetration testing supports identity governance
An access review shows intended permissions. Penetration testing shows whether those permissions can be bypassed, combined or misused in the real workflow. A scoped penetration testing engagement can examine the agent interface, APIs, OAuth flows, service accounts, tool gateway and target systems together.
For API-heavy architectures, the cloud API security testing checklist provides complementary controls. The highest-value tests use multiple identities and verify actual server-side results rather than relying on a chatbot refusal.
Frequently asked questions
Are non-human identities the same as machine identities?
Machine identity is commonly used for certificates and workload authentication. Non-human identity is a broader term that also includes service accounts, API keys, OAuth clients, bots and agent identities. The security principles overlap substantially.
Should each AI agent have its own service account?
Generally yes, and separate identities should be used for different environments or materially different workflows. This makes least privilege, monitoring and revocation more reliable.
Can a system prompt enforce least privilege?
No. Prompts can guide behaviour but are not an access-control boundary. Target APIs and authorization gateways must enforce permissions deterministically.
How often should credentials rotate?
Prefer short-lived credentials that expire automatically. Rotation frequency for unavoidable static secrets should reflect risk, but organisations should also rotate immediately after suspected exposure, ownership change or material scope change.
What is the first practical improvement?
Choose the agent with the broadest permissions, identify every credential it uses and map each allowed action. Remove unused permissions, split shared credentials and test revocation. This usually reduces risk quickly while exposing inventory gaps.
Conclusion
AI agents make identity security an execution-control problem, not merely a secret-storage problem. A secure agent needs a distinct identity, short-lived credentials, preserved user context, deterministic authorization, narrow tools and complete action logs.
Begin with visibility: identify every agent identity, owner, permission and target system. Then reduce standing privilege and verify enforcement through cross-user, cross-tenant, replay and revocation testing. Finally, prepare to contain misuse without disabling unrelated services.
When identity is designed into the agent workflow, prompt injection and tool compromise have a smaller blast radius. When one broad credential is allowed to stand in for every user and action, even a minor model mistake can become a serious security incident.
