A pattern is settling into the AI agent security stack: when you're unsure about a skill, tool, or plugin, you detonate it. Drop it into a sandbox — a detonation chamber, a honeypot environment — let it run for real, and watch what it does. Does it phone home? Does it read files it shouldn't? Does it unpack additional payloads?
It feels rigorous. Execution is truth; static analysis is just reading. And dynamic analysis does catch things static analysis misses — unpacked payloads, environment-triggered behavior, exfiltration that exists nowhere except at runtime.
But here is the framing problem. A sandbox run is a physical exam: a controlled check-up, in a clinic, on a good day, before the patient starts living their life. It is not a black box: the tamper-evident recorder running during the actual flight, readable by investigators who don't trust the airline.
Both matter. They are not interchangeable, and treating the exam as the recorder leaves a specific, predictable gap.
What dynamic detonation gets right
Let's be fair to the sandbox, because it earns its place. Static analysis reads code and reasons about what it could do; dynamic detonation watches what it does do. That distinction is real. Some behavior exists purely at runtime: payloads that decrypt themselves in memory, network calls assembled from environment state, logic that branches on what it finds on disk. If you never execute the artifact, you never see that side of it.
For agent skills and tools — bundles of code that an LLM can invoke, often sourced from third-party registries, often with broad permissions — "run it in a cage and watch" is a genuinely useful pre-release check. It should be part of the pipeline. The argument here is not against the sandbox. It is against asking the sandbox to do a job it structurally cannot do.
Boundary 1: coverage is an arms race, not a one-time build
Anti-sandbox and anti-honeypot evasion is a roughly twenty-year-old arms race in the malware world, and it remains unresolved — managed continuously, never finished. A sample can check whether it is being watched: timing delays and sleep timers, virtual-machine fingerprints, the absence of mouse movement or browser history, telltale environment variables, user-data directories that look freshly faked. Detect the clinic, and you behave like a model patient. The malicious payload waits for what looks like real life.
This has a direct consequence for agent security tooling. When a vendor quotes a dynamic-analysis catch rate — runtime detonation recovering a meaningful share of what static analysis misses — ask the mirror question: what share of malicious behavior does the detonation chamber itself miss, and who measures that? In detection engineering, a detector cannot prove its own completeness. The evasions you can observe are the ones you already know about; the evasion that stays quiet in your environment is, by construction, invisible to you. Coverage is a maintenance contract, not a build artifact — which means a sandbox you stopped tuning is a sandbox whose edge is eroding.
Boundary 2: slow and expensive — a deployment gate, not a runtime gate
Real detonation costs real things: environment construction, warm-up, a timeout window long enough to catch delayed payloads, resource isolation, teardown. That budget is fine for a release pipeline. It is not fine for the request path.
An agent in production makes tool calls constantly — each one a decision point — and you cannot route every call through a multi-minute detonation without making the agent unusable. So the sandbox sits, structurally, before deployment: it audits the artifact you shipped. Everything that happens afterward — production traffic, real sessions, real users — happens outside its field of view.
This is the physical-exam property. The exam happens before the flight. It cannot watch the flight, no matter how thorough it was.
Boundary 3: honeypot behavior is not production behavior
Even when the sandbox watches a run, it watches a drill. The clinic has synthetic inputs, disposable credentials, empty data directories, and no real user in the loop. Production has the opposite: real documents, live tokens with real permissions, and chained calls where tool B receives output shaped by tool A — chains that can run many steps deep by the time something goes wrong.
Plenty of real incidents live in that gap. Code that behaves in a demo environment but reaches for the customer database when a real database exists. A tool that is harmless with a dummy API key and aggressive with a valid one. A chain where each step looks fine individually and the composition is the exploit. You audited the rehearsal. The accident happens on opening night.
"OS-level logs can't be faked" — they can
One defense of dynamic execution is that the operating system sees everything: syscalls, file access, network connections. Logs at that layer get treated as ground truth.
They are ground truth right up until the thing you are watching holds administrator or root privileges — which is exactly what a malicious tool, an exploited dependency, or a successful sandbox escape hands an attacker. Code at that level can hook syscalls, suppress its own traces, wipe or rewrite audit records, and feed the observer a clean narrative. A log written by the party whose behavior is in dispute is self-reported evidence.
Aviation is instructive here. The pilot's handwritten logbook is useful, but nobody mistakes it for a flight recorder. A black box is engineered so the pilot cannot rewrite it after the fact: tamper-evident, write-once, readable by people who do not trust the emitter. If your "runtime evidence" is produced and stored by the same runtime you are auditing, you have a logbook.
What an agent black box actually looks like
The useful unit is a per-invocation receipt: one record per tool call, emitted as the call happens, with properties that make it evidence rather than a report:
- Cryptographically bound to the specific invocation — signed, with hashes covering the caller, the tool, the arguments, and the authorization under which the call ran. A receipt you cannot tie to a concrete call is decorative.
- Anchored outside the call path — verifiable by a party who is neither the emitter nor on the execution path: an append-only transparency log, a remote-attestation flow, any arrangement where rewriting history means breaking the anchor, not merely breaking into the box.
- Three states kept separate — the agent's decision (what it chose to call and why), the provider's outcome (what the tool reported back), and the observed effect (what actually changed). These routinely disagree, and collapsing them into one "success/failure" field hides exactly the disagreements that matter.
- Indeterminate stays indeterminate — when evidence is missing, the state is "unknown," and policy fails closed. "No evidence of malice" must not be recorded as "verified safe."
This is the direction of open standards discussions in the MCP and agent security community: signed, verifiable invocation records rather than vendor-narrated dashboards. The format is less important than the property — evidence has to be checkable by someone with every reason to distrust the system that produced it.
Use both — they do different jobs
For teams building or shipping agents, the practical split:
- Before release, do the physical exam. Static analysis plus dynamic detonation of skills and tools. You do not need an elaborate program for this; free and open toolchains cover the large majority of the basics — scan the code, detonate the artifact, fix what surfaces. Run it on every release, because coverage decays.
- During production, require the black box. Your agent framework should emit verifiable decision records — who acted, what action, under what authorization, with what result — cryptographically signed and anchored somewhere the emitter cannot quietly rewrite them. If your framework cannot do this yet, that gap deserves more attention than another dashboard.
- When evaluating agent security tooling, ask one question up front: does it produce evidence you can verify independently? A dashboard the vendor controls tells you what the vendor's system chose to record. That is a report. It is not evidence until a party outside the trust boundary can check it.
The exam does not replace the recorder
Sandboxes are good engineering. Detonate suspicious code, watch it run, catch what static reading cannot see — keep doing all of it. Just do not mistake the pre-flight check-up for the flight recorder. The exam tells you what a tool does when it is being watched in a clinic. The black box tells you what actually happened, in production, in a record the tool cannot rewrite.
If you want the physical-exam piece today, we publish a scanner that runs locally: npx correctover-scan@latest. It is MIT-licensed open source and zero-upload — your code does not leave your machine, and there is nothing to sign up for. There is also a web entry point at https://correctover.com/scan.html. For the runtime side, take the same question to your framework and your vendors: where is the receipt, and who can verify it without trusting you?
Top comments (0)