Unreachability

What Unreachability Means

Unreachability is a stronger control outcome than simple filtering or throttling. The goal is to make a consequence impossible by removing the path that would enable it, such as cutting off a tool, narrowing what a credential can do, or blocking a network egress route. That changes the security question from “can we detect misuse?” to “can this action happen at all?”

This distinction matters because many defenses still rely on interpreting content, detecting intent, or applying policy after a request arrives. Unreachability instead reduces the attack surface at the mechanism level, so the unwanted outcome is no longer reachable through that path.

How Unreachability Works in Agent Security

In agentic systems, unreachability is usually created by removing or disabling capabilities the agent could otherwise use. A tool can be excluded from the agent’s available actions, a credential can be constrained so it cannot perform a sensitive operation, or a network route can be blocked so the agent cannot exfiltrate or call an out-of-bounds service.

The key design choice is that the restriction is structural, not interpretive. If the agent cannot access the tool or destination, there is no need to rely on prompt inspection, model judgment, or downstream rejection. That makes unreachability useful when the risk comes from the existence of a pathway, not merely from a malicious instruction.

Why It Is Stronger Than Filtering

Filtering tries to decide whether a request should be allowed. Unreachability removes the condition that makes the request actionable. In practice, that means fewer false negatives, less dependence on language-specific detection, and less exposure to adversarial phrasing that tries to bypass a policy engine.

It is also easier to reason about. If a tool or egress path does not exist in the reachable set, then the agent cannot use it even if the model is manipulated, the user prompt is misleading, or the request is wrapped in a benign-looking workflow. That is why unreachability is often the preferred control when the outcome is high impact and the set of allowable actions can be tightly bounded.

Where It Fits in Defensive Design

Unreachability is most useful when paired with a clear boundary around what the agent is allowed to do. It works well for high-risk tools, sensitive administrative actions, and destinations that should never be reachable from a given workflow. It is less useful when the business process truly requires broad, dynamic access, because then the reachable set is difficult to shrink without breaking legitimate work.

In that sense, unreachability is a design principle as much as a control. It pushes teams to decide which actions must exist at runtime and which should be impossible by construction. That usually improves containment, reduces blast radius, and makes later monitoring more meaningful because any remaining path is intentional rather than incidental.

Risk and Threat Considerations

Unreachability matters because partial controls can still leave exploitable paths open. If a tool remains reachable, an attacker may be able to coerce the agent into using it, route around a policy check, or trigger an unintended downstream action. The same applies to overly broad credentials and open egress paths, which can turn a limited compromise into a wider one.

Failure mechanism: The control fails when the forbidden outcome is still technically reachable through another tool, broader permission set, indirect call path, or unrestricted outbound connection.

Impact: A successful bypass can enable unauthorized actions, data exposure, or lateral movement from the agent environment into systems that were assumed to be out of scope.

Practitioner Guidance

Why practitioners should care: Treat unreachability as a control objective, not just a policy preference. If a capability is high risk, the strongest design is to remove the path entirely rather than rely on content-based refusal.

What to watch for: Reintroductions are common when teams add convenience integrations, reuse broad credentials, or open fallback egress for troubleshooting. Those changes can quietly undo an otherwise sound containment model.

Practitioner takeaway: If a consequence must never happen, make sure the agent cannot reach the tool, privilege, or destination needed to cause it.