Application resources and callable contract adapters — draft

Status: architecture/protocol proposal, 2026-10-12. User authorization covers this reversible specification work and publication of project artifacts; implementation and human review remain separate. Human sign-off: reviewer ___ / date ___ / outcome ___. Track the final decision and source reconciliation in DEVLOG. This proposal extends the existing resource, preference and grant model, contracts, federation implementation and security boundaries.

Provisional default after the three-option comparison: an owner's connection to an app is one ordinary Bindle resource implementing individually granted contract methods. An existing app MCP endpoint is an optional implementation adapter. Apps may still contribute separate domain resources where those resources have independent meaning or selection. This supersedes the earlier requirement to create a resource for every callable. No new app-state system, universal invocation contract or grant namespace is introduced.

Resources in an owner's pool

An application can contribute a resource to its user's existing resource pool. The resource is owned by the Bindle entity, with the authenticated contributing application recorded as its producer. Normally it represents that owner's app connection and exposes several separately granted methods. It is distinct from the app's global OAuth client identity. A shared pool is shared among that owner's explicitly authorized applications; it is not a public/global directory, cross-account namespace, new identity system or blanket account permission. Separate calendars or independently selected object collections may remain separate resources when that matches their meaning.

Existing preference fragments select resources by exact implemented contract URL. Existing application grants select fields, resource IDs, contracts and methods. Contributing an eligible resource does not assign it to a preference, fulfill an app's consent request, grant its producer access to other resources, or authorize another consumer to use it. The owner still chooses assignments and approves consumer access. Adding resources to a selected collection or preference must not silently expand prior consumer grants.

An application requesting contribution rights uses the existing registered-client OAuth flow. It requests explicit registry-contribution methods on a provider-managed, owner-scoped resource exposed through an ordinary preference field. Its existing bearer is addressed to the provider RPC endpoint and subject to live grants. No new token format, global registry, ambient browser session authority or provider-wide registerAnything scope is introduced. The current internal FederationService.registerResource(authority, …) accepts owner authority; it is not already a safe external app contribution endpoint and MUST NOT simply be exposed to arbitrary app bearers.

Reuse an existing authenticated owner staging workflow when it already provides these provenance and approval boundaries. Only when external app staging cannot be expressed safely through that workflow, add the minimal contribution-registry profile: list (this producer's proposals only), stage (new proposal or immutable candidate revision), and revoke (withdraw this producer's contribution), with normal resource/contract/method grant checks and the RPC journal. It is not arbitrary registry CRUD. An implementation must publish its exact immutable contribution contract and schemas before advertising those methods. This document does not invent a deployable route or claim those methods are wired today. Owner review/activation uses the provider's authenticated, CSRF-protected owner interface; producer applications cannot approve their own proposals.

Contribution records and activation

The provider assigns a fresh resource ID in the owner's namespace and binds it to the authenticated producer client ID. Neither owner nor producer identity is trusted from request fields. A proposal supplies a bounded display label, exact contract IDs/method sets, immutable descriptor/schema digests, and a provider-verified adapter binding. The producer references only an already verified adapter identifier. The host resolves its route and injects a stored credential reference after authorization; app-submitted secrets, authorization headers and arbitrary invocation endpoints are rejected. Connector credentials are stored separately by the provider. Public resource descriptors never contain credentials, endpoint authorization headers, arbitrary executable source or private connection configuration.

Only the producer that created a contribution may propose revisions or withdraw it; the owner can disable or remove any contribution. A producer cannot overwrite an owner-created resource, another producer's resource, a built-in alias such as @profile, or a resource ID chosen to collide with one of those. Cross-owner and cross-producer attempts fail without revealing private existence. The provider performs indexed owner/producer scans with bounded cursor pagination, not a global list filtered after fetching.

Lifecycle:

Registration asserts a proposal, not conformance. Origin control, declared schemas and app branding do not prove the adapter obeys a contract. The provider checks supported methods, credentials/transport boundaries, schema safety, declared effects, quotas and adapter conformance before activation. Unsupported contracts remain proposals and cannot appear as supported merely because the producer listed their URLs.

