Capability-Scoped Tool Invocation¶
Invocation protocol — instantiates Data-Control Boundary Inertization
Binds each tool or action call to a narrowly scoped capability granted for that purpose, so untrusted content processed by a deputy can never summon authority the deputy was not explicitly handed.
The danger is not that a deputy — a workflow, a service, an AI agent — malfunctions, but that it acts on untrusted content with its own authority. Capability-Scoped Tool Invocation cuts that link by making every privileged action require a capability scoped to exactly that action, granted deliberately rather than ambient. Its defining move is that authority travels with the call, not with the caller: reading an untrusted document gives the deputy a read-scoped capability and nothing more, so even if the content tries to steer the deputy toward a consequential action, there is no capability in hand to carry it, and the conversion from "the content asked for this" to "the system did this" is an explicit, gated, recorded step. It answers the confused-deputy problem at the point of invocation.
Example¶
An email assistant can read a user's inbox and also send mail, touch billing records, and delete threads. A message arrives whose body is written to instruct the assistant — to forward the inbox elsewhere and then delete the trace. Under capability scoping, the context that reads and summarizes mail holds only a read capability; sending and deleting are separate capabilities that are simply not present in that context. For the assistant to send, the request must cross an authority gate — a scoped grant, often gated on the actual user's confirmation — and that crossing is logged as a distinct handoff. The injected instruction can influence what the assistant says, but it cannot mint the authority to act, because authority was never ambient in the reading context.
How it works¶
- Scope authority to the call. Each action requires a capability minted for that specific operation and target, rather than inheriting the deputy's full standing privileges.
- Gate the data-to-action conversion. Turning content-derived intent into a privileged call passes an explicit authority gate — a scoped grant, a policy check, or a human confirmation — never an implicit one.
- Record the handoff. Every conversion from content to action is a distinct, attributable event, so it can be reviewed and, if wrong, traced.
Tuning parameters¶
- Capability granularity — one broad "act on the user's behalf" grant versus per-operation, per-resource capabilities. Finer scoping contains more but multiplies the grants to manage.
- Grant lifetime — long-lived tokens versus one-shot capabilities that expire at the call. Short lifetimes shrink the blast radius; they add re-grant friction.
- Gate placement — which actions cross a human-confirmation gate versus an automated policy gate. More human gates are safer for high-consequence actions and slower for everything.
- Default posture — deny-by-default (no capability unless granted) versus allow-with-exceptions. Deny-by-default is the safe stance for a deputy exposed to untrusted content.
When it helps, and when it misleads¶
Its strength is that it targets the structural vulnerability — a deputy acting with borrowed authority on attacker-influenced input — rather than trying to detect the malicious input itself, which is exactly the confused-deputy failure that content inspection keeps missing.[n1] Its limits: capability scoping constrains what can be done, not whether the deputy was fooled into a permitted-but-unwanted action, so an over-broad capability quietly reintroduces the risk; and grant sprawl — capabilities that accrete and never expire — erodes the whole guarantee. The classic misuse is granting a wide capability "for now" to unblock a workflow and never narrowing it. The discipline is least authority per call, deny-by-default, and short capability lifetimes, so the gate stays meaningful.
How it implements the components¶
authority_context_gate— the invocation is the gate: it is where a content-derived request is either granted a scoped authority or refused, and nothing becomes action without crossing it.explicit_handoff_record— each conversion of intent into a privileged call is a distinct, attributable handoff rather than an invisible side effect.
It does not reduce the ambient privileges of the surrounding process or sandbox — that is Least-Privilege Execution Context — nor validate or encode the untrusted content itself (Allowlisted Parser or Schema Validator, Contextual Output Encoding).
Related¶
- Instantiates: Data-Control Boundary Inertization — it is the boundary at which content-derived intent must earn explicit, scoped authority before becoming action.
- Sibling mechanisms: Least-Privilege Execution Context · Content Security Policy or Execution Policy · Contextual Output Encoding · Allowlisted Parser or Schema Validator · Injection Payload Regression Tests · Parameterized Interpreter Call · Structured Command Construction · Template or Markup Sandbox · Taint Tracking or Provenance Labeling · Rejection or Quarantine Queue
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Binds each tool or action call to a narrowly scoped capability granted for that purpose, so untrusted content processed by a deputy can never summon authority the deputy was not explicitly handed, making its operative form a live operational control that automatically routes, enforces, adapts, or responds during execution.
Independent corroboration: The frozen evidence defines Capability-Scoped Tool Invocation as 'Binds each tool or action call to a narrowly scoped capability granted for that purpose, so untrusted content processed by a deputy can never summon authority the deputy was not explicitly handed', so its operative form is Control, Automation & Runtime.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Security Studies & Intelligence Analysis
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Capability security established the pattern of conveying the exact authority needed for an operation with the invocation, preventing a service from accidentally applying unrelated ambient authority.
Related originating lineages:
- Computer Science & Software Engineering — Capability-oriented operating systems and languages implement unforgeable, attenuable authority passed with a call.
Review resolution: Both reviewers selected security. Hardy's confused-deputy account directly explains why an invocation must distinguish the invoker's authority from a tool's ambient authority, while formal capability research treats delegated capabilities as the enforcement mechanism.
Attribution caveat: Object-capability design is also a computer-systems lineage; security is primary because least authority and confused-deputy prevention are the mechanism's defining purpose.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] The confused deputy is a program tricked into misusing its own authority on behalf of another party; capability-based security answers it by binding authority to specific, granted capabilities rather than to the deputy's ambient identity — the principle of least authority. Scoping the invocation is the direct application of that idea. ↩