A control approach that limits what an AI agent can do by defining approved tools, destinations, and actions. It shifts the security focus from prompt safety alone to the specific execution paths an agent may use, which is where most operational damage occurs.
Expanded Definition
Capability-level governance is the practice of constraining an AI agent by the specific capabilities it is allowed to use, rather than trusting the prompt, model output, or user intent alone. In NHI and agentic AI security, that means defining approved tools, destinations, data scopes, and action types so the agent can only execute within a known boundary.
This approach is narrower than general policy management and more operational than prompt safety. It sits alongside identity, authorization, and runtime control: the agent may be authenticated, but still blocked from invoking a payment API, sending data to an unapproved endpoint, or escalating privileges through a tool chain. The concept aligns well with the governance emphasis in the NIST Cybersecurity Framework 2.0, although no single standard governs this yet and usage in the industry is still evolving.
Capability-level governance is often confused with prompt filtering or role assignment, but those controls do not reliably prevent tool misuse once the agent is executing. The most common misapplication is treating prompt approval as sufficient, which occurs when organisations fail to restrict the agent’s downstream tool permissions.
Examples and Use Cases
Implementing capability-level governance rigorously often introduces workflow friction, requiring organisations to weigh agent autonomy against the cost of tighter execution controls.
- An IT support agent can reset passwords in a helpdesk system, but cannot read payroll records or export user directories.
- A procurement agent can draft purchase requests, but can only submit to approved vendors and cannot change contract terms.
- A data analysis agent can query a sanctioned warehouse, but cannot send results to external SaaS tools without explicit approval.
- An engineering agent can open tickets and create pull requests, but cannot deploy to production without a separate release gate.
- Capability planning should be informed by lifecycle and audit controls described in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and by incident patterns in the State of Non-Human Identity Security.
In practice, teams also use capability catalogs to document which tools an agent may invoke, and they pair that list with just-in-time approvals for high-risk actions. The control model is strongest when each capability maps to an explicit business purpose, not a generic “productivity” label. For broader governance framing, the Top 10 NHI Issues remains a useful reference for prioritising where agent permissions become dangerous fastest.
Why It Matters in NHI Security
Capability-level governance matters because most harmful agent behavior is not caused by a single bad prompt, but by a valid identity exercising too much authority through approved tools. Once an agent can reach secrets, modify records, or trigger external transactions, the damage path is often indistinguishable from legitimate automation unless the capability boundary is enforced.
NHIMG research shows why this matters operationally: in The State of Non-Human Identity Security, lack of credential rotation was cited as the top cause of NHI-related attacks by 45% of organisations, while inadequate monitoring and logging and over-privileged accounts were each cited by 37%. That pattern maps directly to agent capabilities, because overbroad execution rights make misuse harder to detect and easier to repeat. The same report also found only 1.5 out of 10 organisations are highly confident in securing NHIs, underscoring how immature many capability controls still are.
Organisations typically encounter the need for capability-level governance only after an agent has already invoked the wrong tool, exposed sensitive data, or completed an unintended action, at which point the control becomes operationally unavoidable to address.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic AI guidance focuses on tool use, action limits, and execution boundaries. | |
| OWASP Non-Human Identity Top 10 | NHI-04 | Over-privileged non-human identities are a core risk addressed by least-privilege controls. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed to enforce least privilege for system actors. |
Constrain agent tools and actions so autonomous behavior stays within approved operational bounds.
