Your agent's tool loop is a supply chain now. Every install adds code you didn't write to a runtime you're responsible for, and the interesting security question isn't whether the install was verified — it's what happens when that code runs. If you want to sandbox agent apps at runtime, you need four things: artifacts that can't be swapped after verification, permissions scoped to declared grants, a supervisor that owns the process lifecycle, and a call surface narrow enough to audit.
This post walks the threat model, the four controls that actually limit blast radius, and one concrete implementation you can inspect today: the app store in Pilot Protocol, an open-source overlay network for AI agents. Its security model is documented in the Pilot Protocol app store docs, and every claim below comes from there.
Why "verified at install" isn't enough
Install-time checks are point-in-time. A signature check when you fetch a package tells you the artifact was intact then. It says nothing about the binary that gets executed minutes later, after a cache swap, a symlink trick, or a compromised update channel. This is the classic time-of-check-to-time-of-use (TOCTOU) gap, and it's worse for agents than for humans because nothing pauses to review: an agent installs a tool, reads its output, and acts on it in the same loop.
The runtime threat model for installed agent apps is roughly:
- Prompt injection via tool output. The tool returns content that re-directs the agent. The most famous variant, but only one of several.
- Buggy or malicious tool code. The app itself misbehaves — reads files it shouldn't, opens sockets, exhausts memory or file descriptors.
- Data exfiltration. A tool with network access can ship your context out. This is why "can it reach the network?" has to be an explicit, grantable property, not a default.
- Crash loops and resource abuse. A misbehaving app that dies and respawns can become a denial-of-service against your own host.
"Verified at install" answers none of these. Sandboxing agent apps at runtime means the environment — not the artifact's provenance alone — is what constrains the damage.
Sandbox agent apps at runtime: four controls that matter
If you're evaluating any agent runtime (or building your own), these are the four controls to look for. Together they form a defense-in-depth story; each one alone leaves a hole.
1. Signed artifacts, re-checked at launch. The manifest pins the binary's sha256 and carries an ed25519 signature. The daemon verifies the signature when it scans installed apps, and re-checks the binary's hash immediately before every spawn — rejecting it if it became a symlink or no longer matches the pinned hash. This closes the TOCTOU gap: a binary swapped between install-scan and launch is caught before it runs.
2. Grant-scoped permissions, no ambient authority. The manifest declares exactly what the app may do — network, file I/O — and a broker enforces those grants at runtime. Installing an app accepts its declared grants; nothing more. There is no "joined the system, therefore trusted" default, which is the failure mode of most plugin architectures.
3. A supervisor, not a launcher. The runtime supervises the app's lifecycle: auto-spawn on install, crash-loop detection with exponential backoff, suspension after repeated failures, and resource limits (file-descriptor and address-space caps) so a misbehaving app can't take the host down with it. Lifecycle events go to a rotating audit log.
4. A typed call surface. Each app method is a JSON-in/JSON-out call, and the manifest's exposes set is the entire dispatchable surface. The broker refuses anything not listed there — even requests from the daemon itself. No browser, no REST plumbing, no hidden endpoints: a surface small enough to audit is a surface you can actually reason about.
A worked example: Pilot Protocol's app store
Pilot Protocol's app store is a useful case study because it's young, open source, and unusually explicit about its threat model. The loop an agent runs is discover → install → call:
# 1. Discover what's installable
pilotctl appstore catalogue
# 2. Inspect before committing — description, vendor, methods, permissions
pilotctl appstore view io.pilot.cosift
# 3. Install by id — fetch + verify sha + signature; the daemon auto-spawns it
pilotctl appstore install io.pilot.cosift
# 4. Call a method — JSON in, JSON out
pilotctl appstore call io.pilot.cosift cosift.search '{"q":"raft consensus","k":"5"}'
Every layer is deny-by-default. The catalogue itself is signed with a dedicated ed25519 key whose public half is compiled into the client, so a compromised host or CDN can't redirect installs to hostile bundles. App-to-app calls go through the daemon's broker, which enforces two gates before dispatch: the exposes gate (the method must be in the target app's declared surface) and the grant gate (the caller must hold a matching ipc.call grant). The supervisor re-verifies the binary's hash at launch, applies resource limits, and backs off on verification failures.
One honest caveat worth stating plainly: OS-level sandboxing like landlock or seccomp isn't wired in yet. Today the enforcement is rlimits plus the syscall/IPC broker, not a kernel sandbox. That's a real boundary — but it's also exactly the kind of admission that makes the rest of the model credible, and it's the right thing to know before you run third-party apps in a hostile environment.
The store even ships a runtime firewall as an app: AEGIS blocks prompt injection before your agent reads the content — the same class of defense this article is about, applied at the input layer.
What to check before you run third-party agent code
Whatever runtime you use — MCP servers, plugins, a homegrown tool loop — run this checklist against it:
- Who signs, and who can rotate? A signature is only as good as the key custody and the fail-closed behavior when verification fails.
- What does it declare, and what can it actually touch? Does the permission model match the manifest, or is there ambient authority?
- Who supervises it? Is there a process owner that detects crash loops, bounds resources, and logs lifecycle events?
- Can it be revoked? If an app turns hostile or gets compromised, is removing it a real operation or a fantasy?
- Is the surface auditable? Can you enumerate everything the app can do — and would you notice if that list changed?
The pattern that holds up across all of them: trust the artifact at install, but constrain the process at runtime. Install-time verification decides what you let in; runtime sandboxing decides how much damage it can do once it's there.
Pilot Protocol is one implementation of that pattern, and it's free to try. If you want to poke at the model yourself:
curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl appstore catalogue
Install something, read its manifest, watch what the supervisor does. The app store docs spell out the whole security model — worth a read before you run your next agent's tools.
Top comments (0)