Subtitle: Structural Isolation Over Trust (and How to Get It Ready-Made)
Track: Security & safety in agentic systems · Format: 30–40 min + recorded demo
Deck: ../talk-1/
Hook: Everyone's building agents, but how do you deploy them securely and keep the data with you?
Agent platforms increasingly execute code nobody on the team wrote, generated by an LLM, pulled from a third-party skill registry, or authored by a customer. The moment that code can call tools, touch the filesystem, and spend money, your "agent framework" is really a multi-tenant code-execution platform with an adversary inside it. Prompt-level guardrails don't contain a process that has already decided to misbehave.
This talk presents how we built a multi-tenant Go agent framework on
one principle: isolation must be structural, not conventional, enforced by the
layer below the agent (the Linux kernel, the crypto layer, the database primary
key), never by trusting agent code to follow the rules. We walk a concrete threat
model, secret theft, sandbox escape via planted binaries, fork bombs, runaway token
spend, supply-chain deploys, and show the mechanism that defeats each: Landlock LSM
sandboxes with non-executable working dirs, per-agent AES-256-GCM credentials whose
keys are bound to (workspace, agent) at construction, process-group tree isolation,
pre-call token budgets, HMAC-verified atomic deploys, and a tamper-evident
hash-chained audit log. We open with a real production incident (Meta's
account-recovery bot that changed a user's email and password just by being asked),
and we frame the whole thing as zero trust for agents: the same posture NIST,
OWASP, and Anthropic now name, with one operational test running through it, does a
control make the attack impossible, or just tedious? We close with the practical
shortcut: most of this isolation is a base layer you can buy instead of build, a
KVM micro-VM gives you a separate kernel per tenant and a natural unit for keeping
each customer's data inside their own boundary.
Engineers building or operating agent platforms; infra/platform teams about to let agents run real tools in production; anyone nervous about handing an LLM a shell.
- A practical threat model for treating agent code as adversarial.
- The structural-vs-conventional mental model, and how to apply it to your stack.
- Copyable controls: Landlock recipe, per-tenant key derivation, pre-call budget gate, hash-chained audit.
- When to stop hand-building and adopt KVM micro-VMs as a ready-made base.
- How the controls map to zero trust for agents (Anthropic / NIST 800-207 / OWASP least agency), with an honest Foundation→Enterprise→Advanced self-assessment.
- An honest map of what's solved and what isn't.
Five "what if the agent…" attacks, grounded in engineer9's real tools, each answered
by a structural control:
| Attack | Real-world stake | Structural control |
|---|---|---|
| Reads another tenant's secrets | holds AWS keys, Slack/Linear tokens | construction-bound credential store |
| Writes & executes a binary | can run shell | Landlock (writable ≠ executable) |
| Fork-bombs / loops forever | hourly heartbeat | process-group tree kill (cgroups = gap) |
| Burns $50k of tokens | calls Claude in a loop | pre-call budget gate |
| Deploys malicious code | skills ship via git webhook | HMAC + atomic versioned deploy |
Punchline: we assume the code is hostile and run it anyway, because nothing about the guarantee depends on the code being honest.
See the live deck. Arc: Act I (problem) cold-open (the Meta bot) → what is an agent →
whose code is it (origin changed) → prompts can't contain a process (Chipotle scope-creep) →
the naive mithai origin → thesis (structural, not conventional + the impossible-not-tedious test) →
threat model. Act II (mechanisms) five attack→defense pairs, each resolving from danger-red to
safe-green, with real code. Act III (reality) recorded demo → containment-rings recap →
"why not a container?" → the boundary that holds (KVM/CoCo) → "we built zero trust for agents"
mapping → Foundation/Enterprise/Advanced tier self-assessment → close ("make trust unnecessary").
Hi, I'm Shekhar. I want to talk about a problem that sneaks up on everyone who builds with agents: the moment your agent can run tools, touch files, and spend money, you're not running an "AI feature." You're running a code-execution platform , and the code came from an LLM, a third-party skill, or a customer. Nobody on your team wrote it. So you have to assume it might be hostile.
Most teams reach for prompt guardrails. But a prompt can't stop a process that has already decided to misbehave. By the time the code is running, the system prompt is just a suggestion.
In this talk I'll show how we built a multi-tenant agent platform on one rule: isolation has to be structural, not conventional. Every safety guarantee is enforced by the layer below the agent, the Linux kernel, the encryption layer, the database primary key, never by trusting the agent's code to behave.
I'll walk a real threat model. Read another tenant's secrets? Can't, the credential store is cryptographically bound to one agent at construction. Write a binary and run it? The kernel refuses, because the sandbox makes its directory writable but not executable. Burn fifty thousand dollars in a loop? We block it before the call. And every attempt lands in a tamper-evident audit log.
Then I'll be honest about what's still hard, and about the shortcut. We built this the hard way so we'd understand it. But most of it is a base layer you can buy: a KVM-based virtual machine gives you a separate kernel per tenant, and a clean way to keep each customer's data inside their own boundary.
If you build or operate agent platforms, you'll leave with a threat model, a set of copyable controls, and a clear answer to "how do I deploy this securely and keep the data with me." Because the goal isn't to make the agent trustworthy. It's to make trust unnecessary.
Recording: single take, plain background, no slides; land "make trust unnecessary" after a beat.