Internal audit has heard the words "AI writes our tests" and wants a control, not a paragraph. Saying that agents only write proposals is exactly the kind of claim they will ask me to evidence.
What is the concrete answer? Ideally something they can verify themselves rather than take from me.
Show them three things, in this order.
The write path. Every agent role and every write tool produces a directory under proposals/<id>/ — a manifest, the files, a diff. feature_write over MCP does the same. There is no code path from a role to your feature files; the only thing that applies a proposal is sdods proposals accept <id>, run by a person, and the manifest records who accepted it and when.
The tool surface. Have them read it themselves rather than believing the list:
sdods mcp -p demo-shop --caps all --list-toolsEvery tool carries an access level — read, run or write — and write means "produces a proposal", not "edits a file". That output is generated from the registry, so it cannot be stale.
The sandbox, if you are running roles through a coding CLI. The claude-code adapter is invoked with --disallowedTools Bash Write Edit, and the codex adapter with a read-only sandbox. So even the general-purpose file tools those CLIs have are off.
For an auditor, the second one is usually the persuasive one, because they run it.
Add the token side if the agents reach a hosted server, since that is the boundary an auditor recognises: scopes are checked at creation and at use, a token's scopes must be a subset of its owner's role, and a tool the token cannot call is never advertised to the client.
We gave audit a viewer token and let them point their own editor at /mcp. Watching the write tools simply not be there ended the conversation faster than any document did.
sdods tokens create --user audit --name review --scopes projects:read,features:read,runs:read --expires 30dHave the same question?
Ask it with the command you ran and the output you got, and it will be answered here.
Ask a question