Overview › Lever
Guardrails
Sandboxes, permissions, approval policies, data containment. 5 optimizations change this part of an agent.
- 6.c.i
Code-then-execute (CaMeL)
Have a privileged model turn the trusted request into a small program before any untrusted data is read, then run it in an interpreter that labels every value with where it came from and checks a per-tool policy before each call, so injected text can neither add actions nor send private data to the wrong place.
- 6.c.ii
Plan-then-execute
Have the agent fix its tool calls (an ordered list or a dependency graph) from the trusted request before it reads any tool output, and let a controller execute only those calls, so injected text cannot add an action.
- 10.a.i
Constrain what the agent can touch
Run the agent in an OS-level sandbox with a workspace path guard that resolves symlinks, scrub credentials from the command environment, run agent-written SQL read-only with timeouts and row caps, and set resource limits on generated code.
- 10.b.i
Gate irreversible actions: allow, ask or deny by side effect
Classify every action the agent can take by its side effect (read, reversible write, irreversible or externally visible: sending email, issuing a refund, deleting a record, posting publicly, pushing code) and gate by class: allow, ask a human or a policy, or deny.
- 10.c.i
Contain sensitive data and untrusted input
Tokenize PII in the client so it never reaches the model, wrap untrusted tool and web results in taint delimiters, scan context files and skills for prompt injection, and state an explicit instruction-precedence order (user, repo, defaults, external data as data).