Unreachability

Unreachability means a consequence has been made impossible rather than merely less likely. In agent security, this is achieved by removing a tool, narrowing a credential, or blocking an egress path. It is stronger than filtering because it does not depend on detecting the attacker’s wording.

Expanded Definition

Unreachability is a design property, not a detection outcome. In agent security, it means a sensitive action, resource, or downstream system cannot be reached by an agent because the path to it has been removed, constrained, or terminated. That can include removing a tool from the agent’s allowed action set, narrowing a secret so it cannot authenticate to a target, or blocking network egress so the agent cannot call an external endpoint. The key distinction is that unreachability does not rely on classifying prompts, spotting malicious intent, or filtering content after the fact.

This makes it different from guardrails that merely reduce risk. A filter can be bypassed if an attacker finds new phrasing, but unreachability changes the system boundary itself. In practice, security teams use the term when discussing agentic AI, NHI, and privileged automation, where execution authority must be shaped with the same discipline as human access. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because it frames how access, boundary, and system protections can be enforced rather than merely monitored. The most common misapplication is calling a tool “unreachable” when it is only hidden behind a policy check that still permits access if the right input is supplied.

Examples and Use Cases

Implementing unreachability rigorously often introduces operational friction, because tighter boundaries can reduce agent usefulness and require more exception handling. Security teams have to weigh containment against the cost of lost automation breadth.

• An AI agent used for IT support is given read-only access to ticketing data, while the tool that can close or modify privileged accounts is removed from its toolchain entirely.
• A code-generation agent can draft pull requests, but deployment credentials are withheld so it cannot push directly to production systems.
• A customer-service agent is prevented from reaching payment APIs by network controls, even if a prompt tries to coerce it into handling card data.
• A workflow agent in a cloud environment is issued a narrowly scoped token that expires quickly and cannot be exchanged for broader access.
• In identity operations, a non-human identity is segmented so it can query logs but cannot initiate administrative changes, reducing blast radius if the identity is abused.

These patterns are often paired with architecture guidance from the OWASP Top 10 for Large Language Model Applications, especially where tool exposure and indirect prompt influence are being constrained. Unreachability is most useful when a specific downstream consequence must never be available to the agent under any prompt condition.

Why It Matters for Security Teams

Unreachability matters because many agent failures are not failures of detection, but failures of containment. If an agent can still reach a privileged tool, a payment endpoint, a secret store, or an administrative workflow, then prompt filtering alone cannot prevent misuse. Security teams need to think in terms of reachable consequences, not just allowed text. This is especially important for autonomous software entities with execution authority, where tool access, credential scope, and network paths define the real attack surface.

For identity teams, the concept aligns closely with non-human identity governance: if an NHI can authenticate to a system, the system is reachable. If the identity is over-scoped, long-lived, or reusable across environments, the supposed control is weaker than it appears. The same logic applies to agentic AI security, where a model may be safe in conversation yet dangerous once granted tool execution. Guidance from the ISO/IEC 27001 information security management system standard is relevant when organisations need to translate policy into enforceable access design. Organisations typically encounter the impact of unreachability only after an agent exfiltrates data, triggers an unsafe workflow, or attempts an action that should never have been technically possible, at which point the concept becomes operationally unavoidable to address.