The set of actions an AI agent can actually be steered into performing at runtime, not just what its manifest or design says it may do. It combines declared permissions, exposed tools, and prompt-reachable paths, which is why it is a more accurate security boundary than approval-time scope.
Expanded Definition
Reachable capability describes the practical action space of an AI agent once it is live, not the theoretical scope written in a policy or manifest. In security terms, the question is not only what the agent is allowed to do, but what it can be induced to do through its tools, prompts, memory, connectors, and execution context. This makes the term especially important in agentic AI governance, where declared permissions and actual runtime reach can diverge. NHI Management Group treats this as a control boundary issue: if a capability is reachable, it must be governed as though it may be exercised. That perspective aligns with the control-oriented approach in NIST SP 800-53 Rev 5 Security and Privacy Controls, even though the framework does not use this exact term. Usage in the industry is still evolving, and some vendors blur reachable capability with permissioned capability or tool inventory. The most common misapplication is treating approval-time scope as the real boundary, which occurs when teams assume a signed-off tool list fully captures prompt-driven and chained execution paths.
Examples and Use Cases
Implementing reachable-capability analysis rigorously often introduces operational friction, because every additional tool, connector, or prompt path expands what must be tested, monitored, and constrained.
- An internal AI agent is approved only to draft email, but a connected workflow tool lets it open tickets, notify users, and trigger follow-on automations. The reachable capability is broader than the original approval.
- A support agent can be steered through prompt injection into exposing secrets or retrieving sensitive records from a connected knowledge base, even when those actions were not intended in the design.
- A coding agent with repository access may reach deployment-related actions through chained tool calls, making OWASP guidance for LLM applications relevant to runtime containment and indirect control paths.
- An autonomous agent operating with a privileged API token can execute actions across multiple systems if the token is reusable outside the original workflow, creating a larger reachable surface than the UI suggests.
- A customer-facing assistant may appear low risk until memory, plugins, and delegated actions are combined, at which point its effective runtime capability includes tasks no single approval step described.
These cases show why reachable capability is a runtime concept, not a procurement or architecture diagram concept. It is also why many teams now pair capability discovery with SPIFFE-style identity for workloads and agents, so the actions available to an agent can be tied back to a verifiable execution identity.
Why It Matters for Security Teams
Security teams care about reachable capability because it reveals where an AI agent can cross from harmless assistance into real-world action. If this is misunderstood, organisations may overtrust agents, miss privilege escalation paths, and fail to see how prompt injection, indirect tool invocation, or insecure connectors convert a narrow use case into a broad operational risk. For identity and access governance, the term is closely related to Non-Human Identity controls: the agent’s identity, its secrets, and its delegated authorisations all contribute to what is reachable at runtime. That means NHI governance cannot stop at provisioning; it has to account for tool access, session scope, and the conditions under which an agent can be steered. The same logic applies in zero trust designs, where every action should be continuously constrained rather than assumed safe because it was approved earlier. Teams should also consider OWASP Top 10 for LLM Applications when mapping prompt-driven abuse paths to concrete controls. Organisations typically encounter the true impact of reachable capability only after an agent has already taken an unsafe action, at which point the runtime boundary 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, NIST Zero Trust (SP 800-207) and NIST AI RMF 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, prompt injection, and runtime abuse paths. | |
| OWASP Non-Human Identity Top 10 | NHI guidance is relevant because agent credentials and tokens shape reachable runtime actions. | |
| NIST CSF 2.0 | PR.AA-01 | NIST CSF access control concepts support managing effective permissions and runtime reach. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of each action and session boundary. | |
| NIST AI RMF | GOVERN | AI RMF governance is relevant to accountability for runtime behaviour and agent oversight. |
Review effective access, not just approved access, and remove paths that let agents exceed intent.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
