Agent safety discussions often collapse three different questions:
- Role preflight — Is this task inside the declared authority of this role?
- Diff verification — Did the actual changes satisfy acceptance criteria without weakening tests?
- Runtime authorization — Is this exact side effect allowed now?
They catch different failures.
A role contract can reject a read-only reviewer being assigned an implementation task. It cannot prove the runtime obeyed the contract.
A diff check can catch an ordinary write that disables a test. It cannot decide whether the writer was authorized.
A runtime broker can stop a send or deploy. It may still permit the wrong actor if the policy never modeled the role.
I'm maintaining Agent Role Contracts (ARC), an open-source, offline preflight for explicit role/task declarations.
Important limit: current stable ARC evaluates supplied declarations. It does not observe runtime behavior and does not prove that a platform enforced anything.
I want to turn this into public comparison receipts instead of another abstract framework. For each volunteered workflow, the evaluation is:
- use one sanitized completed task
- record the incumbent controls
- run a baseline PASS
- introduce one real contradiction
- repair and rerun
- publish setup time, false positives, missed controls, and a keep/remove decision
The evaluation template is public.
Three fixtures I especially want:
- the tools stay the same, but a role crosses from read to send
- an in-scope write weakens a test or acceptance condition
- a read-only reviewer is asked to implement
If you have a workflow, reply with one completed task or repository and the controls you already use. I'll do the mapping and publish the receipt—including where ARC adds nothing.
Which layer is your real stop condition today, and what failure does it still miss?
Top comments (2)
Which layer do you expect to catch the case where the tools stay identical but the target changes, say an agent with a click tool moving from a test inbox to a real one?
From the Auten team (we build a screen-control MCP), honest answer to your closing question: our "ask before any buy/delete/send click" rule is instructions to the model, so it sits closer to your role preflight than a real stop. The one hard runtime stop we have is saved logins pinned to the site they were first used on. What neither catches is a correct-looking Send with the wrong content.
For me it's the diff layer, and it got fooled once by a test that never ran. On an Android build the agents had to break a file on purpose to show each test could fail. One broken copy first came back green, because Gradle restored the test task from its build cache. The drawable files the test reads weren't declared as inputs, so changing one left the cache key the same. Now every control run has the cache off and has to show the test task actually executed.