Hardening the agent harness and runtime

Why the harness is the control plane

The model decides what it wants to do. The harness decides what actually happens. It dispatches every tool call, assembles the context window, runs hooks before and after each action, and writes the audit trail. Treat it as application code with a hostile caller, because that is what an injected agent is.

Two layers carry the security weight, and they fail differently. The harness governs what the agent is permitted to attempt: tool scoping, hook enforcement, the Policy Enforcement Point. The host governs what a successful attempt can reach: network destinations, filesystem mounts, process boundaries, credentials. A flawless harness on a host that shares the developer's user account and SSH keys still hands an attacker the keys. Treat each as its own security problem, not as one undifferentiated pile of infrastructure.

Network egress: the single most effective control

An agent that cannot reach a destination cannot exfiltrate to it, no matter what it was tricked into deciding. Egress control bounds the worst case directly, which is why it earns the most attention.

• Default-deny outbound. The harness has no internet access until a destination is explicitly granted. Start from zero, not from the open internet minus a blocklist.
• Per-agent, per-tool allow-list. Enumerate the destinations each tool actually needs (api.openai.com, slack.com, a specific news provider) and nothing else. A scope wide enough to be convenient is wide enough to exfiltrate through.
• Domain filtering at an application-layer proxy. Squid, mitmproxy in transparent mode, or a cloud-provider equivalent enforces the allow-list above the packet level.
• DNS filtered at the resolver. An agent blocked at the proxy can still encode data into DNS lookups. Close that channel at the resolver, not only at the HTTP layer.
• Internal services over VPN only. Tailscale, WireGuard, or mTLS. Nothing the agent talks to should be reachable from the public internet.
• No SSH credentials between hosts. If the agent holds no keys, construction blocks lateral movement. You are not relying on a policy you have to trust.

Filesystem isolation

The filesystem is the second exfiltration and tampering surface. An agent reads what it should not, writes where it should not, or climbs out of its working directory with a relative path. Bound all three at the tool boundary, where you control the code, not in the prompt, where you control nothing.

• read_file and write_file accept paths only inside an explicit working directory. Resolve and validate the canonical path; do not pattern-match the raw string.
• Reject path traversal (..) at the tool, not by asking the model to behave.
• Mount system directories read-only. Mount source code read-only wherever the task allows.
• Exclude credential and config files from the agent's view entirely: ~/.ssh, ~/.aws, ~/.config/claude, ~/.npmrc, browser profile directories. The agent should not be able to read what it cannot name.
• Give each task an ephemeral filesystem (microvm or container) so an injection in one session leaves nothing behind for the next session.

Hooks as inline guardrails

Hooks run the harness's own code in the path of every tool call, before the action executes and after it returns. They are defense-in-depth: a second enforcement point that does not depend on the model. They sit in front of the Policy Enforcement Point, which still makes the hard authorization decision.

Process model

Shared state between agents turns one compromise into many. Keep the boundaries hard:

• One harness process per agent. No process shared between agents on a host.
• An ephemeral subprocess per task for code execution and shell, torn down when the task ends.
• No filesystem shared between agents.
• No shared credentials. Give each agent its own service account, so an attacker who turns one agent inherits that agent's authority and nothing past it.

Resource limits

Limits turn runaway behavior into a bounded, observable event. They cap the damage of a loop the model cannot escape, and the throughput of an exfiltration the egress controls failed to fully close.

• Loop-iteration cap and wall-clock limit per session.
• Per-tool rate limits per session.
• Token and monetary budgets per session, enforced by the harness.
• OS-level memory and disk quotas.
• An outbound byte ceiling per session. A sudden approach to the ceiling is a strong exfiltration signal.

Audit and observability

You cannot reconstruct an incident you never recorded, and you cannot trust a record the attacker could edit. Both halves matter.

• Log every tool call: identity, tool, redacted arguments, outcome, latency, cost.
• Write the audit log to a store outside the agent's reach. An agent with write access to its own log can rewrite history after the fact.
• Log conversation transcripts with provenance tags, so you can tell later which content was untrusted.
• Stream logs in real time. Batch upload leaves a window where a compromised agent can suppress its own evidence.
• Alert on outliers: a tool used for the first time, call volume past the 99th percentile, off-hours invocation, a new egress destination.
• Retain at least 90 days for general agents, longer for high-risk ones.
• Replay an old session into a sandbox now and then, and confirm the audit trail is enough to reconstruct it. An audit you have never tested is a guess.

Checklist