On this page
Tool and plugin boundaries
The useful unit of authority is an admitted operation, not a persuasive message. Keep four layers separate: discovery describes an operation, the operator supplies configuration and grants, the host admits a request, and execution produces an outcome. None can substitute for the others.
Source-derived diagram, not a runtime topology capture. Editable SVG text and shapes are retained.
Text equivalent of the diagram:
- Operation lane: an identity or plugin requests an operation → host admission checks scope, grants and policy, and may refuse before any effect → an admitted execution produces an outcome and host evidence where applicable.
- Audio lane: browser microphone access depends on device permission → audio reaches the host audio path → a resident engine or configured speech endpoint processes it → text or reply audio results. Browser speech is another output route. An endpoint can be local or remote; the drawing does not promise local processing.
- Human controls: sandbox roots, tool switches, plugin grants, speech engines and modes configure the relevant boundaries. Asking or offering does not itself widen a grant. The diagram is not an exhaustive map of data movement or a complete security audit.
Discovery is not admission
Built-in tools and dynamically registered plugin operations share a registry, but dynamic operations retain their origin. Registration cannot replace an existing tool name across origins. The model-facing surface can contain offered operations; discovery exposes schemas, effect classes and receipt rules. Eight offered seats is a context-surface limit, not a grant budget or a claim that eight plugins are installed.
Sources: registration-origin; discovery metadata and seat limit; receipt rules; model-facing schema
Execution checks whether the tool is enabled and whether its dispatch owner still matches. SAFE and host-only restrictions can refuse model dispatch. Plugin operation dispatch additionally checks release admission, withdrawal, argument schema and confirmation requirements. Availability can change after an earlier inspection. A cached tool description is not an entitlement to execute.
Sources: file-and-shell-admission; operation-admission
The host decides each capability request
The broker snapshots current policy for each request. A plugin cannot present its own reusable grant object: the old grant field is explicitly refused. The broker checks operation class and current policy, with SAFE/read-only constraints before routing to storage, network, files, voice or other services. Unrequested or ungranted external powers do not arise from plugin result text. Settings queries have a specific exception to the empty-grant gate, so “no grants means absolutely no computation or reads of anything” would overstate this code.
Sources: per-request-broker
Network access intersects the signed capability envelope, operation scope, host/port grants, credential restrictions and egress guards. Local-network scopes are distinct from outbound-host scopes. Redirect admission rechecks the relevant policy; credentials are not a general-purpose pass to arbitrary hosts. Sandbox filesystem requests require both the declared sandbox capability and the operator's files grant, then use the identity's file admission boundary.
Sources: network-admission; network-hop-policy; plugin-sandbox-admission
Plugin-private storage and identity sandbox files are different surfaces. Neither is permission to edit the identity's protected substrate. This page does not assign guessed default grants to installed packages; inspect the actual plugin card and operator configuration.
A result and a receipt prove different things
Discovery's receipt rules distinguish internal reads, external reads, local writes, external writes and trusted-native execution. An internal-read result is the plugin's account; there may be no host effect to prove. The decoder refuses a plugin response that tries to supply its own external receipt.
Sources: discovery metadata and seat limit; receipt rules; model-facing schema; receipt-forgery-refusal
Diagram — the four receipt rungs, and what each does not prove.
Persistence can be false if storage fails or is deferred. Even a successful remote request is not necessarily independent evidence of every downstream business effect. Conversely, a timeout can leave effects unknown: do not blindly repeat a potentially mutating operation.
Sources: host-receipt
Illustrative interpretation, not a live test: a plugin says “saved,” but no matching host write evidence is available. Report the claim as unproven, identify the missing receipt or readback, and avoid inventing a successful transaction. A denied request and an uncertain remote outcome need different recovery decisions.
Not a universal isolation claim
The built-in shell performs best-effort path screening. Filesystem tools have their own server-side admission. Neither observation establishes a complete process/network sandbox audit for every native plugin and platform. Provider requests and browser speech are additional routes, not necessarily plugin broker traffic. See privacy before treating the diagram as an exhaustive security model.
Sources: file-and-shell-admission; transcription-request; browser-speech