Treat cloud IAM as the control for where the agent can execute, and treat federation, SCIM and app authorization as the control for who the customer is and what they can reach. If both are merged into one layer, offboarding and tenant isolation become ambiguous. Separate ownership, separate policies and separate audit expectations are the safer model.
Why Runtime IAM and Customer Access Need Different Control Planes
Agent runtime IAM answers a different question from enterprise customer access. Runtime IAM governs where the agent executes, what it can call, and which environment permissions it inherits. Customer access governs who the tenant user is, what tenant they belong to, and which business objects or functions they can reach. Keeping those control planes separate avoids mixing operational authority with tenant entitlements.
The practical benefit is clearer blast-radius control. A cloud role or workload identity can be short-lived, tightly scoped, and owned by the platform team, while customer identity can follow federation, directory sync, and application authorization rules owned by the product or IAM team. When those concerns are collapsed into one layer, policy changes for one side can unexpectedly alter the other.
How the Boundary Should Be Drawn in Practice
Use the runtime layer for execution trust and the customer layer for business access trust. Runtime controls should decide whether the agent can start, which resources it can invoke, and whether it can reach a given service boundary. Customer controls should decide whether a person may sign in, which tenant they belong to, and which records, workflows, or administrative functions they can use.
This separation works best when the agent never acts as a surrogate customer identity. Instead, the agent should hold its own machine or workload identity, then receive narrowly scoped authorization to perform a task on behalf of the platform. Customer federation and SCIM then remain responsible for onboarding, offboarding, group membership, and tenant membership, without becoming entangled with infrastructure permissions.
That design also makes audits easier. Security reviewers can inspect one set of evidence for runtime permissions, secret handling, and execution boundaries, and a different set for customer provisioning, entitlements, and deprovisioning. It is much easier to prove that a platform role was revoked than to prove that a blended identity was both safely deprovisioned and still usable for the right tenant.
Where Merged IAM Breaks Down
Merged models usually fail first at offboarding and isolation. If the same identity object is used for both agent execution and customer access, removing a customer can leave behind residual runtime authority, or revoking runtime access can accidentally break legitimate customer access paths. That creates ambiguity about ownership, incident response, and who is accountable for the final revoke.
They also fail under scale. In multi-tenant systems, tenant isolation depends on predictable boundaries, not on whoever last updated the shared identity. If the runtime layer and the customer layer share policies, one mis-scoped change can broaden access across tenants or across environments, especially when automation reuses tokens or templates too aggressively.
Risk and Threat Considerations
When runtime IAM and customer access are merged, the main risk is authority confusion: a control meant to govern execution can accidentally grant business access, or a customer change can alter agent reach. That raises exposure for tenant isolation, offboarding reliability, and privilege containment, especially if the agent identity is reused across environments.
Failure mechanism: Shared identities, shared roles, or shared policy stores let an attacker or an error in provisioning turn one credential into both execution access and customer access. If the agent token or federation path is over-scoped, compromise of the runtime layer can become a direct path into tenant data or administrative workflows.
Impact: Teams lose clean revocation boundaries, audit trails become harder to interpret, and a single compromise can expand from platform execution into customer-facing reach. In a multi-tenant service, that can mean cross-tenant exposure, delayed offboarding, and higher-impact incident response because no layer can be safely changed without affecting the other.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CSA Cloud Controls Matrix and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Separates machine/agent authentication from customer identity flows. |
| AC-6 — Least Privilege | Runtime IAM should be tightly scoped to execution tasks and not customer entitlements. | |
| IA-5 — Authenticator Management | Different credential lifecycles are needed for agent runtime secrets versus customer credentials. | |
| Recommendation — Use IA-9 for agent-to-service authentication and keep it distinct from customer access paths. Apply AC-6 to minimize agent execution privileges and reduce tenant blast radius. Manage agent and customer authenticators separately to simplify revocation and rotation. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Directly addresses separate identity, entitlement, and access governance in cloud services. |
| Recommendation — Map runtime and customer access to distinct IAM policies and ownership. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Requires access boundaries that support separate execution and tenant-access controls. |
| Recommendation — Define access rules that keep agent execution authority separate from customer authorization. | ||
| OWASP ASVS | V8 — Authorization | Customer-facing app authorization must remain distinct from backend runtime permissions. |
| Recommendation — Verify that application authorization enforces tenant reach independently of agent runtime IAM. | ||
Practitioner Guidance
What to prioritise: Define two separate ownership models, one for platform runtime IAM and one for customer identity and authorization. Each should have its own policy source, its own review cadence, and its own revocation path.
What to verify: Confirm that the agent can execute only through workload or cloud IAM, while customer federation and SCIM update only customer entitlements. If a single role, group, or token can influence both, treat that as a design defect rather than a convenience.
Common mistake: Mapping customer sign-in directly onto the agent’s runtime permissions because it is faster to build. That shortcut usually hides the real control boundary until offboarding, incident response, or tenant segregation fails under pressure.
Practitioner takeaway: The safest model is not “one identity for everything,” but a narrow execution identity for the agent and a separate business identity for the customer, with a controlled handoff between the two.
Related resources from NHI Mgmt Group
- How should security teams separate AI agent access control from runtime action authorization?
- What do teams get wrong when they treat customer identity as separate from enterprise IAM?
- How should teams separate internal agent governance from customer IAM?
- How should security teams run access reviews for non-human identities?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org