Agent Guardrails and Secure Development
Keep release evidence attached to its build
The report belongs to the previous build
The dashboard’s green report predates the artifact Botie wants to release. Preserve what the checks actually inspected.
BOTIE
The inputs we are comparing
Current candidate
Same in both cases
{
"revision": "r2",
"artifact": "a2"
}Verified build evidence
The candidate has complete evidence
{
"revision": "r2",
"artifact": "a2",
"trustedRunner": true,
"checks": {
"tests": "pass",
"dependencies": "pass"
}
}The passing report predates the patch
{
"revision": "r1",
"artifact": "a1",
"trustedRunner": true,
"checks": {
"tests": "pass",
"dependencies": "pass"
}
}Required check names
Same in both cases
- 0tests
- 1dependencies
Result for the candidate has complete evidence
ready for release review
The same revision produced different bytes
This check uses the pieces from “Require matching evidence and complete checks”.
BOTIE
- Current candidate
{ "revision": "r9", "artifact": "a-new" }- Verified build evidence
{ "revision": "r9", "artifact": "a-old", "trustedRunner": true, "checks": { "tests": "pass" } }- Required check names
- 0tests
Use a number, text, or an array matching the requested result. For a matrix, put each row in brackets. Saving your prediction runs your current construction on these inputs and checks the earlier examples too.
Build a construction in the workspace above first. This case will test those pieces.
Who can write the evidence consumed by your release controller?
Verify the evidence source and candidate binding independently of candidate-controlled files.
These are invented records and deterministic policy checks. The browser runs no agent, shell command, MCP server or network request. Passing these fixtures establishes only the stated policy behaviour.
Work through the Python challenges →