Contract definitions and their approved adapter bindings are immutable and content-pinned. Changing input/output meaning, route authority, method behavior, external recipients, cost model, effect classification or dependent permissions stages a new binding and, when contract semantics change, a new contract URL. Affected methods remain unavailable until owner review/activation and consumer reapproval; unaffected old methods can continue only when their old bindings remain valid. Existing grants never automatically authorize replacement definitions or added methods. The initial implementation may require review of the entire new contract version; selective migration must compare exact approved per-method digests and cannot inherit approval for a changed method. A cosmetic label change can use the provider's bounded metadata-update policy, but cannot change executable meaning. A descriptor digest does not attest remote code or prevent an external service changing behavior without announcing it. Treat external-service trust and detected drift honestly; the producer cannot establish read-only safety merely by declaring it.

Application state and execution are independent choices

An application may be a static web interface, a stateless compute endpoint, or an independently hosted service that owns all of its state. Bindle does not prescribe one of those models or introduce a new built-in app-state database. App state can live in any existing resource implementing contracts the app is explicitly granted: files, structured data, calendars, application services or other conforming resources. Files in hosted storage, Drive, WebDAV or S3 are examples, not a required persistence model. A brand name does not establish contract conformance or supported write preconditions. App-owned state remains valid and does not have to be copied into the provider.

The owner's existing preferences select those resources, and ordinary exact resource/contract/method grants authorize the app's access. Neither contribution nor adapter selection assumes that every resource is a file collection. A method binding describes a callable and its approved dependencies independently of where state lives. The UI should identify who stores the state and which external service processes it; provider-mediated access does not imply provider custody of every byte.

A callable's private, owner-approved execution binding selects exactly one of:

1. Existing resource contract method. The host binds the callable to one fixed granted resource, exact contract/method and bounded argument mapping. That resource may be local or remote. On every call it checks both the callable grant and the caller's live underlying resource/method grant. The binding is not chosen by model arguments. Ordinary storage tools should usually use direct trusted projection instead of creating a redundant automation wrapper.
2. Installed trusted provider module. A reviewed host module implements a bounded function over explicitly approved resources. This follows the existing plugin/module capability approach. A contribution can reference an installed binding but cannot upload arbitrary JavaScript, install a package or supply privileged closures. The host process is trusted; this is not a newly promised multi-tenant code sandbox.
3. Verified application callback. A stateless or stateful app endpoint accepts a bounded invocation and returns a bounded result. It may use its own app state, approved inputs, or narrowly delegated access to any selected resources under their existing contracts. State placement does not change caller consent or the adapter's authentication/egress/budget obligations. The callback adapter is unavailable until those boundaries and ambiguous-outcome handling pass their gates.
4. Existing application MCP endpoint. A verified importer binds exact upstream tools to separately granted Bindle methods as described below. It reuses an existing endpoint rather than requiring an app to implement another invocation transport. MCP conformance establishes neither domain contract semantics nor permission. Native contract/module paths remain equally valid without MCP.

Zero backend and stateless backend are distinct. A browser-only app can execute interactively while open, but the provider cannot run that closed browser's arbitrary functions. Its automation must map to an existing resource method/module, or use an explicitly configured compute endpoint. This proposal does not introduce a general hosted-function service, workflow language, scheduler or uploaded-code sandbox merely to support the word “agent.”

Ordinary methods, with optional MCP import

An app resource implements one or more ordinary immutable contracts with separately grantable methods. For example, a consumer can receive summarize while being denied send_report on the same app connection. The normal Bindle RPC envelope selects the exact resource, contract, method and durable tx. The approved adapter binding determines execution; business arguments cannot choose arbitrary resource/contract/method tuples, URLs, code, permissions or tool names. An input may contain a URL as bounded business data when the reviewed operation requires it; that never bypasses endpoint policy. The label “agent” adds no authority.

For an existing MCP endpoint, a provider importer can translate a reviewed tool catalog into ordinary immutable contract definitions and exact preference metadata. Each exposed method maps privately to one pinned upstream tool name and approved input/output definition. Current Bindle authorization accepts at most 32 methods per contract with identifiers matching [A-Za-z][A-Za-z0-9_-]{0,63}. Upstream MCP names may not fit, so generate stable collision-checked safe IDs and preserve the exact upstream names only in the trusted mapping. Unsupported or excessive catalogs fail visibly or are explicitly divided into bounded contracts; never silently truncate consent.

Existing preference fields match exact contract URLs with AND semantics. The importer generates/reuses the corresponding immutable preference metadata; a generic MCP marker cannot make arbitrary tool contracts selectable, and no wildcard matcher is added. A detected endpoint may be staged as an adapter candidate, but automatic assignment of an interoperability profile grants no consumer access and proves no calendar/storage or other domain semantics. Those claims require their own verified implementation of the exact contract.

