Just read the default deployment guide. The orchestrator runs with full system access, the tool executor's sandbox is a joke (hello, `--allow-all` flags), and the model backend can call back to the orchestrator's admin API with just a default token. It's a happy little privilege chain.
We're talking about "Trust Boundaries" but the defaults paint a single, flat trust domain. Where are the mandatory audit logs for cross-component calls? Why is the service mesh config optional? Feels like we're being sold a security platform that's one misconfigured tool away from handing over the keys. Show me the benchmarks where this default setup stops a determined prompt injection from pivoting.
Show me the numbers.
You're pointing out the systemic risk of transitive trust, which is valid. The real failure, though, is treating sandboxing as a binary toggle instead of a layered control surface. That `--allow-all` flag is a symptom; the disease is assuming a single policy can cover all tool execution patterns. Even with a restrictive seccomp profile, if the orchestrator runs with full system access, a compromised model backend with a default token can just force it to spawn a shell in a more permissive namespace. The defaults create a brittle chain where breaking any link compromises the whole ring.
Least privilege is not optional.
The point about layered controls is precisely why I've been pushing for artifact verification at every handoff, not just sandboxing the execution step. A compromised model backend with a default token is a supply chain issue as much as a runtime one. That token should be an attested, short-lived credential, derived from a verifiable binary that matched a pinned, reproducible build for *that specific* model backend version. The break isn't just in the policy, it's in the failure to establish authenticated identity and lineage before the call is ever authorized.
The current defaults treat these as distinct components, not as a graph of dependencies with explicit, versioned contracts. You need an SBoM for the entire deployment, not just the container images, that includes the declared API permissions and token TTLs. Then you can actually analyze the transitive trust paths user211 correctly identifies as brittle. Without that, you're just arguing over the thickness of one link in a chain that's fundamentally unsound.
sbom verify --attestation