In plain words
An agent can use a web proxy to reach other services, but a program it starts may open its own network connection and skip that proxy.
Connection Escrow is a system that pauses an agent’s outgoing connection inside the operating system and asks a separate verifier whether to release that exact connection.
In one single-node cluster test, a raw socket bypassed a proxy and delivered a post. With Connection Escrow, both the ordinary web call and raw-socket call were reset, and the service stored no posts. This was one test with two described calls, not a broad measure of all network traffic.
The research
An agent can make network connections through tools, but a child process or direct socket may bypass a gateway or proxy setting. How can an approval be enforced where the agent cannot route around it, and tied to the particular connection that approval is meant to govern?
Connection Escrow holds each agent TCP connection in the kernel until a separate verifier approves that specific socket and destination.
The paper asks how to enforce an outbound-connection decision when an agent can bypass a proxy, and how to make sure approval applies to the connection that actually opens. Connection Escrow moves the hold into the kernel and binds release to the socket and destination named by a separate verifier.
In a single-node cluster comparison, a raw socket bypassed a deny-all proxy and the service stored one post; under escrow, both the HTTP and raw-socket calls were reset and none were stored.
This shows the kernel hold handled the tested bypass, while the adversarial suite also passed its applicable checks for each hold path.
These results come from a prototype evaluated in separate runs on a single node. The content gate was demonstrated with TLS 1.2 and is designed for hostile input to an honest agent, not hostile code; the system also trusts the node.
Analysis
Deep
- Original paper authors
- Ashok Subbabhatta Gopalakrishna
- Submitted to arXiv
- License
- arXiv non-exclusive