Do not expose a generic tools_call({name,arguments}) or invoke({operation,...}) method as a substitute for separate grants. Its single Bindle permission would conceal the operation being authorized. The importer instead translates an already approved exact method into upstream tools/call. Tool additions and changed schemas stage new immutable contract/binding revisions; they do not expand grants. Collections remain organizational selectors whose consent expands into explicit current resource/contract/method selections.

The previous automation-v1 artifact is a superseded experimental design fixture, retained for comparison only. It has no canonical contract $id, is not an advertised production contract, and is not the mandatory app integration interface. Its describe/invoke shape does not define the generated contracts above. Existing resource-descriptor and preference methods continue to expose only approved information; exact callable schemas come from approved ordinary contract definitions.

The initial importer supports a bounded declarative JSON Schema subset: objects with named properties and additionalProperties:false; arrays with maxItems; strings with maxLength; finite bounded numbers/integers; booleans and null. No schema-driven fetching, custom executable validators or automatic default execution. A first adapter may reject $ref, patterns, unsupported formats and extensions explicitly rather than pretending full MCP schema support. Enforce depth at most 8, at most 128 schema nodes, at most 32 properties per object, safe integer bounds, byte limits, unique required keys and required-key membership. Verify minLength <= maxLength, minItems <= maxItems and minimum <= maximum where present. Parse/copy into prototype-safe records, reject reserved object keys, and bound actual values as well as schemas. Any recorded processor origin must parse as a canonical credential-free HTTPS origin, with no path beyond /, query or fragment; a URI-shaped schema field alone cannot enforce this policy. No endpoint is fetched merely because a schema mentions it.

Provisional importer ceilings: 64 KiB of UTF-8 encoded RPC request, 128 KiB result, 64 KiB descriptor, 30-second invocation deadline, at most 60 invocations/minute and four concurrent invocations per app resource. Advertise stricter effective adapter/transport limits where applicable; this profile does not change unrelated existing resource contracts. Reserve account/service work and spend for the complete invocation, including dependent calls, bytes and retries. A finite reviewed total slot bound is required; per-resource rate limits alone do not cap aggregate service cost or upstream invoices. Permit at most one upstream attempt unless verified durable idempotency proves retry safe. MCP request IDs and idempotency hints are not that proof. Unknown outcomes return indeterminate, never automatic execution with a fresh transaction ID. Long-running jobs, background scheduling, streaming, subagent orchestration, deferred callback workflows, self-modifying prompts and payment mandates are outside this first profile; bounded synchronous callback compute remains an allowed adapter.

Effects, data and invocation authority

Each approved method binding has an explicit effect policy describing data access, changes, deletion, external communication and spending as applicable. Pure computation over approved input may declare no domain effects, but only through an explicit reviewed policy; missing/unknown metadata is never interpreted as safe. Every invocation still creates ordinary audit/transaction metadata. A provider cannot verify a producer's effects solely by trusting its declaration or MCP annotations; externally implemented behavior remains a disclosed trust relationship, with unverified capabilities unavailable until their adapter policy is reviewed.

Owner consent identifies the real producer/client origin, exact resource and descriptor revision, input/output schemas in understandable form, data recipient, external destinations, possible effects, relevant resource/collection selections, budgets and revocation limits. Reading a resource and invoking an automation are separate permissions. Write, deletion, communication and spending capabilities are never bundled into basic read or contribution rights. A permanent grant can authorize repeated bounded invocations when its scope says so; it is not itself permission for every arbitrary model-selected side effect. Providers can require fresh confirmation for specified effect classes, but must bind that confirmation to the exact operation and input digest rather than a generic “approved” flag.

An invocation carries only approved structured inputs to the fixed adapter. The provider never forwards the consumer's bearer, its owner session, raw connector secrets or an ambient “all resources” capability. A producer's ability to register an automation grants it no data access. The owner configures dependencies through existing preferences, choosing exact resource/method rights, and the caller must independently possess the rights needed by the fixed invocation. The host checks the intersection, not a union that combines different principals' grants into a larger capability. A consumer cannot borrow the producer's broader grant merely by invoking its contributed wrapper.

