TL;DR: Enterprises are deploying AI agents on both sides of the firewall, but workforce agents and customer agents create different identity risks, from internal blast radius to cross-tenant leakage, according to Aembit. The governance gap is not access alone, but the assumption that human IAM patterns can govern machine-speed delegation.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “Workforce Agents vs. Customer Agents: Identity, Access, and Security Explained”.
Key questions
Q: How should security teams govern workforce and customer AI agents differently?
A: Treat workforce agents as internal automation with blast-radius risk and customer agents as externally exposed, tenant-isolated actors.
Q: Why do AI agents increase access risk compared with fixed workloads?
A: Because an agent can assemble its access path at runtime, the true blast radius is not always known at provisioning time.
Q: What breaks when AI agent access is managed like standard IAM access?
A: What breaks is the assumption that access is stable, reviewable, and tied to a single human owner.
Practitioner guidance
- Define separate control models for workforce and customer agents Map internal automation to internal blast-radius controls and customer-facing automation to tenant isolation, delegated identity, and external trust boundary controls.
- Replace long-lived secrets with short-lived agent credentials Eliminate stored API keys and service account passwords where agents can authenticate through workload identity, token exchange, or runtime attestation.
- Bind delegated access to user context For customer agents, enforce blended identity so the agent can act only within the end user’s scope and the tenant’s data boundary.
Bottom line: Workforce and customer AI agents need different identity controls because they operate inside different trust boundaries and create different failure modes.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Workforce agents and customer agents are not variations of the same IAM problem. They share the fact that both are non-human, but their trust boundaries diverge enough that one policy stack will inevitably misfit one of them. Workforce agents amplify internal blast radius, while customer agents create tenant isolation pressure and delegation complexity. The practitioner conclusion is that access strategy must start from actor context, not from a single agent label.
A few things that frame the scale:
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What should teams do when customer agents act on behalf of users?
A: Enforce blended identity so the agent’s capability is always constrained by the user’s permission set and the tenant boundary. That prevents a shared agent instance from reusing the wrong context across customers and keeps delegated actions auditable at the right scope.
👉 Read our full editorial: Workforce and customer AI agent identity needs different controls