> ## Documentation Index
> Fetch the complete documentation index at: https://gora.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Ai sharing consent gap 2026 09 21

# AI-sharing consent: current gap and minimum launch gate

Read-only design review, 2026-09-21. No consent implementation, provider call,
deployment, or inferred user approval is recorded here.

## Current finding

User-data AI dispatch is **not release-ready** without explicit, informed
provider-sharing consent and authoritative backend enforcement. Read-only app
browsing and non-AI execution need not be disabled by this gate.

Current-source evidence:

* iOS `SettingsScreen.swift:984` and Android `SettingsScreen.kt:125` contain
  passive processing disclosures, not an approval flow or durable grant.
* iOS `AppDetailScreen.swift:639` / `:645` and Android
  `apps/AppWebViewScreen.kt:232` / `:237` forward app and instance invocations.
  Instance operations also include scheduling.
* iOS `GoraDevBridgeClient.walletSession` and Android `authenticatedAppSession`
  automatically sign bounded app-session challenges. Their permission text
  covers app use/instance lifecycle, not sharing data with an identified AI
  processor. A session is not AI-sharing consent.
* `crates/protocol-core/src/runtime.rs:1663`–`:1701` recovers a paid attempt or
  builds a provider request, reserves allowance, then sends it. No sharing
  consent check exists there. `node/paid_ai.rs` fences execution ownership and
  payment accounting, not consent.
* iOS `forgetAppConnection` clears local connection/activity state; it does
  not revoke background AI authority in the backend.

Neither funding, buying credits, clicking Analyze, installing an app, accepting
an agent-wallet policy, nor reading settings may be substituted for the missing
informed approval. The successful Signal Lab invoice/browser checks in
[the live browser report](signal-lab-live-invoice-browser-2026-09-21.md) do not
pass this separate gate.

## Minimum implementation

1. **A trustworthy disclosure.** Publish a nonsecret operator-maintained profile
   identifying the actual processor, sanitized destination domains, model or
   deployment family, data categories/purpose, Gora execution-record handling,
   and provider retention/training policy references. Do not expose raw endpoint
   queries or credentials, infer the processor solely from a model name, or
   invent privacy guarantees. Hash/version the public policy and bind it to the
   app and reviewed WASM artifact. Material app/provider/data-flow changes need
   fresh approval; ordinary API-key rotation need not.

2. **Explicit native approval.** Present a trusted native sheet before the first
   AI invocation, or as a separate optional action during connection. Name the
   app and processor, describe that observations, configured instructions,
   app/agent state and fetched data may be sent according to the declared scope,
   and offer Approve and Decline. Background execution needs separate opt-in for
   the named instance/schedule. Wallet connection, payment and signing consent
   remain separate. Reuse the existing native consent-dialog pattern, not its
   wallet-permission wording. Cover both direct `invoke` and instance
   `invoke`/`schedule`, including `invoke_then_action` helpers, through a shared
   coordinator at the bridge-client boundary. A read-only connection should not
   force AI consent.

3. **A durable, scoped grant.** Store grants under authenticated owner, API
   audience, app ID, artifact digest, provider-policy digest, data scope/purpose,
   and interactive/background scope. Record grant ID/revision, disclosure hash,
   issuance/expiry/revocation and approval evidence. A dedicated, expiring
   consent challenge signed only after explicit native review prevents an app
   from posting `consent: true` with an ordinary session. Do not auto-sign this
   challenge. The backend grant is authoritative; a native cache or WebView
   storage entry is not. Status/revoke endpoints must be owner-scoped.

4. **Admission and final dispatch checks.** Validate at invocation/enqueue,
   schedule create/resume and each scheduled run. Relevant hooks are
   `GoraNode.invoke` / `enqueue_durable` and `dev_http.rs` functions
   `create_schedule`, `set_schedule_enabled`, `run_due_schedules_mode`.
   Most importantly, revalidate immediately before each actual `llm`/`llm_json`
   provider dispatch in `host_llm`, using server-derived request/app/artifact and
   the actual configured provider. Integrate with the durable paid-attempt
   reservation so denial causes zero provider requests and no AI debit or
   reservation. Do not trust consent flags in guest input or allow an
   unapproved provider fallback. Native-only enforcement would leave CLI,
   direct API, recovery workers and schedules able to bypass the decision.

5. **Revocation and existing work.** Increment the durable grant revision and
   fence new dispatch admissions; pause affected schedules and queued jobs
   without deleting their IDs/history. Serialize revocation with final dispatch
   admission and document its boundary: already admitted/dispatched in-flight
   work may complete and cannot be recalled. Subsequent calls must stop.
   Preserve captured results, receipts and uncertain attempts for read-only
   recovery; do not redispatch or create replacement requests. Existing
   schedules without a matching explicit grant become `consent_required`, not
   grandfathered approvals. An operator/developer cannot approve sharing on
   another owner's behalf. Local disconnect must offer backend revocation
   rather than imply it stopped background work. AI revocation does not undo
   provider-held data or already-signed blockchain transactions.

6. **Other egress and frozen clients.** Guest HTTP egress can also disclose data
   in URLs; an LLM-only gate must not be advertised as controlling all external
   sharing. Its allowlist/data-sharing policy needs compatible enforcement.
   Native interception can protect frozen Signal Lab without editing its
   assets. The existing external-browser client has no new consent flow and
   must fail clearly with `consent_required` until an approved browser flow is
   available; frozen assets are not permission to bypass enforcement.

## Required verification before claiming this gate passed

* Approve, Decline, dismissal and timeout are exercised in native UI; none
  silently grant consent. Untrusted app code cannot create approval evidence.
* Missing/wrong-owner/wrong-app/wrong-artifact/wrong-provider grants produce
  `consent_required` with zero local fixture-provider hits and no AI charge.
* Named-instance/background scope cannot authorize another instance or
  schedule. Existing schedules do not run under inferred consent.
* Revocation while queued or between two calls stops the next dispatch.
  Restart/storage loss cannot recreate consent; stale provider/artifact grants
  cannot be reused. Exact captured retries cause no new sharing.
* Direct API, CLI, native invoke, scheduled runs and recovery workers obey the
  same backend gate. Pure WASM and authorized read-only recovery still work.
* Only after offline fixture tests pass should separately approved live
  acceptance use explicitly disclosed synthetic data. No prior test run or
  passive disclosure constitutes that approval.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.