An instruction is not a permission boundary.
A document can tell an agent what it should do. Tools, credentials, and host controls determine what actions can actually succeed.
The files, tool names, identities, policies, and outcomes below are invented. No extension was installed, no credential was issued, and no denial was tested. A diagram cannot prove that a real host is contained.
“Never publish without approval” is a useful instruction. It is not equivalent to removing a publishing tool, withholding a credential, denying the service action, blocking the network path, or requiring approval at an enforcement point. Those controls answer different questions.
Follow a proposed action through five separate layers
- 1 · GuidanceWhat should the agent do?Instruction files, prompts, procedures
- 2 · Tool surfaceWhat callable operation exists?Read, write, shell, API tools
- 3 · IdentityWhat authority reaches the target?Tokens, service identity, ambient access
- 4 · Host boundaryWhat does the runtime permit?Filesystem, network, sandbox, policy gate
- 5 · EvidenceWhat happened?Denied call, approval, diff, service audit
One fictional task, four materially different setups
A synthetic repository contains release-notes.md. The task is “summarize the notes into draft-summary.md; do not publish.” The instruction is identical in every row. Only the available capability chain changes.
| Setup | What is present | Defensible conclusion before a run |
|---|---|---|
| Document only | Instruction text; no tools exposed | The text provides guidance. This host surface exposes no action through the described interface. Check for other interfaces before saying the process is contained. |
| Local draft tool | Scoped read plus write to a draft directory | The described tools can read the source and write a draft. They do not, by themselves, establish a publishing path. |
| Publish tool, no verified identity | A tool named publish_page; credential state unknown | The action is callable, but success is unknown. Do not infer denial: the tool may hold an ambient service identity outside the model’s context. |
| Publish path with a hard gate | Tool and identity; service policy requires a separate reviewer approval | The design includes an enforcement point. Claim the denial only after a safe negative test and service-side evidence show the unapproved request was rejected. |
The key distinction is between selection and authorization. An instruction may help the model select a safer action. A tool definition makes an operation selectable. A credential or workload identity may authorize the target service. A host or service policy can deny the request regardless of the model’s choice.
Ask these questions in order
- Was the instruction loaded? Inspect the host’s context or configuration view; the file existing on disk is not enough.
- Which tools are actually exposed? Record names, schemas, executable hooks, and alternate paths such as shell or browser control.
- Where does authority come from? Look for user login, service identity, delegated token, environment injection, or credentials held inside a remote tool. Never print the secret to prove it exists.
- Where is denial enforced? Name the filesystem, network, sandbox, permission callback, server authorization, or reviewer gate that makes the prohibited action fail.
- What evidence would demonstrate the boundary? Prefer a synthetic denied request, exit status, approval record, and target-side audit event over a model statement that it “cannot” act.
Hard controls still need careful claims
- A deny rule can be mis-scoped, shadowed, disabled, or applied only to one tool path.
- A sandbox limits the process it contains; it does not automatically constrain remote tools acting elsewhere.
- Withholding a token from model context is good secret hygiene, but a tool may still use that token on the model’s behalf.
- A tool’s “read-only” or “non-destructive” annotation is descriptive metadata, not proof of behavior.
- An approval prompt is a checkpoint, not evidence that the reviewer understood every downstream effect.
- A successful negative test supports only the tested action, identity, policy version, and environment.
What the primary documentation establishes
Instruction context is not enforced configuration
Claude Code’s memory documentation says instruction files and auto memory are loaded as context, not enforced configuration, and points to a pre-tool hook when an action must be blocked regardless of the model’s decision.
Permission rules decide tool calls, not tool existence
Claude Code’s permissions documentation distinguishes deny, ask, and allow decisions and explains that an allow list pre-approves matching tools rather than removing every unlisted tool. This is one product’s documented evaluation model, not a universal agent standard.
Tools expose actions; annotations remain hints
The MCP tools specification defines tools as server-exposed functions and warns that tool annotations should be treated as untrusted unless they come from a trusted server. The MCP maintainers’ tool-annotation guidance makes the boundary explicit: hints are not enforcement; guarantees belong in authorization, transport, runtime, sandbox, or network controls.
Primary documentation checked. These sources describe their own systems. The five-layer trace, synthetic task, table, and conclusions are original synthesis; no local configuration or security result is represented.
Companion guide: inspect an agent extension before installation →