Skip to main content

​
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 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.