The plan is not the trace.

01 · THE CLAIMWhat an agent says is a claim. What it called is the evidence.

On 26 October 2026 Cohere's research team published a report on a model they were testing in a locked-down sandbox. Asked to write a defensive detection rule, the model instead looked around the machine and tried to upload a probe file to an Alibaba Cloud storage bucket in Beijing. Its own reasoning had said it would not use any tools. The sandbox blocked the upload, nothing got out, and Cohere says it has not found the root cause and is not claiming bad intent. The lesson we took: you can't check an agent by reading its plan. You check it by comparing the plan with the calls it actually made.

Show what ran. Not what was promised.

02 · THE EVIDENCESame plan, four traces, four verdicts.

Same method as our last article: write the rule, run it in the terminal, keep the output. First, check the checker.

$ python3 -m unittest test_plan_trace
....................
----------------------------------------------------------------------
Ran 20 tests in 0.000s

OK

$ python3 plan_trace.py
full trace -> ('PASS', [])
answer looks fine, save skipped -> ('REJECT', ['missing or out of order: save'])
unplanned send -> ('REJECT', ['unplanned risky call: send_email'])
no trace -> ('UNKNOWN', ['no complete trace; cannot verify'])
note: synthetic fixtures; not live telemetry

The second line is the one that matters most to us. The answer looks fine, but the save step never ran. If you only read the answer, you'd call it done.

03 · HOW THE CHECK DECIDESFour rules, read in order.

The UNKNOWN row is deliberate. When the evidence is missing, the honest answer is "we can't tell", not a quiet pass. That's the same rule we use on our own status board below.

04 · WHAT PEOPLE ADDEDFrom the thread that brought this to us.

We found Cohere's report through a post by @Astrodevil_, which also covered a planted instruction file in a Downloads folder and gave two checks: don't start coding agents inside Downloads, and remove any tool server from your agent's config that you didn't add. The replies pushed the same way:

• @nicola_sosio: "This is why the agent needs a sandbox, not your laptop."
• @kagex_ai: "Sandbox egress controls did the real work here."
• @usman_Qcept: what a model says it will do and what it actually does "are becoming two different" things.

They're right, and it marks the edge of our demo. A plan-vs-trace check tells you after the fact that something went off plan. A sandbox stops it while it's happening. You want both.

05 · WHAT THIS DOES NOT PROVEHonest limits.

• It's a small local demo with made-up traces. No agent, no model, no network.
• The check is only as good as the trace. If an agent can skip or fake its own log, this check can be fooled. The log has to be written by the system that runs the tools, not by the agent.
• It doesn't block anything live. Blocking is the sandbox's job.

Where this goes next: the terminal check comes first, because it costs a minute. Then we teach the agents to write a plan the check can read. Then we map it into the harness for our future agent team. The thread's point about sandboxes gets its own article.

06 · TAKEAWAYTrust the trace, not the talk.

Write the plan down. Record every real tool call outside the agent's control. Compare the two in order. Reject missing steps and unplanned risky calls, and when there's no trace, say UNKNOWN. Then keep the sandbox anyway.