The certification model breaks first, because there is nothing discrete for identity governance to review. Access can expand through tool wiring, scope changes, or vendor updates while the control record still says the agent is unchanged. That creates silent privilege creep, and the organisation only discovers the change after the agent has already been operating with broader reach.
Why This Matters for Security Teams
When an AI agent’s access changes without a mover event, identity governance loses the signal it depends on to detect meaningful change. The agent may keep the same name, owner, or service account while its effective reach expands through new tools, broader scopes, or a vendor-side configuration update. That leaves certification, access review, and attestation workflows reviewing stale records instead of current privilege. The result is silent privilege creep, especially dangerous because the agent can act at machine speed and outside human supervision.
This is not a theoretical gap. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime governance, because static records do not capture how autonomous systems actually behave. NHI Management Group’s AI Agents: The New Attack Surface report notes that 80% of organisations report agents have already acted beyond intended scope, which is exactly the kind of change a missing mover event fails to surface.
In practice, many security teams encounter the breach only after the agent has already used the broader access, rather than through intentional review of the change itself.
How It Works in Practice
A mover event is the governance trigger that says, “this identity changed in a way that matters.” For humans, that usually means a role transfer or department move. For agents, the equivalent can be subtler: a new API connector, a changed system prompt, an expanded token scope, a different orchestration policy, or a vendor update that adds tool access. If none of those changes generate a mover event, the access model remains frozen while the agent’s effective permissions evolve.
That breaks certification in several ways. Reviewers see the same principal and assume the same risk. RBAC and entitlement reports appear clean, even though the agent now has new execution paths. If the organisation relies on quarterly access reviews, the drift may go undetected for months. The correct response is to treat the agent as a workload identity with change-sensitive controls, not as a static account. That means pairing mover events with runtime signals from workload identity, policy-as-code, and JIT credential issuance, rather than depending on manual recertification alone.
Practitioners should also connect identity governance to the systems that actually grant agent capability. A mover event should be emitted when:
- tool inventory changes, including new plugins, connectors, or MCP endpoints
- scope or token audience changes, even if the account name stays the same
- vendor-managed agent behaviour changes through a release or policy update
- delegated approvals or orchestration graphs expand the agent’s reachable actions
This aligns with the operational direction described in the OWASP NHI Top 10 and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasize dynamic control surfaces over static identity records. These controls tend to break down when an agent’s privilege changes are introduced through external SaaS updates or hidden orchestration layers, because the identity system never receives a discrete event to reconcile.
Common Variations and Edge Cases
Tighter mover-event requirements often increase operational overhead, requiring organisations to balance stronger auditability against faster release cycles and vendor-managed change. That tradeoff becomes sharper in environments where agents are assembled from multiple services, because the “identity” may be spread across an orchestrator, a model endpoint, and several downstream tools.
There is no universal standard for this yet. Current guidance suggests treating any change that alters reachable action space as a governance event, but implementation varies by stack. Some teams emit mover events for any scope drift, while others require only privilege expansion or new data access. The safer interpretation is broader: if the agent can now do something it could not do yesterday, the certification state is already stale.
Edge cases usually appear in three places. First, vendor-hosted agents may change under the organisation’s feet without a visible IAM transaction. Second, multi-agent pipelines can shift access indirectly when one agent inherits another agent’s tool permissions. Third, ephemeral credentials can mask the issue if the token is short-lived but continuously reissued with the same expanded scope. In those cases, the control gap is not that access lasted too long, but that the change was never recorded as a change.
That is why NHI governance must link entitlement review to telemetry, not paperwork alone. The Ultimate Guide to NHIs — Key Challenges and Risks and the NIST AI Risk Management Framework both support the same practical takeaway: if access changed but no mover event fired, the organisation should assume its review state is wrong until proven otherwise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Addresses agent-specific access drift and uncontrolled tool expansion. |
| CSA MAESTRO | T1 | Covers threat modeling for changing agent toolchains and delegated actions. |
| NIST AI RMF | Supports governance when autonomous systems change behavior without formal records. |
Treat any agent capability change as a runtime risk event and re-evaluate access immediately.
