A structured representation of an agent action that can be checked before execution. Instead of treating a tool call as an implicit privilege, the system translates it into a request for a specific action, resource, and context, then applies policy to decide whether it may proceed.
Expanded Definition
A capability request is the policy-facing form of an agent action: it describes what the agent wants to do, which resource it wants to touch, and the surrounding context needed for a decision. In agentic AI systems, this is different from a raw tool invocation, because the request is evaluated before any execution authority is granted. That makes the concept central to safe delegation, especially where an AI agent can call APIs, query data, or initiate workflows.
Usage in the industry is still evolving, and definitions vary across vendors. In practice, a capability request sits between intent and action. It is not itself a credential, and it is not the same as a general permissions model; rather, it is the structured event that allows policy to determine whether the action is allowed, denied, stepped up, or constrained. For organisations aligning with the NIST Cybersecurity Framework 2.0, this maps naturally to governance, access control, and decision enforcement. The most common misapplication is treating a capability request as a logging label only, which occurs when the system records agent intent but still executes the underlying tool call without pre-authorisation.
Examples and Use Cases
Implementing capability requests rigorously often introduces latency and policy-design overhead, requiring organisations to weigh safer execution against the cost of more complex orchestration.
- An AI agent asks to read a finance API for a specific invoice set, and the capability request includes the data scope, tenant, and time window so policy can approve only that bounded read.
- A customer-support agent requests permission to reset a user credential, but the request is denied unless the workflow includes verified identity proofing and human approval.
- A build automation agent requests access to a secrets vault, and the capability request is evaluated against environment, repository trust, and break-glass conditions before any secret is released.
- An analyst assistant requests query access to sensitive records, but the policy engine trims the request to a narrower dataset rather than granting broad database access.
- A task-planning agent requests an external action through a tool endpoint, and the system requires a capability request so the action can be audited, constrained, and revoked if needed.
These patterns align closely with identity and access governance principles described in the Zero Trust Architecture model, where each access decision is evaluated in context rather than assumed from network position or prior trust.
Why It Matters for Security Teams
Capability requests matter because they convert agentic behaviour into something that security controls can reason about. Without them, an AI agent can blur the line between suggestion and execution, making it difficult to enforce least privilege, segregate duties, or prove why a sensitive action occurred. For NHI governance, this is especially important when the acting entity is not a person but a software identity with tokens, scoped permissions, and tool access. A well-formed capability request gives security teams a place to apply policy, evaluate risk, and attach audit evidence before action happens.
This also strengthens response and review workflows. When an agent acts outside expected bounds, the capability request shows whether the issue was excessive entitlement, weak policy, poor context, or a flawed workflow design. The same structure can support controls discussed in NIST SP 800-53 and AI governance patterns in NIST AI Risk Management Framework. Organisations typically encounter the full operational cost of capability requests only after an agent attempts an unauthorized action, at which point controlled execution 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 AI RMF, NIST CSF 2.0 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 | Agentic AI guidance covers tool-use boundaries and pre-execution checks for actions. | |
| NIST AI RMF | AI RMF addresses governance and risk controls around AI system actions and oversight. | |
| NIST CSF 2.0 | PR.AC-4 | Access control principles apply when agent requests need authorization before use. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires context-aware, per-request authorization instead of assumed trust. | |
| OWASP Non-Human Identity Top 10 | NHI guidance is relevant when software identities request scoped permissions for actions. |
Bind each capability request to the non-human identity and revoke excess scope promptly.
Related resources from NHI Mgmt Group
- What is the difference between network trust and request-level identity trust?
- Why do access-request workflows matter for NHI governance?
- How should organisations use AI in access request approval without weakening control?
- What is the difference between access request automation and access governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 21, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
