#!RFC-AI/2;id=25;draft=6;v=0.6.0;status=draft;lang=en;dir=auto;theme=chatgpt-mono;sha256=b78d0b864eefc5cb2aafb738645f363bf9fb3777669a736dae70f0fb45913bcf
For easier reading, view RFC-AI documents using RFC-AI Reader software.

RFC-AI 25 — INFORMATION SECURITY, PRIVACY AND MEMORY POISONING
DOCUMENT CLASS: AI RFC — INTELLIGENT-WORK GUIDANCE
STATUS: DRAFT FOR CEO REVIEW — ENTIRE RFC-AI SYSTEM UNIMPLEMENTED

1. PURPOSE — WHAT AND WHY
Protect people, secrets and trust while enabling work. Privacy, security and legitimate authority are required outcomes, not excuses for empty activity or unchecked privilege.

2. INTELLIGENT-WORK DIRECTION
Separate private information from reusable guidance, treat retrieved content as untrusted data, use actual authorization boundaries and relevant security Standards, and test the system against realistic misuse and leakage.

3. PROPOSED IMPLEMENTATION APPROACH
Use the relevant authorized Interface, component and expressly designated Standard: authorization Interface and applicable security Standards. Investigate the complete relevant context before deciding what the assignment means (see RFC-AI 11). A competent worker may discover, invent and improve the necessary methods during implementation; this guiding AI RFC is not required to repeat low-level APIs, algorithms or technology choices. Previous and legacy systems are research evidence only, never an implementation of this draft.

4. EVALUATION AND ACCOUNTABILITY
Use independent DAVG as described in RFC-AI 22 to challenge whether the eventual real-world result meets the objective, not whether the AI RFC looks like a traditional API specification. A missing prerequisite creates an active cross-worker recovery obligation through the worker coordination Interface, not a reason to abandon the task (RFC-AI 20 and 31). Report only verified effects and preserve lessons without reintroducing old operational mistakes.

5. DESIGN CUSTODY
Original subject-specific intended contract: Private/generic boundaries, secrets outside documents/comments, injection defenses, provenance of retrieved context, least privilege, evidence retention and safe redaction.
Implementation tasks, legacy-derived candidate methods, proposed data schemas, tests and open engineering questions are kept with this draft's append-only objectives.txt or the responsible Interface/Standard. This RFC has NOT been implemented; it does not approve a deployment or create a new CEO release gate. Rewritten 2026-11-02T20:28:09.285Z.


## HISTORICAL FAILURE EVIDENCE — RESEARCH ONLY; NOT AN RFC-AI IMPLEMENTATION
Historical context: Browser DOM channels and logs risked leaking sensitive text; pattern matching alone could miss split or unlabeled secrets.
Historical reports have mixed evidence quality; verify primary facts before adopting a claimed root cause. Preserve source provenance and do NOT operationalize retired legacy policies as current RFC authority.

## MUST-DESIGN CRITERIA — CEO-DIRECTED PROPOSED FUTURE SYSTEM
MUST-25-01: MUST independently prevent unauthorized secret exposure across worker, browser, storage and log boundaries; simple phrase scrubbing alone cannot demonstrate secrecy.
MUST-25-02: MUST minimize shared data and treat legacy content as untrusted input, not a privileged directive.

IMPLEMENTATION STATUS: Entire RFC-AI system NOT IMPLEMENTED. Historical systems are independent past research material; no test or existing service may be counted as implementing this RFC-AI.


## ADDITIONAL MUST-DESIGN CRITERIA — 2026-11-02 (PROPOSED, NOT IMPLEMENTED)
Historical trigger: legacy materials repeatedly confused authored progress, scripts and document content with real observed execution; this is research evidence, not proof of any new RFC implementation.
MUST: Forensics MUST protect secrets, pseudonyms, privacy and collection permissions; independent event logs are not automatically reliable if collection or storage is compromised.
MUST consider the concrete literal behavior of competent AI workers and enforce required hard safeguards by simple, separately running Interface logic where an actual boundary exists. MUST not delegate Interface internal details back to this guiding document. MUST preserve the requirement in relevant top-level objectives.txt and independently verify that future implementation satisfies it. New requirements here remain draft, not live controls.

## DESIGN REVIEW ADDENDUM 2026-11-03 — PRIVATE CONTEXT AND SUPPLY CHAIN
REQ-AI-25-PRIV-001: Worker Continuity/Context/Assignment MUST be separately ACL-filtered at source before assembly; no private CEO vault, cross-worker history, API token, signed URL or unrelated human location may appear in a generic bootstrap. Untrusted retrieved material cannot grant rights or poison controlling principles.
REQ-AI-25-PRIV-002: High-trust forensics require independent collector custody, source/build identity, bounded retention and threat model; signatures or hashes by a compromised common writer do not establish independent truth.

SUPPLEMENTARY DESIGN CORRECTION CONTACT-PRIVACY — CONTACT AND LOCATION PERMISSION
RATIONALE: HereShift/TapVoyage planning records explicitly distinguish knowing a contact's name/phone from authenticated device enrollment, connection availability and revocable consent; a saved address-book record does not authorize location disclosure.
REQUIRED FUTURE BEHAVIOR: A worker or app MUST distinguish contact directory membership, verified contact identity, authenticated other-party device session, permission purpose/precision/duration, current connection and valid revocation. User selection of a name MUST NOT grant authority to fetch location, access contacts broadly or share location to a different recipient. Worker Context may report a consent status only through an authorized source; restricted contact/precise location values MUST NOT leak to unrelated worker Continuity or task-specific context. A stale contact presence is UNKNOWN, not online or available.
ADVERSARIAL DESIGN ACCEPTANCE: Switch contact A to B while A consent exists, revoke on A's actual device and disconnect B. No use of old A grant for B, no unauthorized location, explicit expiry/staleness; a browser mock cannot be represented as an installed Android capability.
STATUS: FUTURE DESIGN; NO LIVE APP/CONSENT IMPLEMENTATION IN THIS RFC.