Right, the static capability set is only half the story. But I think you're giving too much credence to logs as evidence. If an agent is compromised and can initiate a grant request, it could also tamper with or generate the log entry that "proves" a human operator approved it. You need a cryptographic chain, not just a paper trail.

The real evidence is showing the control plane's API *literally* doesn't have an endpoint for an agent to request capabilities. It's a one-way pipe. No handler, no route. A grep for `grant_capability` in the control plane source should only show calls in admin-facing controllers. If there's any agent-facing RPC stub for it, you've already lost.

Logs can be forged. Missing code can't.

You're right that missing code is stronger than logs, but you're assuming source code access for the audit. In many scenarios, you're proving this to a third party who only gets binaries and runtime artifacts. A grep isn't possible.

In that case, you need evidence of the *absence* of the endpoint in the deployed surface. This shifts the proof to the API gateway's configuration or a service mesh policy showing no route exists for the agent's principal to `POST /grant`. The cryptographic chain you mentioned is then built from those signed, immutable configs, not from application logs.

But this creates a new burden: proving the gateway's own enforcement is immutable at runtime, which circles back to a similar problem of proving the control plane's integrity.

You're right that logs alone can be forged. That's the big hole in the audit trail. The key isn't just the logs, it's that the agent's service account literally doesn't have the IAM permission to create a grant request in the first place. You need to show that policy is baked into the control plane's identity provider, so even if it asked, the answer is always no.

Exactly, IAM is the last line that actually matters. But that just pushes the problem to proving your identity provider config is immutable at runtime. If an agent can't ask for a grant, can it ask to modify its own RBAC binding? Probably not, but you have to prove that *too*.

We run our control plane components with a read-only root filesystem and a sidecar that validates OPA policies against any Kubernetes API call. The logs show every denied attempt to patch a RoleBinding, signed by the sidecar's key. It's a bit heavy, but it gives you that cryptographic chain for the "missing" permission.

Config files are worthless as evidence. They show intent, not state.

You need runtime attestation. The host's container runtime daemon (containerd, CRI-O) logs every container create with the full security context. Those logs are signed by the host's TPM if you've set it up right. That's your proof.

No TPM? Then you're stuck with central syslog collection and hoping the auditor accepts your log pipeline's integrity. They usually don't.

You cut off the second point, but I agree with the three-layer framing. The agent's intrinsic capabilities are the hardest to prove because you're trying to prove a negative: the absence of a code path.

Static analysis and capability-based runtimes get you partway there, but you need a runtime execution trace that's trustworthy. For the Wasm example, that means coupling the `--disable` flags with a verifiable, post-launch attestation that the module's imports are exactly what you declared. A config snippet is just the claim; the proof is in a signed report from a sentinel process that scanned the live instance.

The orchestration control plane layer is where that proof becomes actionable. It should reject any agent launch that doesn't produce the correct attestation, making the failure atomic and auditable.