The kernel-level approach is the right answer for protecting the host from the agent — landlock and seatbelt give you deterministic enforcement that the LLM can't reason its way around. What I find interesting is the complementary layer above this: even with a perfect sandbox, you still need application-level policy for what the agent is allowed to do within its permitted scope. A sandboxed agent can still send all your emails or delete all your files if those operations are within its allowed syscalls. The two layers solve different problems and both seem necessary.
The hash-chained audit trail is a nice touch — append-only logs are underrated for agent governance. Curious how you handle the policy definition UX for teams without security backgrounds. JSON rules are expressive but require knowing what to block in advance. Most developers don't know their risk profile until after something goes wrong — which is part of why I think automated scanning before policy definition matters. Does AgentBouncr have any way to suggest policies based on what tools the agent actually has access to?
The supply chain angle is the right framing — the typosquat example with mcp-servr-github is exactly the kind of thing that's hard to catch manually.
One thing I've been thinking about in this space: static scanning at install time is necessary but not sufficient. A server can pass a clean scan and still behave dangerously at runtime — either because it changes its tool descriptions after installation (the MCP rug pull attack Invariant Labs documented), or because two individually safe tools create a dangerous combination when chained together. Email access alone is fine. Web browser alone is fine. Together they're a data exfiltration path that no static scanner would flag.
Curious whether MCPShield has any plans to address chaining and runtime behavior, or if the focus is intentionally on the pre-deployment supply chain problem?