# Plugins Are Capability Grants, Not Modules: Ambient Authority Is Why A Prompt Injection Works, And You Can Instrument Before You Enforce **version** v0.33.56 **date** 6 August 2026 **from** Human (project lead) **to** Engineering, Architecture, AppSec **type** Architecture brief *Eleventh of 6 August. Completes an authorisation story begun in the two previous briefs. Security literature is grounded and cited. Offered to be built on and challenged.* --- ## What This Is A plan for modular vault capabilities, which turns out to be a security architecture rather than a code-organisation exercise: **the memo asks why every vault should hold the inference capability and, more pointedly, why every vault should be able to read and write at all, and that question is the ambient authority critique, which is the foundation of the object-capability discipline in which a program holds only the authorities explicitly granted to it and a capability is an unforgeable reference to a resource together with the permissions over it; the consequence of naming it that way is a design instruction, because plugins organised by code you would like to keep separate produce modules while plugins organised by authority a vault may or may not hold produce a security boundary, so the inference plugin is not the inference code but the authority to spend on inference, and the storage plugin is not file helpers but the authority to reach particular paths; naming it also closes a loop across the last three briefs, since published analysis states plainly that ambient authority is the root cause of prompt injection because an attacker need not break anything and need only ask the confused deputy to use the authority it already holds, which means the state machine addresses the problem from the direction of sequence and this addresses it from the direction of capability and neither is sufficient alone; there is an off-the-shelf expression of exactly this discipline in the component model the corpus already ships in other contexts, where a component begins with no filesystem, no network, no clock and no host visibility, every capability must be declared as a typed import, the host performs the grant, and a directory handle confers access to that subtree rather than to a filesystem, which is described as matching least authority better than either operating system permissions or container capabilities because both of those grant categories rather than resources; and the migration problem the memo rightly identifies as the hard part has a clean answer, because implicit registration on first call is a fine transitional step and a poor destination, so the sequence is to grant implicitly and record every grant, read the resulting data to learn which vault actually uses what, then require declaration with a warning, then require it outright, which turns a migration that would otherwise be guessed into one that is measured.** It is the eleventh document of 6 August (cross-ref: the v0.33.56 kernel state machine brief, the v0.33.56 engine-outside-the-vault brief, the v0.33.56 vault-architecture brief, the v0.33.55 vaults-as-substrate brief, and the v0.33.52 outbound maturity model). New contributions: **plugins reframed as capability grants rather than modules, ambient authority identified as the shared root cause linking this to the injection work, the reference-is-the-permission design rule, the component model named as an existing implementation, and instrument-before-enforcing as the migration answer.** ## The Question That Reframes The Whole Thing The memo asks two questions and the second is the important one. The project lead: **"why should every single vault have access to the LLM capability, and why should every single vault actually have the ability to read and write from the vault?"** The first is about scope creep. The second is a challenge to something almost every system treats as given: that a component running inside a store can obviously reach the store. That is **ambient authority**, and it has a name because it is a known problem. Ambient authority means privileges a process uses automatically by virtue of where it is running, rather than because it was handed anything. The alternative is a **capability**, defined as an unforgeable reference to a resource together with the permissions over it, under a discipline that restricts programs to the authorities they receive explicitly. So the memo's instinct is the principle of least authority, arrived at from the practical direction of a codebase getting too large. ## Which Changes What A Plugin Should Be The design consequence is immediate and worth stating before any code is written. **Organised by code, you get modules. Organised by authority, you get a security boundary.** | Wrong axis | Right axis | |---|---| | The inference plugin is the inference code | The inference plugin is the authority to spend on inference | | The storage plugin is file helpers | The storage plugin is the authority to reach these paths | | The network plugin is HTTP wrappers | The network plugin is the authority to reach these hosts | The difference shows up the first time somebody wants to refactor. Under the first framing, moving a helper between plugins is housekeeping. Under the second, it changes what a vault can do, which means it is a decision rather than a tidy-up. A corollary worth adopting as a rule: **the reference is the permission.** A plugin that holds no reference to a resource cannot reach it, which means the interface should pass handles rather than names. A storage capability granted as a directory handle confers access to that subtree; a storage capability granted as a path string confers whatever the receiver can construct. The literature makes this precise: a handle grants the subtree, not the filesystem, and this matches least authority better than either operating-system permissions or container capabilities, both of which grant broad categories rather than specific resources. That is also the original confused-deputy failure restated: the compiler could write to the file the caller named because it conflated the authority to act with the designation of what to act upon. ## This Is The Same Problem As The Last Two Briefs The connection is worth making explicitly, because it turns three separate pieces of work into one argument. Analysis of agent sandboxing puts it directly: the root cause is ambient authority, because applications inherit the background permissions of their execution environment, and **with a prompt injection an attacker does not need to break anything, they only need to ask the confused deputy to use the authority it already holds.** The same literature observes that every agent acting on behalf of a chain of delegators is a potential confused deputy. So the three briefs of the last two days address one problem from two directions: ``` THE PROBLEM an action that is individually permitted but was never intended SEQUENCE the state machine in the kernel -> is this the next legal step? catches: injected, reordered, extra steps misses: a legal step carrying bad content CAPABILITY plugins as explicit grants -> may this component touch this at all? catches: authority it should never have had misses: misuse of authority it legitimately holds TOGETHER an action must be both permitted and expected ``` Neither is sufficient. A vault with no inference capability cannot be induced to spend on inference however cleverly it is prompted, and a vault that legitimately holds that capability can still be induced to spend it on the wrong thing, which is where sequence constrains it. **The combination is the authorisation model**, and it is worth writing down as one thing rather than three. ## There Is An Existing Implementation Of Exactly This Worth knowing before designing an isolation mechanism, particularly since the corpus already ships this technology in other contexts. A component in the WebAssembly component model **begins with no filesystem, no network, no system calls, no environment variables and no visibility into the host.** Every capability it holds must be declared as a typed import in its interface, and the host performs the grant. Each component has its own memory, and data crossing a boundary passes through a defined serialisation layer with no shared mutable state except what is explicitly threaded through typed interfaces. Commentary describes this as the object-capability model expressed as a runtime, in which the reference is the permission and a component holding no reference can reach no resource, and notes that grants can be virtualised rather than handed over wholesale. Guidance published in 2026 recommends it specifically for agent tool execution on the grounds that a deny-by-default capability model matches how agents should interact with the world. The corpus already uses this technology for browser query engines, established on 28 July. Whether it is the right isolation mechanism for vault plugins is a question worth asking rather than assuming, and the point is that the semantics have been designed and the interface discipline is documented. **The typed-import model is the thing to copy even if the runtime is not.** ## The Client And Server Split, With One Correction The memo proposes the shape. The project lead: **"it's sort of like this client-server architecture, where the client is the code that runs inside the vault app, and the server is the code that runs in the vault kernel."** That is right, with one boundary that must not blur: **a plugin must not adjudicate its own authority.** If the plugin's kernel-side code decides what the plugin may do, then a compromised or buggy plugin removes its own limits and the grant means nothing. So the split is three ways rather than two: | Part | Responsibility | |---|---| | Client, in the vault app | Calls the capability | | Plugin, kernel side | Implements the functionality | | **Kernel** | Decides whether this vault holds this capability, and with what attenuation | That is the same referee-and-player distinction drawn for the state machine, and the same reason: enforcement belongs at the layer that cannot be bypassed, which is now the fourth time this session has reached that conclusion. One refinement worth adopting from the credential literature: capabilities should be **attenuable but not expandable**. A grant passed onward may only narrow, never widen, so a workflow invoking a plugin on behalf of a user receives at most the intersection of what each of them holds. That makes delegation safe by construction rather than by review. ## The Migration Is The Hard Part, And It Is Solvable The memo identifies the real risk. The project lead: **"the challenge here is that we need to add this in a way that it is either compatible or detectable from the existing vaults."** With a proposal. The project lead: **"maybe we have a bit that some of these can actually be registered, that although they are not added by the vault, if there's a call to that endpoint, maybe they get added."** Implicit registration on first call is a good transitional step and a bad destination. As a destination it defeats the entire property, because if calling something grants the authority to call it, the model is ambient authority with extra ceremony. But as a **first stage it is exactly right**, provided one thing is added: record every implicit grant. That converts a migration nobody can plan into one that plans itself. ``` STAGE 1 implicit grant, every grant RECORDED nothing breaks, nothing is enforced produces the data the migration needs STAGE 2 read the data now you know which vault uses which capability, derived rather than guessed STAGE 3 explicit declaration honoured; undeclared still works but warns, and the warning names the capability and the vault STAGE 4 declaration required new vaults first, existing vaults on a date, with the list from stage 2 as the work plan ``` The principle worth stating generally, because the corpus will face it again: **instrument before you enforce.** You do not need to predict what will break when you can measure it, and the measurement costs one log line per grant. Stage one is also independently useful even if the rest is deferred. A record of which vaults exercise which capabilities is an inventory nobody currently has, and the corpus has argued repeatedly that not knowing your own estate is itself a rateable finding. ## What This Buys Beyond Security Three things the memo mentions and one it does not. **Testability in isolation.** The memo names it. The project lead: **"it can be tested, it can be run in isolation."** A component with declared imports can be tested against stubs for every one of them, which is much harder for code that reaches ambient services. **A smaller core.** Feature creep in the vault becomes feature growth in the plugin set, and the kernel stops growing with every capability. That is the same argument the previous brief made for keeping the execution engine small enough to verify. **The precedent already exists.** The memo cites it. The project lead: **"a really good example is what we did with LLMs, where the first version had lots of code inside the vault, and then we refactored out and we added to the SG LLM namespace."** So the pattern is proven in this codebase; this generalises it and adds the grant. **And the one it does not mention: this is what makes capabilities sellable.** The payments work of this morning established budgets per agent and per action as the containment control worth building. A capability grant is the natural place to attach one, so a vault may hold the inference capability with a ceiling, or hold it only for particular models. The plugin boundary and the budget boundary are the same boundary. ## Plugins And Workflows Are Two Halves The memo anticipates the connection. The project lead: **"especially as we move to workflows, we should basically be moving the code of the vault into this sort of plug-in environment."** The relationship is precise and worth stating for the plan: - A **plugin** determines what a vault may do at all. - A **workflow** determines what it may do now, in what order, and within what budget. - A **step** in a workflow invokes a capability that a plugin provides. - The **kernel** checks both: is this capability granted, and is this step legal here. Which means the two projects share an enforcement point and should share a design session. Building them independently risks two permission models that disagree, and a system with two permission models has neither. ## A Plan Ordered so that each stage is useful alone. 1. **Enumerate the capability surface.** Every distinct authority a vault application can currently exercise, listed. This is a document, not code, and it is where the plugin boundaries come from. 2. **Record implicit grants**, changing nothing else. Stage one above. 3. **Define the grant interface**: how a capability is declared, granted, attenuated and revoked, with handles rather than names. 4. **Extract one capability** as a plugin, with the inference namespace as the obvious candidate since it is already half separated. 5. **Read the recorded data** and produce the migration list. 6. **Extract storage**, which is the hard one and the one the memo is really asking about. 7. **Move to declaration required**, new vaults first. 8. **Attach budgets to grants**, joining this to the payments work. Storage is deliberately late. It is the capability every vault currently assumes, so it is the one where implicit grants are universal and the migration is real work, and it is the one worth having the recorded data for before starting. ## What This Does Not Try To Be - **Not a module system.** Plugins are capability grants; the code organisation follows. - **Not permission checks in the plugin.** The kernel decides; the plugin implements. - **Not names.** Handles, because the reference is the permission. - **Not a breaking change.** Implicit grants, recorded, then narrowed over four stages. - **Not separable from the workflow engine.** One enforcement point, one design session. ## Honest Tensions | Tension | Note | |---------|------| | Least authority versus developer convenience | Every capability must be requested and granted, which is friction on every new feature, and the friction is the point | | Removing ambient storage access | It is the right target and the one every existing vault depends on, so it is the most disruptive and the most valuable | | Plugins as security boundary versus as code organisation | Both are real and only one drives the boundaries, and treating a refactor as housekeeping will quietly widen authority | | An existing component runtime versus building it | Mature semantics and tooling against a substantial dependency in a core component | | Instrument before enforcing versus the interim | Stages one to three leave the property unenforced for as long as the migration takes | | Two permission models | Plugins and workflows must agree, and if they are designed separately they will not | ## Open Questions | Question | Notes | |----------|-------| | What is the capability surface? | The enumeration is the first deliverable and determines everything after | | Handles or names for storage? | Handles are correct and change every call site that currently passes a path | | Which isolation mechanism? | Typed imports as a discipline, and whether the runtime comes with it | | How is a grant attenuated? | Narrowing only, so delegation is safe by construction | | Where do budgets attach? | To the grant, which joins this to the payments work | | How long does stage one run? | Long enough for the data to cover seasonal or rare usage, which argues for months rather than weeks | | Who may grant a capability? | Granting authority is itself a privileged act and needs its own answer | ## Relationship To Previous Briefs | Date | Document | Relationship | |---|---|---| | 6 Aug | `v0.33.56__arch-brief__sg-send-state-machine-in-the-vault-kernel-reference-monitor-write-is-the-attestation.md` | The sequence half of the authorisation model, of which this is the capability half | | 6 Aug | `v0.33.56__arch-brief__sg-send-engine-outside-the-vault-statecharts-are-the-formalism-vocabulary-and-override-boundary.md` | The engine that invokes these capabilities, and the shared enforcement point | | 6 Aug | `v0.33.56__arch-brief__sg-send-vault-architecture-for-payments-least-privilege-billing-vault-derived-balance-credential-not-address.md` | Least privilege applied to the hot path, which this generalises to every capability | | 2 Aug | `v0.33.55__arch-brief__sg-send-vaults-as-substrate-asynchronous-agent-collaboration-through-encrypted-folders.md` | Split ownership by path, which is a capability grant expressed in the storage layer | | 27 Jul | `v0.33.52__arch-brief__sg-send-agentic-outbound-maturity-model-aomm-reach-motive-freedom-silence-could-has-will-liability.md` | Reach as a precondition, which a capability grant is the mechanism for bounding | --- ## Key Claims | # | Claim | |---|-------| | 1 | Asking why every vault can read and write is the ambient authority critique, arrived at from the practical end | | 2 | A capability is an unforgeable reference to a resource together with permissions over it, granted explicitly | | 3 | Plugins organised by code produce modules; organised by authority they produce a security boundary | | 4 | The reference is the permission, so interfaces should pass handles rather than names | | 5 | Ambient authority is the documented root cause of prompt injection, because the attacker asks the deputy to use authority it already holds | | 6 | Sequence and capability address the same problem from two directions, and neither is sufficient alone | | 7 | An existing component model implements exactly this discipline, with typed imports and host-performed grants | | 8 | A handle grants a subtree rather than a filesystem, which matches least authority better than category-based permissions | | 9 | A plugin must not adjudicate its own authority; the kernel grants, the plugin implements | | 10 | Capabilities should attenuate but never expand, so delegation narrows by construction | | 11 | Implicit registration is a good first stage and a bad destination, and recording every grant turns migration into measurement | | 12 | Plugins and workflows share an enforcement point and must be designed together or the permission models will disagree | --- ## Sources - The object-capability discipline enforcing least authority by restricting programs to explicitly received capabilities, and the definition of a capability as an unforgeable reference to a resource together with permissions over it: https://arxiv.org/pdf/2605.24036 and https://medium.com/swlh/capability-based-security-and-macaroons-aaa64fb9fc01 - Ambient authority as privileges automatically used by a process, its role in confused deputy attacks, the original compiler case in which authority to act was conflated with designation of what to act upon, and the mitigation by eliminating ambient authority: https://en.wikipedia.org/wiki/Confused_deputy_problem and https://css.csail.mit.edu/6.858/2017/lec/l06-capsicum.txt - The identification of ambient authority as the root cause of prompt injection, on the grounds that an attacker need only ask the confused deputy to use the authority it already holds, and guidance recommending a deny-by-default capability model for agent tool execution: https://cosmonic.com/blog/ai-sandbox-guide/ - The component model in which a component begins with no filesystem, network, system calls, environment variables or host visibility, every capability is declared as a typed import and granted by the host, grants may be virtualised, and a directory handle confers access to a subtree rather than a filesystem, described as matching least authority better than operating system permissions or container capabilities: https://blog.cosmonic.com/engineering/aiops-and-agentic-ai-security-in-a-componentized-world/ and https://zylos.ai/research/2026-03-12-wasm-sandboxing-ai-agent-runtime-isolation/ - The observation that every agent acting on behalf of a chain of delegators is a potential confused deputy, and the credential pattern of contextual caveats that may only restrict and never expand the bearer's authority: https://arxiv.org/pdf/2606.12320 --- This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).