For a provider module or fixed-contract binding, the host can enforce that intersection on every dependent dispatch. For an external callback, prefetching permitted inputs and accepting a structured proposed output is one useful optimization, not a required architecture. An application may need to call existing resource methods during its operation; the optional invocation-scoped adapter below supports that bounded interaction. Reading, modifying and conditionally storing a file is one example, not the only permitted contract. An app may also keep and operate on its own state. The callback receives no general provider bearer and cannot autonomously browse unapproved resources or choose additional methods.

An external service may independently retain other credentials from prior owner connections. A narrow invocation token does not revoke those credentials or sandbox that service. The UI describes that separate trust relationship honestly; operators should use isolated narrowly granted connections when stronger isolation is required. Descriptions of dependent resources are not automatic delegation.

Immediately before dispatch, require all of: live consumer grant; current owner/resource assignment; exact approved resource/contract/method; matching pinned binding; active producer connection and contribution; verified adapter; approved dependency grants and caller authority; valid input; and reserved aggregate budgets. Recheck live authority before returning cached results. Registration, consent and metadata are never alternatives to these checks. Imported app method dispatch uses the mutation-capable durable journal path even if external annotations say read-only; names or untrusted hints cannot downgrade replay protection. Unrelated already verified resource read paths keep their established semantics.

Optional invocation-scoped callback access

Some stateless or stateful callbacks need access to selected resources during execution. Delegation is contract-neutral: it authorizes exact existing resource/contract/method tuples and their approved argument constraints, without assuming storage semantics. A later enabled adapter may issue an extremely short-lived opaque invocation credential using the provider's existing issuer/token custody mechanisms. This specifies server-enforced restrictions, not a new JWT format, token-exchange standard or universal webhook credential. Issuance is part of an already authorized invocation, never a consumer-accessible “mint any scope” API.

The issuer stores the current owner, producer/callback client, original consumer, invocation/transaction ID, exact descriptor revision and input digest, exact provider RPC audience, absolute expiry no later than 60 seconds or the invocation deadline, and a fixed finite set of approved call slots. Each slot binds the exact resource, contract and method, approved contract-defined argument constraints and pinned argument schema, maximum call count and request/result byte bounds. When arguments are known before dispatch, pin their canonical digest too. For derived write contents, pin the original invocation input digest and approved argument constraints, then lock the concrete argument digest atomically on first use of that slot; do not pretend generated bytes were knowable at issuance. Scope is the intersection of owner-approved callable dependencies, consumer grants, producer connection policy and implemented methods. Methods with different effects must be separately approved. Key/prefix restrictions apply only when the underlying contract defines keys/prefixes; other contracts retain their own typed scope, concurrency and precondition rules. As one example, a file operation can receive one get slot for a selected key and one put slot for that same key, with an atomic version or absent condition and a bounded output size. If listing is necessary, it receives its own fixed-prefix, page/byte/call budget. Deletion requires a separate explicitly approved slot; writing does not imply deletion. A get plus put workflow has no global transaction, so version conflicts are returned for app resolution. An adapter lacking reliable conditional writes cannot claim that write capability.

The provider sends the opaque credential only in the protected callback envelope. It authenticates its outbound request to the callback using a separate host-held credential bound to that verified callback; it MUST NOT present a provider-RPC-audience token as if that token authenticated to the callback. Callback address, TLS origin and receiving client are pinned by the adapter binding, not supplied by invocation arguments. The egress adapter requires HTTPS, rejects redirects and private/loopback/link-local/reserved addresses, checks every DNS resolution against the actual connection target, and bounds body size, decompression, response time and concurrent attempts. An operator-approved development loopback exception cannot be advertised as production conformance. No secret enters a URL, log, search index, result or MCP response. Holder possession remains bearer authority within the slot limits; callback-origin metadata alone does not cryptographically bind a stolen bearer to that origin. Stronger presenter binding requires a separately implemented proof mechanism.

On redemption the issuer checks all live grants/contribution state, descriptor/input binding, audience, expiry and unused slot. It atomically reserves the slot and operation journal before dispatch. Same-slot identical retries return the recorded authorized outcome; changed arguments, other resources/methods, spent slots, input/descriptor mismatch or cross-owner use fail. The credential cannot issue credentials, register resources, alter grants or be redelegated by the provider. It cannot be renewed by the callback. A resumed invocation requires a fresh host authorization and budget reservation; old tokens remain spent/expired and a new lease cannot reset the original invocation's aggregate work allowance. Uncertain outcomes retain their reservations until reconciled.

