# 13. Reliability, security & sandboxing > Letting an agent act in the world without letting it break things. Track: Production systems. 33 terms. 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. **Interactive figure on the web page: 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. ## 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. Web page: https://llm-atlas-7or.pages.dev/learn/security/ _Definitions written for LLM Atlas._