Workforce and customer AI agent identity needs different controls

At a glance

What this is: This is a governance analysis of workforce and customer AI agents, showing that both are non-human identities but they require different trust boundaries, scope controls, and audit patterns.

Why it matters: It matters because IAM, PAM, and NHI programmes must separate internal automation risk from external customer-facing exposure, while still applying one identity control model across both.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Aembit's guide to workforce and customer AI agent identity

Context

AI agent identity risk is now a two-sided problem. Workforce agents operate inside the enterprise and may touch internal data, credentials, and orchestration systems, while customer agents sit at the boundary and can expose tenant data or delegated permissions if controls are too broad.

Traditional IAM was built around human authentication and stable roles. That model breaks down when the actor is a non-human identity that can invoke tools dynamically, run continuously, and move across systems at machine speed. The practical question is not whether to govern agents, but how to separate internal blast radius from external tenant exposure without creating new blind spots.

For teams already managing service accounts, secrets, and workload identities, this is not a new category of problem. It is the same governance discipline applied to a more dynamic identity subject, which makes lifecycle, delegation, and audit design the real differentiators.

Key questions

Q: What breaks when AI agent access relies on long-lived secrets?

A: Long-lived secrets let AI agents carry persistent access far beyond the task they were created for. That increases theft risk, complicates offboarding, and makes it harder to prove scope at audit time. Secretless, short-lived access is safer because the credential exists only for the current task and runtime context.

Q: Why do customer AI agents complicate tenant isolation?

A: Customer agents often operate on behalf of a user while sharing infrastructure across many customers. If scopes are not bound to the tenant and session, one agent instance can expose another customer’s data. Tenant isolation must therefore be enforced at token issuance and continuously checked during execution.

Q: What do security teams get wrong about AI agent identity governance?

A: They often assume human IAM patterns can be reused with minor adjustments. That fails because agents can invoke tools dynamically, operate continuously, and combine multiple systems in one session. Governance has to focus on runtime scope, delegated identity, and revocation, not just authentication.

Q: Who is accountable when an AI agent accesses the wrong data?

A: Accountability sits with the team that defined the agent’s scope, the owner of the delegated user context, and the operators who allowed access to persist beyond the task. For customer workflows, audit logs should show both the agent and the user identity so responsibility can be traced clearly.

Technical breakdown

Workforce agents as internal non-human identities

Workforce agents act inside the enterprise trust perimeter and often chain several internal systems in one workflow. That creates a broader blast radius than a normal workload because the agent may read from a data lake, write to a dashboard, and query a secrets vault in the same session. The key technical issue is not whether the agent is useful, but whether its identity is tightly scoped to the task and runtime context. Secretless authentication, short-lived tokens, and conditional access are the control patterns that reduce persistent exposure.

Practical implication: scope internal agent access to one task path and one runtime context, then remove long-lived secrets from the design.

Customer agents and tenant-isolated delegation

Customer agents sit in multi-tenant environments and often act on behalf of an end user, which means the access token has to represent both the agent and the delegated user. That blended identity model is useful, but only if the authorization layer enforces tenant boundaries on every request. Without that, one agent instance can become a cross-customer exposure point. The technical challenge is high-volume verification without weakening isolation, so token exchange, short-lived credentials, and per-tenant scoping become essential.

Practical implication: enforce tenant-specific scopes at token issuance and verify that every request still resolves to the correct customer boundary.

Real-time policy enforcement for AI agent identity

AI agents do not fit static allowlists well because they can change their tool use and action sequence during execution. Access therefore has to be evaluated at runtime, not only at login or first token issuance. Real-time policy enforcement lets an identity control plane revoke or narrow access when posture changes, anomalous behaviour appears, or the delegated user session ends. That is the operational difference between managing a workload and managing an agentic actor.

Practical implication: move from one-time authentication checks to continuous policy decisions that can interrupt an in-flight agent session.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Workforce agents and customer agents are both non-human identities, but they fail differently. Workforce agents concentrate risk inside the enterprise blast radius, while customer agents concentrate risk at the tenant boundary. That distinction matters because identity controls that are sufficient for internal automation can still fail when the same access model is extended to external users. Practitioners should treat the deployment boundary as part of the governance boundary.

Blended identity is the right model for delegated customer actions, but only if the user scope survives every hop. The agent identity determines what the system can do, while the user identity determines what data it can touch. If either side is treated as decorative metadata, the authorisation decision becomes too broad or too narrow. The implication is that delegated access must be evaluated as a combined entitlement, not as a simple session token.