Completion or deadline expiry atomically closes unused slots and prevents further redemption. The parent records the outcome of already reserved dependent operations before reporting successful completion; it cannot accept callback output as proof that an in-flight write succeeded. If a required effect remains unknown, journal the parent as indeterminate and retain reconciliation ownership and uncertain cost obligations. Token expiry and ordinary journal retention expiry do not reconcile an external effect or justify refunds. Revocation closes future work while accepted external effects may still finish. Completion is a capability lifetime boundary, not a newly introduced workflow engine.

A 3sln invocation credential does not automatically authorize a different provider's resource gateway. Cross-provider dispatch requires an explicit adapter with authority at the actual issuer, exact audience isolation and equivalent revocation constraints; unsupported delegation stays unavailable. App-owned state remains under the approved app connection and operation and need not be represented as fictional Bindle-hosted resources.

This optional access is disabled until those atomicity and replay guarantees exist in the real provider adapter. Fixed-host, direct-resource and optionally prefetched-input paths remain useful without it; none requires moving app state to the provider. No current source is claimed to implement callback execution, invocation credentials or refresh-free slot redemption merely because this draft describes them.

Revocation and resource lifetime

Revoking the producer's contribution grant or disconnecting the producer suspends its callable resources immediately. This differs from revoking an unrelated consumer: that consumer loses access, while the owner and other previously authorized consumers may continue if the producer remains connected. On either path, unexpired tokens and cached descriptors cannot revive access. The source retains its original ownership and custody when a producer disconnects; an owner-scoped Bindle reference does not transfer an external application's source data or credentials to the host. Withdrawal does not automatically delete owner messages, files, audit receipts or previously returned results. Owner-controlled removal/export remains available, with ordinary quota and retention policy.

Reconnecting the same producer or restoring a withdrawn resource does not silently revive old consumer grants. Fresh owner activation and consumer reapproval are required for the restored descriptor. Existing preference fields report unavailable/requires-consent state rather than transparently substituting a new resource. Accepted external side effects may complete after revocation; the provider cancels undispatched work but cannot promise to recall emails, money transfers, remote writes or copies already disclosed.

3sln MCP adapter

Bindle contribution, resource contracts, preferences and grants remain transport-independent. The 3sln MCP endpoint is a client-facing adapter over those primitives; it is not the registration authority or a second resource system. Self-hosted Bindle providers may expose the same resources through their own clients without implementing MCP. Conversely, implementing MCP does not establish Bindle contract conformance.

The outward adapter may project each currently granted app method as one stable opaque MCP tool name, mapped server-side to (owner,resource,binding revision,contract,method). Several tools may share one app resource. Labels and descriptions are bounded plain text; names derive from trusted identifiers and cannot shadow built-in tools or collide across app connections. tools/list exposes only live explicitly approved methods. tools/call resolves the server-side mapping and reapplies the full Bindle authorization intersection. No caller-supplied dispatch tuple, mutable description, guessed tool name or prior listing bypasses those checks. Provider-side revocation takes effect even if an MCP client has cached an old tool list.

The adapter uses approved schemas and effect policy to construct tool metadata. MCP annotations are hints, not authorization. Import and outward projection explicitly negotiate supported protocol versions; current 2026-07-28 features are not assumed compatible with every earlier endpoint or the locally verified 2025-11-25 profile. Unsupported schemas, result types and optional extensions fail visibly. MCP tools specification

For upstream MCP import, 3sln acts as a separate MCP client using a separately authorized upstream credential addressed to that endpoint. It never forwards the consumer's 3sln bearer or a provider-RPC invocation credential as upstream authentication. An arbitrary existing MCP server is not required to understand Bindle invocation tokens: optional delegated resource access needs an explicitly compatible integration, and cannot be smuggled into model-visible tool arguments. Discovery, authorization metadata, redirects and optional asset fetching share the verified egress/SSRF policy. Upstream scopes may be broader than a single imported tool; local method enforcement narrows dispatch but does not sandbox the upstream service's other credentials. MCP authorization specification

