#!RFC-AI/2;id=21;draft=4;v=0.4.0;status=draft;lang=en;dir=auto;theme=chatgpt-mono;sha256=228a9846ae18a3795c42abd28533eda714bb75e7d46f207ca9bcea9bac2eb7e0
For easier reading, view RFC-AI documents using RFC-AI Reader software.

RFC-AI 21 — AUTHORIZATION AND PRIVILEGED TOOL CONTRACTS
DOCUMENT CLASS: AI RFC — INTELLIGENT-WORK GUIDANCE
STATUS: DRAFT FOR CEO REVIEW — ENTIRE RFC-AI SYSTEM UNIMPLEMENTED

1. PURPOSE — WHAT AND WHY
Handle privileged actions through independent authorization. Trustworthy collaboration must not turn an assignment or retrieved text into unbounded authority.

2. INTELLIGENT-WORK DIRECTION
Use the designated privileged-action and authorization Interfaces. Distinguish what a worker proposes from what trusted execution code actually permits; investigate legitimate alternatives without bypassing human or provider controls.

3. PROPOSED IMPLEMENTATION APPROACH
Use the relevant authorized Interface, component and expressly designated Standard: authorization Interface and RFC-AI 32. 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: Separate RFC-AI 33 composite worker ID from authenticated principal binding, scoped authorization, credentials, revocation, privileged typed actions and audit receipts; historical GUIDs are optional evidence-only aliases and no comment grants permission.
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: Commands intended for Alpine/Windows/virtual hosts were applied with unsupported shell or privilege assumptions.
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-21-01: MUST authenticate principal, action, scope, machine and privilege independently; identity, nickname, provider selection and possession of a chat window are not permission.
MUST-21-02: MUST investigate legitimate alternate permitted capabilities when a permission check fails; MUST NOT circumvent, forge or escalate beyond existing authorization.

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: Recheck present authenticated authority at execution; source provenance, installer/build provenance and current capabilities must be independently verified.
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 — PRIVILEGED ACCESS CONTRACT
REQ-AI-21-PRIV-001: Worker identity, human-authorized delegation, assignment epoch, exact environment/target and permission are separate facts. GetWorkerContinuity then independent GetWorkerContext then GetWorkerAssignment LAST MUST NOT bypass full authorization at the protected effect boundary.
REQ-AI-21-PRIV-002: Scope future privileged interfaces to typed operations with exact allowed target, independent audit, short-lived grants and explicit revocation. Existing broad doas in historical systems is a lesson, not an implementation of this Standard.