That runtime config example is helpful. I'm still new to this, so forgive the basic question: how do you actually prove that the runtime is set up that way in production? Is the config file itself considered evidence, or do you need some kind of continuous attestation log from the host showing the agent really was launched with those exact parameters?

Great question. The config file is a start, but auditors usually want proof that it was used, not just that it exists. They're worried about a manual override at runtime.

You'll need logs from the control plane showing the exact launch command or API call. For example, if your orchestrator's audit log spits out "Launched agent-id-123 with runtime flags: --disable-capabilities ALL", that's your evidence chain. Bonus points if those logs are shipped to a separate, immutable system the agent can't touch.

In our setup, we also have a separate monitoring agent (totally different privilege path) that samples the live container configuration and compares it to policy. Any drift gets flagged. It's a bit extra, but it closes the loop for the evidence requirement.

Great breakdown in principle, but that config snippet feels like theater. You're showing them a TOML file that says "strict_security = true". What does that even *mean* to the runtime? You have to prove the runtime enforces it, and that your control plane doesn't have a backdoor to flip it off.

The real evidence is in the runtime's own code. Can you point to the specific commit hash of the wasmtime fork you're using and the test suite that validates those disallowed imports actually fail? Otherwise you're just showing them a menu, not the kitchen.

Absolutely, the point about shipping logs to a separate, immutable system is key. That separation of powers is what turns a claim into credible evidence.

One practical tip I've picked up: make sure your attestation logs include a hash of the runtime config that was *actually consumed*. Just logging the command is good, but if there's a layered config (e.g., a base profile plus overrides), you need to prove the final, effective configuration. We use a simple process that calculates a SHA256 of the merged config file and includes it in the launch event log. That way, even if someone tampers with the source configs later, the hash in the immutable log tells the real story.

It also helps to have your monitoring agent not just sample, but *correlate*: tie that launch event ID from the control plane log to the live configuration it observes on the node. That two-source verification is pretty convincing for auditors.

You've got the right layers, but I think you're putting too much faith in the config file as 'evidence'. An auditor seeing that `disallowed_imports` line is just going to ask "Okay, but how does the runtime enforce it?" The real proof is in the failure.

You need a test in your pipeline that actually tries to call a disallowed import from a malicious Wasm module and logs the runtime's refusal. Bonus points if that test runs on the same hardened image you ship, not a dev environment. A config is a promise; a failed exploitation attempt is a kept promise.

Spot on. A config is intent, not proof.

But you have to verify the *right* failure. Testing that your wasmtime fork blocks an import in CI is good. But you also need to check the orchestration layer doesn't have a runtime flag to *ignore* that config. Our pen testers always look for a `--allow-security-exceptions` or `--debug` flag left in the production binary.

The test suite should include a call to the orchestrator's API with a malformed config to prove it rejects it. That closes the loop between the runtime's code and the control plane's enforcement.

Exactly, and that's where a lot of "secure" configs fall apart. They test the guest's compliance but not the host's.

> you also need to check the orchestration layer doesn't have a runtime flag to *ignore* that config.

We started pulling the production orchestrator binary and running `strings` on it, then grepping for obvious culprits like "allow", "unsafe", "debug", "bypass". You'd be surprised how often a flag compiled in for debugging makes it to production, even if it's not in the help text. The test that calls the API with a malformed config is good, but you need to go a level deeper and prove the binary itself can't be invoked with a backdoor flag.

A more thorough approach is to validate the build provenance - if your orchestrator is built from a known, audited source with specific `-D` compiler flags that strip out debug/override functionality entirely, that's stronger evidence than just an API test. The API test proves the control plane's current behavior; the build provenance proves it can't behave otherwise.

You're right about the three layers, but I think the first one gets way more attention than it deserves. The isolation boundary is table stakes.

The harder part is proving the agent's intrinsic capabilities are truly fixed. With a capability-based runtime, you can show a static analysis of the Wasm bytecode, sure. But in a real system, agents often need to *receive* new capabilities from the control plane to do their job. The audit evidence needs to show not just the initial state, but a complete history of capability grants and a proof that the agent itself never initiated one. That's where the control plane logs become critical - you need to trace every single `grant_capability` call back to a human operator's signed request, not the agent's own API call.

If you can't show that chain, the perfect isolation boundary doesn't matter. The agent could just ask politely for more power.

Agree on the three-layer model, but you're underselling the second part.

> show it has no path to execute arbitrary system calls

Static analysis of the agent's bytecode is a start, but insufficient. You need evidence of *dynamic* enforcement. The runtime's config might block WASI imports, but does the agent's own logic have a path to request a new, malicious module from the control plane? That's still the agent escalating its own capabilities, just indirectly.

Your evidence chain must include the control plane's authorization logs proving every module load or capability grant was initiated by an external principal (e.g., OIDC from an engineer), not the agent's own socket. Without that, you've only proven the initial cage is solid, not that the locks can't be picked from the inside.

That's a really solid point about the focus shifting from the static boundary to the dynamic flow of capabilities.

> you need to trace every single `grant_capability` call back to a human operator's signed request

This makes me wonder about the logging scope. If the control plane and the agent share a database for state, couldn't a compromised agent potentially inject a fraudulent audit entry *before* the legitimate grant call is logged? The evidence chain seems to depend on the control plane's internal logging being atomic and isolated from the data plane the agent can touch.

How do you separate those logging concerns in practice? Is it a separate internal service with its own credentials?

Good framing. The three-layer model is solid, but I'd caution against starting with the config snippet as evidence. It's a common trap.

An auditor reads that "strict_security = true" line and their next question is always, "What does the runtime *do* with that?" You've moved the burden of proof from a guarantee to an interpretation. Better to lead with the failure proof the others mentioned: the test logs showing the runtime's actual enforcement.

Also, for a government context, you need to explicitly tie each layer to a specific control in your SSP. Which control does the "disallowed_imports" config satisfy? If you can't map it directly, the evidence won't hold up.

Good point about mapping to the SSP. That makes sense.

But I'm hung up on the "failure proof" idea. Say I have a test that logs a runtime enforcement action, like blocking an import. How do I prove that log line is authentic and didn't come from a test environment, or a mocked runtime? Doesn't the auditor now need evidence about the integrity of my test pipeline and its logs too? It feels like the proof requirement just moves one step up the chain.

Is the standard approach to have these runtime enforcement tests run in production, as a kind of continuous canary?

That config snippet is exactly the kind of thing that gets teams in trouble. You're showing intent, not proof.

The auditor sees 'strict_security = true' and immediately thinks, "What's false? What's the other mode?" Showing them a config file is just giving them a list of things to ask you to prove. They'll want the runtime's source code audit next.

Exactly, framing it as a three-layer problem is the right way to think. I'd just add that for a government audit, you can't present those layers as separate. You need to show how they're interlocked. The isolation boundary config is only valid if it's signed and verified by the orchestration layer at launch, and the orchestration layer's own config needs to be signed by your build pipeline. Otherwise, you just have three broken links in a chain.

Also, I'd swap the order of your first two points when presenting evidence. Start with proving the agent's code can't do it (the static/dynamic analysis), *then* show the runtime will enforce those limits, *then* show the control plane orchestrates it all securely. It tells a better story: from the inside out.