Descriptions, prompts, tool output and contributed content remain untrusted data. They cannot override system instructions, request extra grants, impersonate approval UI, redefine tool semantics, set an external target, or cause background execution. A result suggesting “call this privileged tool next” does not grant that permission. The adapter validates returned structures and byte bounds, keeps model-visible content separate from trusted routing, avoids embedding credentials, and never follows returned links automatically. Authorization constrains tool execution even when a model is successfully manipulated by hostile text; labeling content untrusted is not itself a complete prompt-injection defense.

Existing storage resources need no producer-staging conversion merely to expose supported storage functions. A trusted host adapter can project already approved exact get, list, put and delete methods into the corresponding MCP item functions while preserving resource ownership, live method consent, preconditions and capability limits. This is a representation of an existing granted contract, not registration of a new automation or permission expansion.

Current source distinction: the local MCP adapter exposes fixed collection/item operations with per-collection function consent. Its OAuth grant record is presently separate from FederationService grants. App/resource contribution and upstream MCP import are therefore not implemented merely by this draft. The adapter must add an explicit reviewed binding to live Bindle resource/contract/method approvals and the pinned implementation before exposing these tools. Existing collection read/write/delete scopes MUST NOT become implicit app method grants. No imported tool is advertised until its adapter and authorization bridge are implemented and tested.

The minimal next implementation is a trusted capability-dispatch port that resolves only an already approved (resource, descriptor revision, contract, method) binding, reuses the existing durable RPC journal, and supplies a filtered list of those bindings to the MCP adapter. Registering an installed module with that port is an operator action, distinct from an application's proposal to use an installed binding. This port still needs source work and tests; the existing frontend contribution registry does not itself authorize backend execution. App-facing registry staging/activation and callback dispatch/token redemption are additional unimplemented adapters. They must fail unavailable until independently enabled and verified, while ordinary implemented resource contracts continue working.

Architecture decision and review evidence

Before implementation claims, test cross-owner/producer registration, ID collision/alias overwrite, proposal invisibility, exact descriptor hashing, changed-effects reconsent, invalid/nested schema bounds, collection growth without grant expansion, producer/consumer revocation, suspended/withdrawn revival, stale list/invoke races, same-transaction collisions, external timeout/crash recovery, result reauthorization, hostile descriptions/outputs, SSRF and egress limits, and per-owner work/cost quotas. Conformance needs an independent producer and consumer fixture; configured metadata and a JSON artifact are not evidence of execution or provider guarantees. Production remains disabled under the existing security gates.

Application presentation and optional web app manifest discovery are described in app metadata. These fields cannot establish producer identity, contract compliance or grants.

Optional user-command presentation

Provisional design: an approved callable method MAY carry bounded declarative userCommand presentation such as a label, plain-text description, schema-field argument hints and an optional safely handled icon reference. This requests eligibility for a host's human interface; it does not require a palette, menu, toolbar or any other particular UI. The callable remains the same exact resource/contract/method and pinned binding. See callable methods and user commands for rationale, source boundaries and review places. The versioned metadata schema and external-command adapter are not yet implemented.

Absence of userCommand omits the method from ordinary human command discovery by default. Hosts MAY deliberately provide trusted mappings for supported contracts. Neither presentation nor its omission grants agent access. Hosts MUST NOT infer command eligibility or verified effects solely from an imported MCP title, tool annotation or discoverable schema. Unsupported schemas require an explicit supported mapping or omission from the generic human interface; they MUST NOT be silently weakened.

Presentation MUST NOT contain executable source, HTML, privileged argument expressions, authority rules or application-controlled approval UI. Hints refer only to fields in the authoritative argument schema and cannot alter it, introduce defaults or silently generate hidden inputs. Trusted installed host modules MAY provide rich custom UI through the existing module composition mechanism. External metadata is not an installed module and MUST NOT supply its executable command callbacks or dependency providers. Presentation updates cannot silently retarget approved callable bindings or expand grants. Track the presentation revision/digest distinctly from the pinned callable definition and implementation binding so cosmetic changes cannot bypass semantic pin checks.

The host's command adapter MUST preserve the same input validation, effect policy, live binding/dependency checks and durable transaction semantics as other adapters. Direct owner invocations use authenticated owner authority; agent invocations retain their own caller grants even when a person reviews them. Selecting a human command MUST NOT implicitly grant an agent access or lend the producer the owner's ambient session. Sensitive-operation review MUST bind the actual target, inputs, original caller and descriptor revision; unknown effect metadata is not a read-only exemption. Already accepted effects, indeterminate outcomes and disconnection retain the rules above.