Secretless access is no longer a future-state architecture for AI agents. It is the control line between governable and ungovernable machine identity. Long-lived API keys, embedded credentials, and shared service accounts create persistence that agentic systems do not need. When agents move across systems at runtime, persistent secrets become the weakest part of the chain. Teams that still anchor agent access in static credentials are carrying forward a failure mode human IAM never solved well.

Identity blast radius: the effective damage zone created when one agent identity is allowed to touch too many internal systems or tenants. The article shows that blast radius is not just a privilege problem, it is a boundary problem. In workforce scenarios it maps to internal data exposure, while in customer scenarios it maps to cross-tenant leakage. Practitioners should design for the smallest possible blast radius before they scale agent volume.

Traditional IAM assumptions break when the actor can make runtime decisions about what to call next. Human-centric access review, MFA, and static privilege assignment assume stable patterns of use. AI agents can choose tools dynamically, so the security model has to shift from identity as a person to identity as an execution context. The implication is that programmes need a separate control model for machine-paced delegation, even when the underlying resources are the same.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap makes the case for OWASP Agentic AI Top 10 control mapping and broader runtime governance stronger, not weaker.

What this signals

Identity blast radius: the next governance problem is not simply whether an AI agent is authenticated, but how far one agent is allowed to travel across systems, tenants, and delegated actions before the risk becomes unrecoverable. With 92% of organisations saying AI agent governance is critical yet only 44% having policies in place, the operating model is still ahead of the control model.

Teams that already use the Ultimate Guide to NHIs as a lifecycle baseline should extend that thinking into runtime delegation, because AI agents turn access scope into a moving target. The reader implication is clear: if your programme cannot revoke or narrow access while a session is live, it is not ready for agentic workflows.

The strongest near-term signal is not agent adoption itself but auditability. If you cannot trace what a workforce agent touched, or which customer identity a delegated action relied on, the programme is already operating with an evidence gap that will show up first in incident response and later in compliance reviews.

For practitioners

• Separate internal and external agent trust zones Define workforce and customer agent policies in different trust zones, even if they share the same platform. Internal agents should be constrained by blast radius, while customer agents should be constrained by tenant isolation and delegated scope.
• Replace static secrets with runtime attestation Use workload identity attestation and short-lived tokens for agent authentication so there are no long-lived credentials to rotate or steal. This is especially important when agents invoke multiple internal tools in one workflow.
• Bind delegated access to both agent and user identity For customer-facing workflows, issue credentials that are scoped to the user session and the specific tenant, not just to the agent instance. Audit logs should preserve both identities so investigators can reconstruct the full decision path.
• Automate offboarding for agent credentials Treat agent deprovisioning as a lifecycle event tied to the employee, project, or customer workflow that created it. Revocation should remove access immediately when the business relationship ends, not at the next manual review.
• Enforce real-time policy revocation Ensure the access layer can narrow or terminate an agent session when posture changes, a user logs out, or the task completes. Continuous evaluation is the only way to keep agent permissions aligned with current context.

Key takeaways

• Workforce and customer AI agents are both non-human identities, but the governance failure mode changes from internal blast radius to cross-tenant leakage.
• The scale of the problem is already visible, with 80% of organisations reporting agent behaviour beyond intended scope and only 52% able to audit agent data access.
• Practitioners should shift from static secrets and human-centric IAM patterns to runtime scoping, delegated identity binding, and immediate revocation.

Key terms

• Workforce Agent: A workforce agent is an AI agent used inside the enterprise to perform internal tasks on behalf of employees or systems. It is a non-human identity that may touch databases, pipelines, tickets, or infrastructure, so its access must be scoped to the task and runtime context rather than a person’s standing role.
• Customer Agent: A customer agent is an AI agent that interacts with external users or operates in customer environments. It must protect tenant boundaries and delegated permissions because it often handles sensitive data across shared infrastructure, which makes isolation and auditability more important than broad capability.
• Blended Identity: Blended identity is an authorization model that combines the AI agent’s identity with the human user’s identity for a delegated action. The agent defines what systems can be reached, while the user defines what data within those systems can be touched. This is essential when an agent acts on a user’s behalf.
• Identity Blast Radius: Identity blast radius is the amount of damage one identity can cause if it is misused, compromised, or over-scoped. For AI agents, the measure is shaped by how many systems, datasets, and tenants the agent can reach during a live session, not just by the permissions listed at provisioning time.

Deepen your knowledge

AI agent identity governance and delegated access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for both workforce and customer agents, it is worth exploring.

This post draws on content published by Aembit: Workforce and customer agents and how to secure them. Read the original.