Sandboxed Tool Use: Letting Agents Act Without Letting Them Loose

Agents become dangerous the moment they can change something outside the chat. Email. CRM rows. Tickets. Code. Money. Sandboxed tool use is how you keep the upside of action without handing production the keys on day one.

This spoke belongs to the Agentic Systems Operating Manual. Pair it with evaluators: judgement without cages still lets bad actions through between grades; cages without judgement still ship confident nonsense.

What “sandbox” means here

A sandbox is not a marketing word for “we thought about security.” It is a concrete boundary:

• The agent may call only an allowlisted set of tools.
• Each tool runs with the least privilege that still does the job.
• Quantitative caps limit how much damage a confused loop can do.
• Irreversible actions start behind human approval.
• Staging and production are not the same credential set.

MCP servers, custom HTTP tools, and in-process functions are all fine — if they sit behind that boundary. Unrestricted shell, wildcard admin tokens, and “the model can invent new tools” are how incidents start.

Safe tool use for agents: the checklist

1. Allowlist before descriptions

Publish a typed catalog: name, purpose, input schema, output schema, side-effect class (read, write, irreversible). The model chooses among catalog entries. It does not get a blank “run whatever.”

If a job needs a new tool, a human adds it to the catalog with a review. Hot-adding tools mid-run because the model asked nicely is not a feature.

2. Scope credentials per tool

Read-only CRM token for enrichment. Separate write token for the one field the agent may update. Never reuse the founder’s personal OAuth for a fleet. Rotate. Log which identity performed the write.

3. Cap blast radius

Examples that belong in config, not vibes:

• Max rows touched per run
• Max emails sent per day (ideally zero until autonomy is earned — drafts only)
• Max dollars for any spend API
• Max files deleted: zero; deletes are human-only unless you have a bizarrely strong case
• Timeouts and concurrency limits so a retry storm cannot amplify itself

4. Dry-run and dual-write patterns

First week in a new system: tools return “would write X” without writing. Compare to what a human would have done. Then dual-write to a shadow field. Then cut over with caps.

5. Human gates on irreversible classes

Refunds, public sends, production schema changes, legal-sounding commitments — gate them. The agent prepares the payload; a human (or a stricter secondary policy engine) releases it. Autonomy is a promotion, not a default.

6. Fail closed

If auth fails, schema fails, or the sandbox rejects a call, the run goes to escalate or abort — not to “invent a workaround with another tool.” Clever workarounds are how sandboxes die.

Side-effect classes (use them in design reviews)

Class	Examples	Default policy
Read	Fetch ticket, search docs	Allow under rate caps
Soft write	Draft in internal field	Allow after evaluator pass
Hard write	Update customer-visible record	Cap + monitor; often gated early
Irreversible	Send email, charge card, delete	Human gate until proven
Ambient	Logging, metrics	Always on, redacted

Argue about classification early. Most arguments about “trust” are really arguments about which class a tool is in.

Prompt injection and tool use

Any content the agent reads — tickets, emails, PDFs, web pages — can contain instructions. Treat untrusted text as data, not as system policy. Practical controls:

• Tool allowlists that cannot grow from retrieved text
• Separating “instructions” channels from “document” channels in the prompt
• Stripping or ignoring attempts to request new tools or secrets
• Never echoing secrets into traces or model context

Sandboxing does not solve injection alone, but without a sandbox injection has a bigger blast radius.

What to log for every tool call

For ops and forensics you want: tool name, redacted args, redacted result or error, duration, side-effect class, run id, state name, cost attribution. You do not want full PII in a Slack channel. Redaction is part of the sandbox design, not an afterthought.

Anti-patterns

“The agent has the Zapier key.” That is not a platform. That is a skeleton key.

Production credentials in the prompt. Secrets belong in a secret store injected at the tool runner, invisible to the model.

Sandbox theater. A YAML file named permissions that nothing enforces.

Expanding scope mid-pilot. Pilots are one job. New tools wait for the next engagement slice.

How Spurlock Studios applies this in a pilot

In the $1,500 · 5-day pilot we pick the minimum tool set for one sentence-sized job. Reads first. Writes only if the job demands them, usually to an internal surface. Irreversible actions stay human-gated. You leave with a catalog and a runner you can keep operating.

Map and offer: /agentic. Book: /contact?intent=agentic-pilot.

Sandbox + evaluator + state machine

Think of three locks:

1. State machine — only act may call tools with side effects.
2. Sandbox — only allowlisted tools with caps.
3. Evaluator — only passing artifacts proceed to hard writes.

Remove any lock and the system fails open in a different way. The parent operating manual shows how they sit together.

A short example

Job: enrich a lead record with firmographics and draft an internal note.

Allowlist: crm.get_lead, enrichment.lookup, crm.patch_internal_note.

Not allowlist: crm.merge_leads, email.send, crm.delete.

Caps: one lead per run; enrichment API max 3 calls; patch only internal_note field.

Evaluator: note must cite enrichment fields present in the tool result; no invented revenue numbers when enrichment returned null.

That is sandboxed tool use. “Here’s our admin API key, go enrich everything” is not.

