How should security teams govern workforce and customer AI agents differently?

Why workforce and customer agents need different governance models

Workforce agents and customer agents fail in different ways because they sit on different trust boundaries. A workforce agent usually acts inside an employer-controlled environment, so the main concern is limiting internal blast radius, controlling what it can touch, and preventing it from being repurposed across systems. A customer agent is exposed to external users and tenants, so the bigger concern is request-level isolation, tenant binding, and preventing one customer context from bleeding into another.

The governance question is therefore not “how do we secure agents generally?” but “which actor model are we governing?” That choice changes who owns policy, how identity is delegated, what approval model is acceptable, and how much separation must exist between a request, a session, and the underlying permissions.

For workforce agents, policy should be centred on internal authorisation boundaries, human approvals for sensitive actions, and scoping access to the minimum systems needed for the job. For customer agents, governance must assume untrusted input, externally initiated interactions, and a need to bind each action to the right tenant, user, and execution context. A pattern that is safe for internal automation can still be too coarse for customer-facing use.

Where the control emphasis shifts between internal and external agents

Workforce agents are usually easier to anchor to an existing enterprise identity, but that does not make them low risk. They often inherit broad reach through internal APIs, SaaS tools, or delegated credentials, so the control question becomes whether the agent is confined to a narrow task scope and can be revoked quickly when its behaviour changes. AI Agent Authorisation Guide is a useful reference point for this pattern because it focuses on task-scoped access, per-action decisions, and human approval gates.

Customer agents need a different model because the user boundary is no longer internal trust, it is multi-tenant exposure. The governing principle is that each request must be attributable to the correct customer context and isolated from every other context, even when the agent is sharing infrastructure, models, or orchestration layers. That is why delegated identity and tenant binding matter more than simply “logging in” the agent once.

Lifecycle matters in both cases, but for different reasons. Workforce agents should be discovered, registered, reviewed, and retired like internal automation. Customer agents should be governed like externally facing services, with stronger controls around onboarding, entitlement changes, and request mediation. Agentic AI Identity Guide is relevant here because it frames identity, delegation, registration, and retirement as a full lifecycle rather than a one-time setup.

What breaks when one IAM pattern is reused for both

The common failure is to apply a single identity pattern that looks elegant on paper but hides different risks in practice. If internal-style broad delegation is reused for customer agents, the result is overexposure and weak tenant separation. If customer-style per-request friction is forced onto workforce automation, the result can be brittle operations, excessive manual approval, and shadow workarounds that bypass governance entirely.

Another common mistake is to treat the agent itself as the only principal that matters. In reality, the right question is whether the agent is acting on behalf of a human, a business process, or an external customer session. When that distinction is unclear, audit trails blur, approvals lose meaning, and access reviews become performative instead of effective. Zero Trust for AI Agents is useful because it frames verification around the agent, the principal, and the request rather than assuming one identity model fits all.

Teams also underestimate how quickly customer-facing agents become authorization problems, not just conversational ones. Once an agent can initiate actions, retrieve data, or pass tokens downstream, policy must decide whether the action is allowed for that customer, in that tenant, at that moment. That is why a customer agent often needs stronger request binding and narrower runtime permissions than an internal agent with similar functionality.

Risk and Threat Considerations

Reusing a workforce-style model for customer agents creates a direct exposure path: a single weak trust assumption can let one tenant influence another tenant’s data, actions, or context. Reusing a customer-style model for workforce agents can also create risk, but more often through operational drag, approval bypasses, and hidden privilege sprawl than through tenant breakout.

Failure mechanism: The agent is granted permissions too early, too broadly, or without strong binding to the right principal and tenant, so request context becomes the only thing separating safe behaviour from unsafe behaviour. In customer scenarios, that can enable cross-tenant leakage or unauthorized actions; in workforce scenarios, it can turn internal automation into a high-blast-radius control plane.

Impact: The organisation can end up with data exposure, misattributed actions, hard-to-revoke access, and governance blind spots that only appear after the agent has already been deployed at scale.

Practitioner Guidance

Decision rule: If the agent is serving employees, optimise for tightly scoped internal authority, fast revocation, and limited system reach. If it is serving customers, optimise for per-request delegation, tenant binding, and isolation strong enough that one request cannot inherit trust from another.

What to verify: Check whether the agent’s permissions are tied to a single purpose and whether the request context is preserved all the way through execution. If you cannot explain who approved the action, for which tenant, and under which policy, the model is too weak for customer use.

What practitioners underestimate: The right design is often asymmetric. Workforce agents usually need stronger blast-radius controls, while customer agents usually need stronger boundary controls. Treating them as the same class of automation is the fastest route to either overprivilege or isolation failures.

Practitioner takeaway: Govern the agent according to the trust boundary it crosses, not the technology stack it uses; internal automation should be constrained by blast radius, while customer-facing automation must be constrained by delegation and tenant isolation.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams govern AI agents and NHIs differently?
• How should security teams govern customer identity differently from workforce IAM?
• How should security teams govern AI support agents that resolve customer conversations end to end?