Yes. Runtime attestation, token injection, and cross-cloud policy serve different purposes, and collapsing them into one control plane makes portability and offboarding harder. Separate layers let each cloud contribute without becoming the only trust boundary.
Why Separating Runtime Controls from Identity Governance Improves Control Boundaries
Runtime controls answer a different question from identity governance. Runtime attestation, token injection, and cross-cloud policy need to govern what an agent can do now, while identity governance governs who or what it is, who owns it, and how it is provisioned, reviewed, and retired. If one layer absorbs the other, portability suffers and offboarding becomes slower and less reliable.
The cleanest design treats runtime as the enforcement layer and governance as the lifecycle layer. That lets teams swap clouds, rotate credentials, or retire an agent without rewriting the policy system that proves the agent is trustworthy at execution time.
For identity lifecycle design, NHI Lifecycle Management Guide is the most direct reference for why provisioning, rotation, and offboarding should remain distinct from runtime enforcement.
Where Collapsing the Two Layers Creates Operational Friction
When runtime and governance share one control plane, the system becomes harder to move, harder to audit, and harder to unwind. A runtime gate that is also carrying ownership, recertification, or deprovisioning logic tends to accumulate exceptions, because the requirements change at different speeds and for different reasons. That is how an integration that starts as convenience becomes a coupling problem.
This separation also matters when organisations run more than one cloud or identity source. If runtime trust is tied too tightly to one governance stack, the agent may work only as long as that stack remains available and authoritative. A layered design keeps each cloud or platform responsible for its own enforcement surface without forcing it to become the sole source of truth.
The broader lifecycle and governance failure modes are well covered in Top 10 NHI Issues and in IAM and IGA Basics, which separate access governance from execution-time authorization concepts.
How to Design the Split So It Still Feels Unified
Practitioners should define a narrow contract between layers: governance decides whether the agent may exist, who owns it, and when it must be reviewed or removed; runtime decides whether a live session, token, or tool invocation is allowed right now. That split keeps the policy model stable even when attestation methods, token formats, or cloud-specific enforcement points change.
It also gives teams clearer failure handling. If runtime attestation fails, the correct response is usually deny or degrade access. If governance fails, the correct response is to suspend issuance, remove stale grants, or force review. Those are related problems, but they are not the same control decision.
For lifecycle and access review operations, Access Reviews and Certification Guide and Joiner-Mover-Leaver (JML) Guide show why review and retirement workflows should stay separate from runtime enforcement.
Risk and Threat Considerations
Conflating runtime controls with identity governance increases blast radius when something goes wrong. A failure in attestation, token handling, or cloud policy can then interfere with offboarding, while a governance workflow outage can block live enforcement or leave stale access in place longer than intended.
Failure mechanism: The control plane becomes a single dependency for distinct trust decisions, so exceptions, delayed reviews, or failed deprovisioning can leave an agent both overtrusted and harder to remove.
Impact: Organisations lose portability, create offboarding delay, and increase the chance that a compromised or obsolete agent continues to operate with valid access.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Runtime tokens and credential handling are central to agent execution control. |
| IA-9 — Service Identification and Authentication | Agents and services need runtime authentication that differs from governance workflows. | |
| AC-6 — Least Privilege | Runtime authority should be bounded independently of identity governance processes. | |
| Recommendation — Apply IA-5 to separate credential lifecycle management from runtime authorization decisions. Use IA-9 to govern service-to-service authentication without merging it into identity administration. Enforce AC-6 so runtime access stays least-privileged even when governance is separate. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question concerns separating access enforcement from governance responsibilities. |
| A.8.5 — Secure authentication | Runtime attestation and token use rely on authentication controls distinct from governance. | |
| Recommendation — Define access control rules separately from identity lifecycle governance. Implement secure authentication at runtime without tying it to review and offboarding workflows. | ||
Practitioner Guidance
What to verify: Confirm that runtime deny decisions can be made without depending on the same workflow that owns review, ownership, or deprovisioning. If the answer is no, the design is already too coupled.
Decision rule: If a control answers “is this action allowed now?”, keep it in runtime; if it answers “should this identity still exist or be trusted?”, keep it in governance.
What good looks like: You can offboard an agent, revoke its credentials, or change clouds without re-architecting the enforcement path, and you can change runtime policy without reopening ownership records or certification logic.
Practitioner takeaway: Separate the policy that proves trust at execution time from the process that governs identity over time, because the fastest way to create brittle agent control is to make one layer do both jobs.