A capability matrix documents exactly what each agent job class may do, including data access, network destinations, package installation, and external actions. It is a governance tool for making runtime privilege visible, comparable, and auditable across different workflows.
Expanded Definition
A capability matrix is a governance artifact that maps what each agent job class is permitted to do across explicit action boundaries, including data access, outbound destinations, software installation, and external side effects. In agentic AI security, it is less about listing features and more about making execution authority visible so that reviewers can compare one workflow against another and spot privilege drift. It is closely related to policy documentation, but it is not the same as a design spec or a permissions list because it is meant to support auditability, approval, and ongoing control. NHI Management Group treats the capability matrix as a practical control surface for autonomous software, especially where tool use can change quickly and silently. The most common misapplication is confusing a capability matrix with an implementation checklist, which occurs when teams document intended behaviour but fail to bind it to enforced runtime limits.
The concept aligns naturally with governance language in the NIST Cybersecurity Framework 2.0, although no single standard currently defines “capability matrix” as a standalone term. Usage in the industry is still evolving, and different vendors may describe similar ideas as agent permission maps, action inventories, or execution policies. The strongest defining feature is specificity: a useful matrix names the exact class of agent, the exact action scope, and the exact boundary conditions under which that action is allowed or denied.
Examples and Use Cases
Implementing a capability matrix rigorously often introduces governance overhead, requiring organisations to weigh agent flexibility against the cost of tighter review and change control.
- A customer-support agent class may be allowed to read ticket content and draft replies, but not send messages without human approval or access payment systems.
- An engineering agent may install packages in a sandboxed environment, yet be blocked from reaching production networks or pushing code to protected branches.
- A procurement agent may query approved vendors and prepare purchase requests, but not approve spend or alter supplier bank details.
- An NHI operations team may use a matrix to separate credential rotation tasks, secret retrieval, and cross-environment access for different agent job classes, reducing ambiguity around least-privilege governance.
- A security analyst agent may gather logs and enrich alerts, while being prevented from deleting evidence, changing retention settings, or initiating containment actions without a second control.
These examples show how the matrix supports both design-time review and operational enforcement. It is especially useful when several agents share a tool stack but must not share the same execution rights, because job class, not model capability alone, should define authority.
Why It Matters for Security Teams
Security teams need a capability matrix because autonomous systems can accumulate silent privilege over time, especially when new tools, plugins, or network routes are added faster than governance can keep up. Without a current matrix, reviewers cannot reliably answer basic questions about what an agent may touch, what it may change, or what it may trigger outside the organisation. That creates audit gaps, weakens change management, and increases the chance that an apparently low-risk workflow can still move data, execute code, or contact external services in ways that were never approved. For identity and NHI governance, the matrix also clarifies which non-human identities are allowed to act on behalf of which business function, which is critical when credentials, tokens, and service accounts are reused across workflows. The idea supports control accountability in the spirit of the NIST Cybersecurity Framework 2.0, particularly where access, change control, and third-party exposure intersect. Organisations typically encounter the real value of a capability matrix only after an agent has overreached, at which point the matrix becomes operationally unavoidable to contain scope and assign responsibility.
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, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Capability matrices operationalise least-privilege access boundaries for autonomous workflows. |
| OWASP Agentic AI Top 10 | OWASP Agentic AI guidance covers constraining agent tools, actions, and escalation paths. | |
| OWASP Non-Human Identity Top 10 | NHI governance needs clear task-scoped permissions for non-human identities and service accounts. | |
| NIST AI RMF | The AI RMF supports governance of AI system permissions, accountability, and risk controls. | |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit authorization for each action, which fits capability matrices. |
Map each agent job class to allowed tools, outputs, and escalation rules, then block everything else.
Related resources from NHI Mgmt Group
- How should organisations build a segregation of duties matrix for modern IAM programs?
- How do you know if an AP SoD matrix is actually working?
- How should security teams build a segregation of duties matrix that reflects real access?
- How can teams tell whether a new platform capability is changing their risk posture?
