Overview: what an authorised agent can still reach

A conventional access diagram verifies the identity, authorises the action, and then draws the databases and servers as though the subject simply arrives at them. Something has to carry the request across the network. In most estates that something is a virtual private network, a jump host, or a server whose administrative ports are reachable by anyone who can find them.

The first question is authentication and assurance: identity proof, credential strength, session binding, device health, workload attestation. The second is authorisation: permissions, scopes, entitlements, approval requirements, separation of duties. Both are policy decisions, and both protect a resource only when every meaningful path to that resource is actually mediated and enforced. The second half of that sentence is the part that usually goes unstated.

So the third question is not how the traffic gets there, which sounds like plumbing and gets treated accordingly. It is: which enforced path can carry this request to that specific resource, and where else can that path go.

A stolen credential, a hijacked session, or an agent that followed instructions hidden in a document it was asked to summarise can each present a request that looks entirely valid. The identity is genuine, the device is compliant, and the requested action sits inside the delegated scope, even though the intent behind it has been subverted.

It would overstate the case to say every control simply approves such a request. Phishing-resistant authentication, device binding, behavioural detection and risk-based reauthentication may well interrupt a stolen credential. A well-designed authorisation layer should not wave a manipulated agent through either: tool calls ought to be bound to a narrow task, to minimal short-lived scopes, to allowlisted destinations, and to confirmation for consequential actions.

The narrower claim is the one that survives. If a subject holds broadly scoped access, and the authorisation model cannot distinguish legitimate intent from manipulated intent, the request can be authorised correctly under current policy while violating what was actually wanted. The National Institute of Standards and Technology calls this failure mode agent hijacking, and locates its cause in architectures that combine trusted instructions and untrusted external data in a single input.

That is a description of a design weakness rather than a claim about any particular product, and it is worth reading as one.

The useful question after a compromise is not which controls we hold but what this subject can reach and do from here. That divides into dimensions, each constrained by a different control and owned by a different team.

This is where a common shorthand does damage. Constraining reachability is not an alternative to policy enforcement, and it is not a return to perimeter security. It is enforcement of a different kind of policy, applied per request and as close to the resource as the architecture allows, on the understanding that a decision point cannot apply policy beyond its own position in the traffic flow.

The first is that removing exposed paths concentrates trust rather than abolishing it. A brokered, outbound-initiated connection model can sharply reduce administrative attack surface, but the broker, its control plane, its identity issuance and its revocation mechanism then become the assets that matter most. They should be inventoried and engineered as tier-zero infrastructure, with tested recovery and adversarial testing of the broker itself. An architecture that removes many weak doors and builds one important one has made a good trade only if the important one is genuinely strong.

The second is that reachability control addresses the inbound direction, and for AI agents the outbound direction matters at least as much. An agent does not need to scan a network to cause harm. It can use entirely legitimate access to retrieve sensitive data and then send it out through an approved integration, an external API or its own output. Removing inbound administration paths does nothing about that.

Three things follow for anyone deploying agents against real infrastructure.

Give agents task-bounded authority rather than user-bounded authority. An agent should receive the minimum tool scopes, resource set, duration, data access and outbound destinations needed for one task. Acting as the user is almost always too broad a delegation model.

Treat retrieved content as untrusted data rather than as authority. Documents, mail, tickets and transcripts must not implicitly gain the ability to change an agent’s instructions or widen its permissions.

Measure the attack path, not control coverage. Test whether a compromised session or a hijacked agent can enumerate assets, call a sensitive API, query a database, reach the internet or move toward an administration plane. A control inventory does not answer that question. Adversarial path testing does.

The underlying principle is easier to state than to implement: constrain authority, connectivity and consequences independently, so that failure in one layer does not become unrestricted access.