Cool project!
I went to a Korean university more than 190 years ago and can only speak basic Korean but going through your examples seem to be improving my Korean vocabulary!
We've been working on a warrant model that ensures task-scoped authorization: constrain your agents to specific tools and specific arguments, cryptographically enforced at the MCP tool boundary. Even a fully compromised agent can't reach outside its warrant. Open source. github.com/tenuo-ai/tenuo
The boundary also needs to hold if the agent is compromised. Proxying keys is the right instinct. We took the same approach at the action layer: cryptographic warrants scoped to the task, delegation-aware, verified at the MCP tool boundary before execution. Open source core. https://github.com/tenuo-ai/tenuo
The two-layer framing is right. Sandbox-exec contains local blast radius, and that's important. But if the agent already has a credential in memory, sandboxing the filesystem doesn't help.
I've been working on a primitive for scoped authorization at the tool call level: what was this agent allowed to do, for which task, signed by whom. The core is open-sourced: https://github.com/tenuo-ai/tenuo
Good distinction, but I wonder if it's worth going further: context integrity may be fundamentally unsolvable. Agents consume untrusted input by design. Trying to guarantee the model won't be tricked seems like the wrong layer to bet on.
What seems more promising is accepting that the model will be tricked and constraining what it can do when that happens. Authorization at the tool boundary, scoped to the task and delegation chain rather than the agent's identity. If a child agent gets compromised, it still can't exceed the authority that was delegated to it. Contain the blast radius instead of trying to prevent the confusion.
This is exactly right. We went down this path and the practical implementation ends up looking like capability tokens. short-lived, cryptographically signed credentials that encode what the agent is authorized to do for this specific task.
The key insight: the token isn't just authorization, it's evidence.
When you issue an ES256-signed token that says "this agent was scanned for PII, classified as INTERNAL, and is authorized to call [search,read_file] for the next 60 seconds" , that token becomes the audit artifact. The auditor doesn't need to the agent or the operator; they verify the token chain.
On "contain the blast radius instead of preventing the confusion"
agreed, but you need both. Containment (scoped permissions, delegation
chains) handles authorization. But you still need a detection layer
for data protection: PII flowing to an external model is a GDPR or EU AI Act (def. in europe) violation regardless of whether the agent was "authorized" to make that call. We found deterministic scanning (regex + normalization, not LLM judges) at the proxy layer catches this at ~250ms without the reliability problems of using another model to judge the first one.
The ergonomics point tucnak raised is real too. We use OPA/Rego for the policy layer with presets so operators don't have to write Rego from scratch, pick a security posture and tune from there. The governance tax has to be near-zero or teams just bypass it.
Right on. Human-in-the-loop doesn't scale at agent speed. Sandboxing constrains tool execution environments, but says nothing about which actions an agent is authorized to take. That gets even worse once agents start delegating to other agents.I've been building a capability-based authz solution: task-scoped permissions that can only narrow through delegation, cryptographically enforced, offline verification. MIT/Apache2.0, Rust Core.
https://github.com/tenuo-ai/tenuo
Spot on. You could argue that most companies buying B2B SaaS could almost always build a clone internally but they need someone to assume SLA and liability.
The Agent Swarm section is fascinating. I'm working on authorization for multi-agent systems so this is relevant to my interests. Lots of interesting parallels to capability-based security models.
Exactly ... and that's why I'm skeptical of "AI verifies AI" as the primary safety mechanism. The verifier for moving money should be deterministic: constraints, allowlists, spend limits, invoice/PO matching, etc. The LLM can propose actions, but the execution should be gated by a human/polic-issued scope that's mechanically enforced. That's the whole point: constrain the non-deterministic layer with a deterministic one. [0]
[0] https://tenuo.dev/constraints
Task-scoped "warrants", attenuating with delegation, and enforced cryptographically at tool call.
Macaroons/Biscuits for agents basically.
reply