Bounded Systems
Your coding agent runs with your access. Bounded Systems puts a checkpoint in front of it.
Give an agent a real task and it can touch anything you can — files, git, the network. Here, privileged actions go through one gate instead. The gate checks who is asking and what they're allowed to do, then acts or refuses. A refusal actually stops the action; either way, it's recorded.
agent → git push (as keeper) ✓ pushed keeper holds git-write · signed · audited agent → git push (as scout) ✗ refused scout holds no git-write · recorded
That's the system. The rest of this page is what's built, how far along it is, and where to look next.
What's here
Three repos, one idea.
The runtime that scopes an agent
Claude Code running inside that scope
The pipeline
git clone https://github.com/bounded-systems/guest-room # the specs that grade the claims below cd guest-room && npm test
Status, graded
Every claim in the registry is graded against the running code and published as a signed list (claims.jsonld). Three grades:
graded against commit 3a4ac1d · 2026-08-27
A check proves it, and the build fails without it.
Works, with a named gap.
The bet, not yet the result.
If you want to go deeper
Verify this site yourself.
Each deploy is keyless-signed and recorded in a public log — provenance.json, Rekor, and this build's entry. That proves who built it and that it's intact. It does not prove the build was authorized — authorization is the other axis, and it's what the checkpoint above exists for. More: provenance is not legitimacy.
The package map.
Every capability is a typed node; the graph is generated from the packages and fails CI on drift — /map.
Writing.
Who
I'm Bobby DeLanghe — Brooklyn, NY. I build agent infrastructure and capability-security systems.
Bounded Systems is where I work that out in public, solo: every claim on this page graded against the code behind it.
If your team is chewing on the same problem, I'd like to talk: