Pi Fortress¶

A small box between your AI agent and the internet. With it, the agent never holds your real API keys.

AI coding agents need API keys to work. A malicious prompt, a bad skill or an MCP server can trick an agent. A tricked agent can send those keys anywhere. Pi Fortress removes the keys from the agent machine and fences them at the network. The agent sees only fake placeholder keys. The gateway puts in the real key only when the request goes to a service that the key belongs to.

It runs on a Raspberry Pi 5, or on a small VM next to the VM of the agent. The agent cannot disable it, because it does not run on the agent machine.

How is it different from a proxy, a vault or a sandbox? Refer to the comparison.

Why it exists¶

AI agents hold keys, and attackers hunt them. Flaws, VM escapes included, are found faster every year.

Pi Fortress assumes that the agent can escape its VM. Thus the keys are on a separate box. Sources

How it works¶

All requests from the agent go through Pi Fortress. The agent has no proxy setting to bypass.

• To the right service: Pi Fortress replaces the placeholder with the real key, only in a credential header. A credential header is Authorization, X-Api-Key, or a header that you declare for that service. If the placeholder is in a different location, Pi Fortress refuses the request.
• To anywhere else: Pi Fortress never replaces the placeholder. It strips a live key in a format that the gateway knows (Anthropic, OpenAI, GitHub, AWS, GitLab, npm and more). It strips the key from header values, the URL and the body.
• To a known-malicious site: Pi Fortress drops the connection.

One request, step by step¶

sequenceDiagram
    participant A as AI agent
    participant P as Pi Fortress
    participant S as api.anthropic.com
    A->>P: Authorization: Bearer pf_…_CLAUDE_OAT (placeholder)
    P->>P: Is this site allowed this kind of key?
    P->>S: Authorization: Bearer sk-ant-oat01-… (real key)
    S-->>P: Response
    P-->>A: Response, with any real key turned back into its placeholder

If the check fails, the agent gets one plain refusal. The refusal does not give the cause. The owner gets an alert.

Where it sits in your network¶

flowchart TB
    Internet(("Internet")) --- Router["Your router"]
    Router --- Pi["Pi Fortress<br/>(Raspberry Pi 5)"]
    Pi ---|"one cable, two VLANs"| Desktop
    subgraph Desktop["Your desktop"]
        AgentNet["Agent VMs<br/>agent segment, full credential fence"]
        Desk["Desktop host<br/>desk segment, DNS and blocklist, optional credential fence"]
    end
    Pi --- HomeNet["Home network (optional)<br/>phones, laptops, TV"]
    classDef pf fill:#3b82f6,stroke:#93c5fd,stroke-width:3px,font-weight:bold
    classDef agent fill:#8b5cf6,stroke:#c4b5fd,stroke-width:2px
    class Pi pf
    class AgentNet agent

Your desktop and its agent VMs use one cable to the Pi. The Pi is the only uplink of the desktop. Pi Fortress assumes that an agent can escape its VM. Thus the desktop also gets DNS filtering and the blocklist.

The same box can also filter your home network. It blocks known-bad sites for phones and laptops.

What you get¶

By default, the agent can reach all sites except known-bad sites. You can leave Pi Fortress on all day.

Lock it down¶

Enable paranoid mode. Then the agent can connect only to the sites on your allowlist, and a key can go only to those sites. The risk model, with each attack that we tested and its result, is published with the source.

Who it is for¶

It is for all persons who run a coding agent, a skill or an MCP server with a real credential:

• Solo developers.
• Small teams that share one gateway.
• Families who want the same filtering for their devices.

Refer to Use cases.

Where to go next¶