How do you scope a deploy agent's tools so a hijacked run stays contained?

## The threat you are scoping against A tool-using agent reads untrusted content — tickets, logs, web pages, emails, tool results — and any of it may contain instructions. You cannot reliably prevent the model from being persuaded; adaptive-attack research through 2025 and 2026 repeatedly bypassed defenses built on detection. So the design question is not "how do I stop the agent choosing a bad call?" but "what is the worst call it is able to make, and how bad is that?" Scoping is how you shrink that worst case. It is a deterministic wall — enforced by code and IAM, not by persuasion — which is what makes it hold when the probabilistic layers miss. ## Move one: granularity beats generality A generic tool grants the union of everything reachable through it. `run_shell(command)` grants every binary on the image plus every credential the process can read. `run_sql(query)` grants the full rights of the database user, including `DROP` and cross-tenant reads. `http_request(url, method, body)` grants your entire internal network. Capability-shaped tools invert this: `scale_deployment(name, replicas)`, `read_recent_logs(service, minutes)`, `open_incident(title, severity)`. Each one names an operation, not a mechanism. The cost is that you write more tools and lose some flexibility — an agent with a shell can improvise. That flexibility is exactly the thing an attacker inherits, which is why generic executors belong only inside a sandbox with nothing valuable in it. ## Move two: bind the dangerous parameters server-side Even a narrow tool is unsafe if the model supplies the scoping arguments. If `scale_deployment` takes a `namespace` parameter, the model can be pointed at `payments-prod`. If the tool implementation hard-codes `checkout-prod` and accepts only the deployment name and replica count, that whole class of redirection disappears. The rule: the model chooses *what to do within a scope*; the scope itself is a property of the tool, not an argument to it. Then validate what remains — the name against an allowed set, the replica count against a range — and reject rather than clamp, so a suspicious call is visible in logs instead of silently normalised. ## Move three: enforce where the call lands Everything on the model side is advisory. A tool description that says "read-only, never use for writes" is prompt text; a JSON Schema `enum` is validated by your wrapper, which is code you control, but it is still one layer. The authoritative wall is the resource server: the agent's own role simply does not include `iam:*`, `billing:*`, or write access to other namespaces. Then a bug in your wrapper, a second call path, or a tool the model reaches some other way all terminate in a deny at the API rather than in a successful destructive call. This is why scoping and identity are the same conversation. A narrow tool over a broad role is one code review away from disaster; a broad tool over a narrow role is bounded but noisy. You want both narrow. ## Move four: split by risk and by trust domain Separate read tools from write tools so that the common case — investigation — needs no write capability at all. Where a workflow genuinely needs both, consider two agents: a diagnosis agent that reads everything and produces a recommendation, and an execution agent that can write but never reads untrusted content. That split removes the combination that makes hijacking profitable, at the cost of an extra handoff. Similarly, do not build one super-agent holding every team's tools because it is convenient. The blast radius of an agent is the union of its tools; merging two agents multiplies the risk of both. ## Operational limits Quotas and rate limits on the tools themselves bound the *rate* of damage: an agent permitted to scale deployments five times an hour cannot flap production two hundred times. Cost caps do the same for spend-shaped tools. These are cheap, they never depend on model behaviour, and they buy time for a human to notice. ## What scoping does not do It does not stop the agent doing a legitimate-looking wrong thing inside its scope — scaling the right service to the wrong number, closing the wrong ticket. That is what approval gates on irreversible actions and good evaluation are for. Scoping's job is to make the ceiling low, not the floor perfect. ## Answering this well Start from "assume it will be hijacked", then walk granularity, server-bound parameters, and enforcement at the resource server, with one concrete deny you would put in the role. Interviewers are listening for whether you put the boundary in the prompt or in the infrastructure.