Constrain permissions, approvals, and tool outputs for agent systems.
Agent security starts by knowing what the agent can read, change, send, spend, or execute.
Agent security starts by knowing what the agent can read, change, send, spend, or execute.
Why this matters: Build a tool inventory with capability tiers.
Problem anchor: an agent can browse course pages, read local lesson files, update a CMS, email instructors, and run shell commands. A prompt-injected page tells it to publish a fake lesson. Without a capability inventory, the team cannot tell which action should have been impossible.
Inventory each tool by capability tier: read-only, private read, write draft, external send, money movement, code execution, admin, or credential access. Record data classes, side effects, idempotency, owner, approval requirement, sandbox, and audit fields.
Tool: publish_lesson. Tier: external write/public publish. Inputs: lesson_id, target_channel, version. Side effect: public content update. Required role: editor. Approval: human confirmation with diff preview. Credential: scoped CMS token, 5-minute TTL. Sandbox: no filesystem access. Audit: user, model, args, approval, result digest, policy version.
Secure agents call purpose-built APIs, not arbitrary shells, browsers, or email tools by default.
Secure agents call purpose-built APIs, not arbitrary shells, browsers, or email tools by default.
Why this matters: Design narrow tool schemas.
The model sees tool names and descriptions as text. That text can guide planning, but it is not an authorization boundary. The runner must validate arguments, check user permission, enforce business rules, and decide whether approval is required before execution.
Narrow tools reduce blast radius. create_lesson_draft(lesson_id) is safer than a general shell command. send_invoice_reminder(customer_id) is safer than arbitrary email with free-form recipient and body.
An agent times out after calling a payment-refund tool and retries because the model thinks nothing happened. The customer receives two refunds. Secure tool design marks non-idempotent tools, records request IDs, and forces confirmation or idempotency keys before retry.
| Option | Broad tool | Safer shape | Reason | When to choose | Cost | Complexity |
|---|---|---|---|---|---|---|
| Arbitrary email | recipient, subject, body free-form | approved template plus customer_id and preview approval | prevents injected recipients and hidden content | Use for external sends. | Medium | Medium |
| Shell command | any command in repo | named build, test, or validation command with fixed args | limits file and network impact | Use for developer agents. | Medium | Medium |
| Browser automation | click anything in logged-in session | domain allowlist, read-only scrape, no purchase or submit actions | reduces unintended external side effects | Use for web tasks. | Medium | Medium |
The model should never carry broad secrets; the tool runner should mint narrow authority after policy checks.
The model should never carry broad secrets; the tool runner should mint narrow authority after policy checks.
Why this matters: Explain scoped credentials and TTLs.
Decision this forces: Choose the right level of rigor for Securing Tool-Using Agents: baseline, production design, or advanced optimization.
An agent that sees a long-lived API key can leak it by mistake, through injection, through logs, or through a tool result. Instead, the server checks the user and tool policy, then mints a scoped token for the specific action with short lifetime and limited resources.
Sandboxing limits what happens if the model plan, dependency, page, or tool result is malicious. Useful dimensions include filesystem roots, process limits, network egress, timeouts, memory, package installation, browser profile, and environment variables.
Filesystem: repo working directory and temp only, no home secrets. Network: package registry and approved docs domains, no arbitrary POST. Process: test and build commands, 10-minute timeout, memory cap. Credentials: none by default; deployment token minted only after human approval. Browser: isolated profile without personal cookies. Audit: command, files touched, network destinations, exit code.
Approval gates turn risky model plans into reviewable human decisions before impact.
Approval gates turn risky model plans into reviewable human decisions before impact.
Why this matters: Write an approval policy check.
def authorize_tool(user, call): risky = call["external_send"] or call["irreversible"] or call.get("cost", 0) > 25 assert call["name"] in {"create_draft", "publish_lesson"} assert user["role"] in call["allowed_roles"] if risky: assert call.get("human_approval") == "confirmed" return {"token_scope": call["name"], "ttl_seconds": 300} call = { "name": "publish_lesson", "allowed_roles": ["editor"], "external_send": True, "irreversible": False, "human_approval": "confirmed", } print(authorize_tool({"role": "editor"}, call))
The runner should block or request approval before execution, regardless of how confident the model sounds.
Look for a real tool inventory, capability tiers, schemas, authorization, scoped credentials, sandbox dimensions, approval rules, audit logs, idempotency, egress policy, and tests for prompt injection through tool outputs. Weak plans say "the agent should be careful" without enforcement.
Tool security must update when tools, credentials, prompts, models, or connectors change.
Tool security must update when tools, credentials, prompts, models, or connectors change.
Why this matters: Recall the secure tool-use loop.
Decision this forces: Choose the right level of rigor for Securing Tool-Using Agents: baseline, production design, or advanced optimization.
Answer this from memory: "How do I secure a tool-using agent?" Include inventory, capability tiers, schemas, authorization, scoped credentials, sandboxing, approvals, idempotency, audit logs, injection tests, egress, and incident review.
Pick one agent tool. Write its capability tier, schema, allowed roles, credential scope, sandbox needs, approval rule, idempotency key, audit fields, and two attack tests: one direct user injection and one malicious tool-output injection.
From memory, reconstruct secure tool use: inventory capabilities, tier risk, expose narrow tools, validate schemas, authorize users, mint scoped credentials, sandbox execution, require approvals, audit results, and test injection paths.
Create a one-page release-ready plan for tool-security policy with least privilege, confirmation, and logging. Include: the user problem, realistic input, mechanism, design choice, runnable or reviewable check, metric (unsafe tool calls blocked before execution), failure case (prompt injection turns a read-only support session into a payment action), owner, and the next rung after this lesson.
Your agent has a tool that can only read customer records — no writes, no deletes. A teammate says it needs no security review because it's read-only. What is the strongest argument against that position?
Even without mutation, a read-only tool that exposes sensitive data is a high-value target — exfiltration via prompt injection or over-broad output is a real risk.
You are designing a tool that lets an agent send emails. Which schema design best follows the principle of narrow typed tools?
Narrow schemas constrain exactly what the agent can express, reducing the attack surface and making validation enforceable before the tool ever executes.
Explain how a prompt injection attack in a tool's output (not the user's input) can lead to a sandbox escape. Give a concrete one-sentence scenario.
Tool output injection works because the agent treats returned content as trusted context, so adversarial text in that output can hijack subsequent tool calls — exactly the vector sandbox rules must guard against.
An agent's approval policy is set to 'auto-approve all tool calls under 10 seconds of estimated runtime.' Which scenario does this policy fail to catch?
Approval policies must gate on impact (side effects, irreversibility) — not on runtime duration, which is unrelated to how destructive a tool call is.
You are choosing a rigor level for a new internal agent that automates HR report generation — it reads from a data warehouse and emails PDFs to managers. No external users. Which level is most appropriate, and why?
PII access plus an outbound side effect (email) crosses the threshold for production-design rigor: scoped read credentials, short-lived tokens, an approval gate on sends, and logging — even for internal tools.