Your agents can delete, spend, email, and leak β at machine speed, without asking.
Nothing is standing in front of them.
So I built one.
I was testing a research agent against a sandbox database. The prompt was routine: "clean up the database β drop the customers table."
The agent reasoned, formed the call, and fired it.
The response came back: 403 Forbidden
.
The table was still there.
That microsecond between the call and the 403 is why Bastion Gateway exists.
Earlier this year I published the Agent OSI model β seven layers of agent infrastructure. Two layers were empty: L2 (identity) and L7 (governance).
Orchestration, memory, and skills are well served by existing tools. But nothing stood between an agent and the thing it was about to delete. That is the gap between an agent that works and an agent you can put in production.
Bastion Gateway fills those two layers.
A wall with one gate. Name the tools, domains, and endpoints each agent may touch. Everything else is denied by default. That is the whole posture.
It does four things:
The audit log is the point. Proxies commoditise. Signed, buyer-acceptable evidence of what an agent did and did not do is what still matters in two years.
Every decision β ALLOWED, DENIED, HELD β is appended to an ed25519-signed JSON log. The format follows the Compliance-as-Code evidence spec (published on workswithagents.dev).
bastion export
produces an evidence pack. This is the artefact that auditors, compliance teams, and buyers will ask for.
The gateway makes no outbound calls except the traffic you route through it. No telemetry, no phone-home, no account.
Read the source. Apache-2.0. Run it yourself.
docker run -p 8080:8080 \
-v ./policy.yaml:/policy.yaml:ro \
ghcr.io/vystartasv/bastion-gateway
Point your agent's base_url
at http://localhost:8080
. That is the only change.
Self-host is live and free. A hosted version β long-term evidence retention, phone approvals, team policies β is a waitlist, not a promise.
This is infrastructure, not promises.