Home Secure Fetch // Sealed egress
Read the web. Let nothing read back.
To be useful, an AI often has to read a page for you. The moment it fetches a URL you have handed it a loaded gun. Secure Fetch reads the dangerous page the way a scientist handles a virus: inside a glovebox. Hands go in, the threat never gets out.
The problem // SSRF
A link that turns your assistant against your own network.
When an AI fetches a URL, it makes the request from inside your network, with your network's reach. A malicious page exploits exactly that. Instead of pointing at the public web, it points the fetch back inward: at your router's admin page, your internal company systems, or the cloud metadata endpoint at 169.254.169.254 that hands out credentials. Security people call this SSRF, server-side request forgery, and it is one of the nastier web attacks because the attacker borrows your trusted position to reach things they never could from outside.
This is not theoretical. The 2019 Capital One breach, over a hundred million records, was an SSRF that reached AWS instance metadata and walked out with the keys. Now imagine handing that same primitive to an autonomous agent that fetches links all day without a human reading them first.
So Secure Fetch is built so that even a page actively trying it has nowhere to go. The cage owns the egress, the reader has no network, and nothing it brings back is trusted until it earns it.
The doctrine // Three controls, not one
Cage the egress. Seal the reader. Distrust the output.
- 01 // CAGE
The part that touches the internet cannot touch you
The fetcher is the only thing allowed to reach the open web, and it is hardened against SSRF: it physically cannot resolve or connect to a private address. Point a malicious link at your router, your file shares, or the cloud metadata endpoint and the request has nowhere to land. It owns all egress, so nothing else in the system can make an outbound call behind its back.
- 02 // SEAL
The part that reads the page has no internet at all
Once a page is fetched, it is read inside a sealed sidecar with no network whatsoever, not even DNS. This matters because a booby-trapped page tries to phone home, and a process with no way to resolve a name and no socket to open simply cannot. The dangerous content is handled the way a lab handles a live virus: inside a glovebox, hands in, nothing out.
- 03 // UNTRUSTED
Nothing read off the web walks in trusted
Everything the fetcher brings back is treated as untrusted by default. It is staged, never auto-written into trusted memory, and never auto-acted on. Guilty until proven innocent. This is the control people forget: being offline stops a page calling out, but it does not stop a page lying its way into your memory. You need all three at once, not one.
Why all three. Offline alone does not stop a page lying its way into memory. A trusted-by-default reader does not stop a page phoning home. An un-caged fetcher does not stop SSRF. Each control covers a gap the others leave open, so removing any one reopens a whole class of attack.
Architecture // How it is built
Two languages, two seals, one one-way seam.
The fetcher is written in Rust and is the single component with any path to the internet. The part that reads and reasons over the page runs in a separate Python sidecar that is network-isolated at the container level, including DNS. Both heavy components sit on a sealed internal network; only the fetcher straddles the boundary.
The only way data crosses from the sealed side back to the trusted side is a deliberate, narrow seam: the fetcher is the one thing that can reach the sealed reader, and the only thing it can pass back is a screened result. The staging corpus is ephemeral; your real memory, Memsom, is the durable store, and crossing from one to the other is gated, never automatic.
The containers themselves are stripped down: every Linux capability dropped, run as a non-root user, a read-only root filesystem, and a pinned syscall filter. So even if something did break out of the application, it would land in a box with the floor, walls, and exits already removed.
The handoff // Into Memsom
Screened at the border, stamped on arrival.
Secure Fetch is the airport checkpoint. Memsom is the country behind it. Web content does not get a passport stamp just for showing up. It gets one only if its story checks out from more than one angle.
- External
Quarantine
Secure Fetch reads the web. The result is staged, untrusted, and untouched by your memory.
- k >= 3
Corroborate
The same fact must be confirmed by several independent sources that agree. One page is never enough.
- Trusted
Promote
Only then is it written into Memsom as trusted, with its receipt attached and revocable later.