Topic 13 · Production systems
Reliability, security & sandboxing
Letting an agent act in the world without letting it break things.
An agent that runs code, browses the web or calls APIs is executing instructions that came from a model, and models can be wrong or manipulated by the content they read. The defence is layers: isolate where code runs, check every action against policy in code the model cannot talk its way past, and require a person for anything irreversible.
Reliability is the same mindset applied to failure. Tools time out, networks drop, processes crash. Retries need idempotency, timeouts need cancellation, and anything with an external side effect needs to be safe to replay.
In this topic
33
terms, each defined below
Defence in layers
A tool call travels from the model toward the host and must pass each boundary in turn. Pick an action to see where it is stopped: safe reads go through, risky actions wait for human approval, and anything the policy does not recognise is denied, because the gateway fails closed.
- Model
- Policy gateway
- Human approval
- Sandbox boundary
- Workspace
email.send({ to: "…" })Approved by a person. External side effect: paused until a person approves, then logged.
Audit log
- Pick an action above. Every attempt is recorded, allowed or not.
Glossary
33 terms
Tool isolation
Running each tool so that a failure or compromise cannot affect the agent runtime, other tools or other users.
Execution sandbox
A restricted environment where agent-generated code and commands run, with limited filesystem, network and system access.
Sandboxed execution
Running untrusted code inside a sandbox. It should be the default for any code an LLM writes.
Docker containers
Lightweight isolated environments that share the host's kernel. Convenient for packaging tools, but the shared kernel makes them a weaker wall against hostile code.
MicroVMs
Minimal virtual machines, such as Firecracker, that boot in milliseconds and give each sandbox its own kernel, a stronger boundary than containers.
Process isolation
Separating work into OS processes with their own memory and privileges, so one crash or exploit stays contained.
Workspace isolation
Giving each agent session its own working directory or volume so tasks cannot read or damage each other's files.
Filesystem boundaries
Limits on which paths an agent can read or write, enforced with mounts, permissions or path checks.
Browser isolation
Running agent web browsing in a separate, disposable browser so pages cannot reach the user's real sessions or the host machine.
Security policies
Rules that define what agents may do: allowed tools, domains and data, and which actions need approval.
Capability security
Granting access by handing out specific, unforgeable capabilities, such as a token for one folder, instead of relying on broad ambient identity.
Authorization
Deciding whether an authenticated identity may perform a given action on a given resource.
Authentication
Verifying who or what is making a request, for users and for agents alike.
Permission enforcement
Checking permissions at the moment of action, in code the model cannot bypass, not just in the prompt.
Policy gateway
A central checkpoint that every tool call passes through to be judged against policy before it runs.
Fail-closed security
When a check cannot be completed, because of an error, a timeout or an unknown action, deny by default instead of allowing.
Audit logging
Recording who did what, when and with which inputs, especially for actions with side effects.
Audit trails
The tamper-evident sequence of audit records that lets an incident be reconstructed afterwards.
Human approval
Requiring a person to confirm sensitive actions, such as payments, deletions or outgoing messages, before they run.
Human-in-the-loop
Designs where people review, correct or approve agent work at key points instead of granting full autonomy.
Secrets management
Storing and injecting API keys and credentials securely, through vaults and short-lived tokens, so they never end up in prompts or logs.
Credential encryption
Encrypting stored credentials at rest and in transit, with tightly controlled keys.
Error handling
Catching, classifying and responding to failures: deciding whether to retry, tell the model, or abort.
Retries
Repeating a failed operation with exponential backoff and jitter, only for transient failures and idempotent operations.
Retry amplification
When retries at several layers multiply (three layers of three retries is 27 attempts) and turn a small outage into a self-inflicted overload.
Timeouts
Upper limits on how long an operation may run before it is abandoned, applied to model calls, tools and whole runs.
Cancellation
Stopping in-flight work cleanly when a user or parent task cancels, and passing that on to sub-tasks and tool processes.
Crash recovery
Restoring service and in-progress work after a process or node crash, usually from checkpoints and durable logs.
Failure handling
The overall plan for failures: detect, contain, retry, compensate, escalate.
Replay safety
Making sure that re-running steps during recovery does not repeat side effects, using idempotency keys and recorded results.
External side effects
Effects outside your own system, such as sending email, charging a card or writing to a third-party API, that cannot simply be rolled back.
Rate limiting
Restricting how many requests or tokens a client may use per time window, protecting capacity and budgets.
Resource limits
Caps on CPU, memory, disk, processes, network and run time for sandboxes and agents.