A governance pattern where identity, authorisation and monitoring move with the workload instead of staying fixed at one layer. For AI systems, that means controls must stay attached as models, agents and applications move between development, runtime and security operations.
What Identity-Following Control Is Doing
Identity-following control is a governance pattern, not a single product feature. Its purpose is to keep identity, authorization and monitoring attached to the workload or agent as that workload moves across environments, rather than letting those controls fragment at one layer of the stack.
That distinction matters because modern systems are mobile by design. A control plane that stays bound to a host, cluster, app boundary or team boundary can miss the real thing being governed, especially when the governed object is an application, service, model or agent that changes runtime location but not trust requirements.
Why It Matters for Cloud and AI Operating Models
In practice, identity-following control is a response to distributed execution. The security question is not just “what is running?” but “what authority follows it, where is that authority enforced, and how is it observed as the workload moves?” That is why concepts such as workload identity, least privilege and runtime visibility become part of the same design discussion.
For AI systems, the pattern is especially important when models, tools and agents move between build, test, deployment and operations. The controls should follow the workload identity lifecycle, rather than relying on a static perimeter or an environment-specific account that can be copied, reused or forgotten.
It also aligns with the idea that identity is not only for people. When services, workloads and agentic components exchange requests, the governing question becomes whether their authentication and authorization state remains attached to the entity itself, not merely to the network location it happens to occupy.
Where the Control Usually Breaks Down
Identity-following control fails when teams separate identity, policy and telemetry across tools that do not share a common trust model. A workload may be redeployed, scaled, cloned or promoted, while its privileges, secrets, logs or approvals remain stale, duplicated or partially enforced.
That creates gaps in accountability and review. If runtime authority changes faster than the governance record, defenders can lose the link between what the system is, what it may do, and what evidence exists to prove that those permissions are still appropriate. A governance and audit perspective on non-human identities is useful here because the same problem appears whenever machine-level access outlives the workload it was meant to protect.
In AI environments, the breakage often shows up as control drift across environments, where development assumptions, runtime permissions and operational monitoring no longer match. That is a governance failure even when the underlying application still appears to be functioning normally.
How It Relates to Identity Governance and Runtime Assurance
Identity-following control sits between identity governance and operational enforcement. It is about making sure that identity, privilege, observation and revocation remain coupled to the thing performing the work, so that security decisions do not depend on a human remembering which layer owns which authority.
That is why the strongest implementations tend to pair lifecycle discipline with runtime checks. The goal is not merely to issue credentials, but to keep those credentials, permissions and monitors aligned to the current state of the workload or agent throughout its lifecycle. Lifecycle management for non-human identities is the closest operational analogue, because it addresses provisioning, rotation, visibility and offboarding as one continuous control problem.
For practitioners, the useful lens is simple: if the workload moves, the authority and the evidence must move with it. If they do not, you do not have identity-following control, you have identity scatter.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Covers machine and service authentication when identity must follow the workload. |
| AC-6 — Least Privilege | Limits the authority that should travel with a workload or agent across environments. | |
| AU-6 — Audit Review, Analysis, and Reporting | Supports continuous monitoring when authority and behavior must stay coupled to the workload. | |
| Recommendation — Apply IA-9 to authenticate non-organizational workloads with portable, workload-bound credentials. Enforce AC-6 so moving workloads retain only the minimum access they need. Use AU-6 to review workload activity and detect identity drift as systems move. | ||
| NIST CSF 2.0 | PR.AA-05 — Physical and Logical Access Service Management | Applies to managing access services that must remain bound to changing workloads. |
| DE.CM-01 — Monitoring of Networks and Information Systems | Supports visibility over runtime changes when control must follow the workload. | |
| Recommendation — Manage access services so workload identity and authorization stay current across environments. Monitor runtime behavior to detect when workload identity or privilege no longer matches state. | ||