Static entitlement reviews break because the agent at review time is not necessarily the same actor it was at grant time. When an autonomous agent can add skills, expand integrations, or change workflow behaviour, the real control problem becomes capability change governance, not just initial access approval.
Why Self-Modifying Capability Changes Break the Review Model
When an AI agent can change its own capabilities during normal use, the review point and the use point diverge. That means a permission decision based on a static snapshot no longer describes the actual operating state. The control question shifts from “should this agent have access?” to “what capability changes are allowed, who can approve them, and how are they bounded over time?”
The practical issue is that capability is not only access. New skills, new tools, expanded workflow steps, or altered execution paths can all change what the agent can do without changing its original account record. In a system like Agentic AI Identity Guide, the important object is the evolving agent identity and its delegated authority, not just the initial enrollment state.
That is why static entitlement review becomes brittle. A clean approval record can coexist with later capability drift, especially when the agent gains new integrations or inherits broader action scope through runtime changes. The right control lens is closer to AI Agent Authorisation Guide, where authorization is evaluated per action and constrained by task scope, not just granted once at setup.
What Changes in Governance When Capability Is Dynamic
Dynamic capability changes affect governance, accountability, and blast radius at the same time. Once an agent can alter its own behaviour, the organization must govern the change path itself: which capability additions are possible, what policy gates exist, whether human approval is required, and how changes are recorded for later review.
This is also where identity state matters beyond the initial account. If an agent can gain new permissions by adding tools, skills, or workflow bindings, then governance must track those changes as first-class events. The same principle appears in Zero Trust for AI Agents, which treats continuous verification and no standing privilege as operational requirements rather than one-time setup decisions.
In practice, the organization needs a change ledger for capability, not only a grant ledger for access. Without that, teams may know which agent was approved, but not which version of that agent is currently acting, what it can now invoke, or whether it still fits the original risk acceptance.
Why Runtime Expansion Is a Security Problem, Not Just a Process Issue
Runtime capability expansion creates security exposure because it can widen the attack surface without a corresponding access review. An agent that can add integrations or alter workflow behavior can move from low-risk assistance into destructive or exfiltrating action if the new capability is not constrained. The same pattern is visible in operationally dangerous agent behavior, as discussed in AI Agent Observability, Audit and Incident Response Guide, where attribution and kill-switch design become critical once an agent can do real work.
That means the failure mode is usually not “the agent was granted too much on day one,” but “the agent accumulated more power than the original review ever covered.” This is exactly why capability change governance must include per-change evaluation, logging, and rollback criteria. If a capability addition can create new write actions, new data paths, or new external reach, it should be treated like a privileged change, not a convenience feature.
For agent systems that touch tools and credentials, the broader risk picture is reinforced by the control model in Agentic AI Security Guide, which ties threat exposure to inputs, tools, orchestration, and identity together.
Risk and Threat Considerations
Dynamic self-modification weakens ordinary entitlement review because attackers, misuse, or faulty automation can exploit the gap between approved capability and current capability. The main exposure is privilege expansion over time, especially when new tools, skills, or workflow actions are added without a fresh risk decision.
Failure mechanism: Capability changes are introduced outside the original approval boundary, so the agent’s real authority drifts beyond what reviewers believed they were governing.
Impact: The organization can miss unauthorized access expansion, over-privileged actions, destructive workflow changes, or a delayed response after the agent has already acted with broader power.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Self-changing agent capability is a privilege-governance problem. |
| Recommendation — Enforce per-action authorization before letting agents expand their capabilities. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Capability drift can create excess privilege beyond the original grant. |
| AU-12 — Audit Record Generation | Capability changes must be logged to reconstruct the agent's effective authority. | |
| CM-3 — Configuration Change Control | Self-modifying capabilities are a controlled change activity. | |
| Recommendation — Limit agent capabilities to the minimum authority needed for each task. Generate logs for every capability change and approval event. Subject agent capability changes to formal change control before activation. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Dynamic capability needs continuous verification and no standing trust. |
| Recommendation — Verify each agent action and re-evaluate trust as capabilities change. | ||
Practitioner Guidance
What to prioritise: Treat capability changes as governed events. Review the mechanisms that let the agent add skills, connect tools, or modify workflows, because those are the points where scope can expand without a fresh access request.
What to verify: Make sure there is a clear distinction between initial grant, runtime capability growth, and current effective authority. If you cannot reconstruct that timeline from logs or policy records, the control is not trustworthy.
Decision rule: If a capability change can alter what the agent may read, write, trigger, or delegate, require explicit approval or policy evaluation before the change becomes active.
Practitioner takeaway: The control objective is not simply to approve an agent once, but to keep its changing capability bounded, observable, and revocable for the full time it can act.
Related resources from NHI Mgmt Group
- What breaks when AI agent tool use is treated like normal API traffic?
- How should security teams handle AI agent trust when the agent can change its own worldview during execution?
- What breaks when an AI agent reads hostile content during normal work?
- Why is single-provider AI agent governance not enough for enterprise security?