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 (4)
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.
I’d expect three gates to cooperate here:
Your saved-login site pin is real runtime enforcement for #2. The ask-before rule supplies declared intent for #1. The gap you described—a correct-looking Send with the wrong content—needs #3. Identical tool definitions do not settle it.
I’m testing the analogous unchanged-tools/read→send boundary in ARC #69. Would Auten be able to expose the resolved target, normalized action, and payload digest to a host-side gate before the click? That would make a clean same-condition comparison.
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.
That is a strong example. If Gradle restores the task from cache, a deliberately broken control can still produce a false green, so the negative control has not actually proved the test is live.
Your fix separates two receipts that are often collapsed into one: the mutation was observed, and the test task actually executed against it. I’m going to treat cache state and task-execution identity as part of the evidence envelope instead of accepting exit 0 alone.
Do you also pin or verify the declared Gradle inputs now, or is cache-off plus task-executed evidence the boundary you found sufficient?