Scoping what it is allowed to do
Scoping what an agent is allowed to do is the practice of defining its permitted resources, actions, environments, users, and approval boundaries, then enforcing those limits in application code. The model may plan or request actions, but deterministic policy checks decide what actually executes.
Agents become risky when they can affect external systems: read databases, run commands, send messages, change tickets, or spend money. Without a clear remit, every new tool expands the blast radius. The boundary must say what the agent may do, what it must refuse, when it should ask for clarification, and when a human must approve. Treating this as a prompt instruction is not enough, because the model is not the enforcement layer.
A useful way to picture it is a service account behind a policy gate. The model emits an intended action, such as querying a table or creating a ticket. Before the tool runs, code checks the request against allowlists, deny rules, typed schemas, user permissions, environment restrictions, spending limits, and approval requirements. If the action fails policy, the tool is not called. The agent can explain, ask, or escalate, but it cannot bypass the gate.
The trade-off is less flexibility. A tightly scoped agent may refuse work that looks harmless, need extra approval steps, or require more engineering around policies, tests, audit logs, and fallbacks. The honest answer is that the right scope depends on the damage a bad action could cause, how trusted the user is, and whether the environment is read-only, staging, or production. Safer defaults usually mean more explicit permission design.
Engineers meet this when shipping an agent with tool access, especially through MCP servers, internal APIs, shell commands, issue trackers, email systems, or deployment workflows. The practical task is to list each capability, decide who and what it may affect, and wrap every external action in a check. Commonly misunderstood: the prompt can describe the remit, but only code can enforce it.
Common questions
- Why not just tell the model not to do dangerous things?
- A prompt is context, not a security boundary. It can be ambiguous, contradicted by retrieved content, weakened by long conversations, or misapplied by the model. Use the prompt to explain expected behaviour, but make the real decision in code before any tool touches files, databases, networks, payments, or production systems.
- What should be included in an agent remit?
- Include the resources it may read, the actions it may take, the environments it may affect, the users it may act for, and the decisions that require approval. Also define refusal and escalation behaviour. The remit should be precise enough that an engineer can translate each line into permissions, tests, and runtime checks.
- How do you know whether a scope is too broad?
- Ask what happens if the model misunderstands, is tricked by input, or chooses the wrong tool. If the result could modify production, leak sensitive data, impersonate a user, or trigger an irreversible action without another control, the scope is probably too broad. Start read-only where possible, then add narrow write capabilities deliberately.