Designing the tool runner

The runner is the enforcement point. It should:

1. Authenticate the run (tenant, job type, state name).
2. Reject unknown tool names.
3. Validate args against JSON Schema before any network call.
4. Inject secrets from a vault — never from model output.
5. Apply rate limits and blast-radius counters.
6. Execute with timeouts.
7. Normalize errors into typed failures the state machine understands.
8. Emit redacted trace spans.

If validation and policy live only in the prompt (“please do not call delete”), you do not have a runner. You have hope.

Idempotency belongs here too. For hard writes, accept a client-generated idempotency key from the state machine and persist outcomes so retries do not double-apply.

Environment separation

Environment	Credentials	Writes	Audience
Dev	Mock / fixtures	Fake	Engineers
Staging	Staging systems	Real staging data	Domain reviewers
Prod	Least privilege prod	Caps + gates	Customers / ops

Promoting a tool from staging to prod is a change-controlled event: review side-effect class, caps, and whether the evaluator covers the new failure modes. Copy-pasting the prod token into a notebook “just to test” is how sandboxes end.

Third-party MCP and plugin risk

Marketplace tools arrive with someone else’s threat model. Before allowing an MCP server into an agent catalog:

• Read the scopes it requests
• Run it against a throwaway tenant
• Confirm it cannot exfiltrate via “helpful” logging
• Pin versions
• Disable tool list mutations at runtime

Spurlock Studios would rather wrap two HTTP endpoints you own than enable twenty plugins you have not read. The operating manual treats sandboxes as a first-class layer for that reason.

Progressive autonomy ladder

1. Dry-run only
2. Soft writes to internal fields
3. Hard writes with human gate
4. Hard writes auto under caps
5. Irreversible actions still gated (often forever)

Climb the ladder per job type using online evaluator scores and incident count — not calendar time. A quiet week is not the same as a measured week.

When you are ready to prove one job inside a cage in five days, the $1,500 pilot on /agentic is the on-ramp; book via /contact?intent=agentic-pilot.

Argument validation patterns

Beyond JSON Schema, add domain validators: email fields must match allowlisted domains for outbound drafts; SQL tools (if you ever allow them) must be parsed and rejected on DROP/UPDATE/DELETE; URL fetchers must block link-local and private IP ranges to prevent SSRF.

Return errors the model can act on without revealing secrets: policy_violation:recipient_domain rather than stack traces with vault paths.

Dual control for high-risk tools

For refunds, production DNS, or payroll-adjacent actions, require two approvals: the agent’s prepared payload plus a human, or two humans. Dual control is older than LLMs; agents do not exempt you.

Inventory review monthly

List every tool in every agent catalog: owner, last used, side-effect class, credential age. Disable orphans. Orphan tools with live credentials are unpaid attackers waiting for a prompt injection.

Continue with state machines and the manual. Pilot path: /agentic.

Secret handling checklist

• Secrets in a vault or encrypted env store, not in prompts, git, or traces
• Short-lived tokens where the provider allows
• Separate identities per environment and per high-risk tool
• Rotation calendar with an owner
• Break-glass prod access logged and time-bounded

Agents increase the number of places secrets can leak (prompts, traces, tool args). Design as if every span will one day be exported.

Network egress policy

If tools can fetch URLs, constrain egress: allowlisted hosts, block metadata IPs, size limits on responses, content-type checks. “Read the webpage” is a powerful tool and a common exfiltration path under injection.

What “safe tool use for agents” means in a procurement RFP

Ask vendors to demonstrate a rejected tool call, a capped blast-radius stop, a dry-run mode, and a human gate. If they can only show a happy-path demo, keep shopping. Spurlock Studios builds these controls into the $1,500 pilot so you see rejection paths on your own systems — /agentic.

FAQ

What are sandboxed AI tools?

Sandboxed AI tools are agent-callable functions wrapped in allowlists, least-privilege credentials, quantitative caps, and policies for irreversible actions. The model proposes a call; the runner enforces whether that call is legal.

How do you implement safe tool use for agents?

Define a typed tool catalog, classify side effects, scope credentials per tool, enforce caps and timeouts in the runner, start irreversible actions behind human gates, fail closed on errors, and log redacted traces. Promote autonomy only after evaluation scores hold.

Is MCP enough to be “sandboxed”?

MCP is a transport and interface pattern. It does not automatically enforce least privilege or blast-radius caps. You still design the server’s capabilities, auth, and policy. A wide-open MCP server is not a sandbox.

Should agents have shell access?

Almost never in business pilots. If you need shell for a devtools agent, isolate the environment, drop privileges, network-restrict, and treat every command as high risk. Default to purpose-built tools with schemas.

When can we remove human gates?

When offline and online evaluator scores meet the bar, blast-radius caps are proven under load, and the business accepts the residual risk in writing. Gates are a control, not an insult to the model.

How does this relate to Spurlock Studios’ agentic offer?

Sandbox design is part of every pilot and build. We would rather ship a narrow, caged agent that works than a broad agent that can email your customers by accident. Start at /agentic or /contact?intent=agentic-pilot.