What we're building, and why
A new class of actor is in production now: autonomous AI agents that take their own actions — touching real systems, with real consequences. SAWP is the runtime boundary built for that class — full power inside the sandbox, full control on the way out.
How we got here
We started SAWP because the same wrong instinct kept winning in every engagement we touched.
Consulting for companies adopting AI agents, two patterns showed up everywhere. Ad-hoc agent runtimes spun up against production credentials, no governance, no audit. Or — at the other extreme — agents wrapped in a tangle of bespoke MCP servers and tool definitions, reinventing protocols for things a shell and an HTTP client have already done well for decades.
Both miss the point. The hard question isn't what tools an agent has access to inside its sandbox. It's what an agent is allowed to affect outside the sandbox — and there's no standard runtime for that. So we started building one.
The thesis
IAM didn't make cloud servers better. It made cloud acceptable at enterprise scale.
That's the thing we think is missing for autonomous workloads. The question keeping agents read-only, supervised, and stuck on toy problems isn't "can it figure this out?" — it's "what if it goes wrong, and how would we know?" The absence of an answer is the ceiling on adoption.
The work isn't to make agents smarter. It's to make autonomous behaviour deployable. A real, enforced boundary turns "we couldn't trust it with that" into "we can let it run." That's the unlock.
What we believe
Give agents a real computer, not a custom protocol.
A tangle of MCP servers and bespoke tool definitions is the industry's current detour. Agents have judgment and a shell — let them use both. We're betting the protocol overhead falls away as the boundary gets real.
Hide credentials from the agent — don't just protect them.
App-layer secret management is a wish. A network that can't expose your keys is an answer. Same logic for identity, audit, and policy: runtime properties, not application-code conventions.
Without a runtime boundary, every autonomy decision is a risk decision.
That's the ceiling on what teams will let agents do. The boundary isn't what restricts agents; its absence is.
Define this in the runtime, not in app code.
Every other modern security model lives at the runtime layer — kernel, network, IAM. That's where rules become enforcement, not just declarations.
How we're building it
-
Hosted product first.
A real platform that real customers run real workloads on. Get the abstraction right by working with people who feel the pain.
-
Then open the foundation.
Once the model is proven, open-source the runtime, the proxy, and the capability spec. Governance infrastructure that requires trust in the vendor's binary is not, ultimately, governance infrastructure.
-
Then a community marketplace.
Capability packs for the APIs people actually use. Compliance templates that aren't yours to write from scratch. The platform curates; the community contributes.
We're at step one — hosted runtime live, working with early customers.
The team
Built by engineers with backgrounds in machine learning at Apple, production LLM systems and distributed-systems architecture at Piano, and over a decade of platform engineering across European product companies.
SAWP sits between them: AI systems that don't behave predictably, and infrastructure that has to. The team's shared bias: care more about what survives production than what survives a demo.
Talk to us
If you're running 5-20 agents and feeling where this starts to bend, we'd like to hear about your setup.