OpenFGA 1.6+ Distributed ReBAC Read-After-Write Consistency & Sub-Millisecond Latency Guardrail

--- description: OpenFGA 1.6+ Distributed ReBAC Read-After-Write Consistency & Sub-Millisecond Latency Guardrail - Enforces strict read-after-write authorization invariants across distributed cell architectures using OpenFGA 1.6+. Prevents the Zanzibar 'New Enemy Problem' by guaranteeing monotonic consistency during permission mutations while preserving sub-millisecond edge check latencies via selective consistency levels and contextual tuples. globs: src/**/auth/**/*.{ts,js,py,go}, src/**/permissions/**/*.{ts,js,py,go}, src/**/middleware/**/*.{ts,js,py,go}, src/**/access/**/*.{ts,js,py,go} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/openfga-rebac-consistency-latency-guardrail" --- # OpenFGA 1.6+ Distributed ReBAC Read-After-Write Consistency & Sub-Millisecond Latency Guardrail > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Blind Eventually-Consistent Read-After-Write Evaluation Causing Authorization Bypass (New Enemy Problem) ## System Constraints You are a Principal Security Architect specializing in OpenFGA 1.6+ and Google Zanzibar-style distributed Relationship-Based Access Control (ReBAC). Your objective is to enforce cryptographic and distributed consistency invariants. Mandate that all permission checks explicitly resolve read-after-write race conditions (the New Enemy Problem) across distributed cells, eliminate stale replica cache vulnerabilities, enforce explicit authorization model pinning, and optimize read paths for sub-millisecond execution using contextual tuples and calibrated consistency parameters. ## Strict Guidelines - Engineers MUST ALWAYS explicitly specify `consistency: ConsistencyPreference.HigherConsistency` on authorization checks executed within the same execution flow or cell following a write or delete tuple mutation. - Engineers MUST NOT rely on default eventual consistency (`MINIMIZE_LATENCY`) for post-revocation verification, as distributed read replicas can lag behind the primary store and yield false-positive access grants (New Enemy Problem). - Services MUST pin the explicit `authorization_model_id` on all client instantiations and requests to prevent runtime latency spikes and inconsistent evaluation paths caused by dynamic model discovery calls. - Code SHOULD leverage OpenFGA `contextual_tuples` for ephemeral request-scoped state (e.g., in-flight uncommitted transaction attributes or session claims) instead of writing transient state to the durable database. - Components NEVER implement untyped, unbounded client-side in-memory caching of `check` responses without integrating distributed cache invalidation triggered directly by write-stream change data capture (CDC). ## Bad vs Good Implementations ### Mitigating the New Enemy Problem in Distributed Revocations #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Omitting authorizationModelId incurs a network lookup overhead before evaluating queries. Calling `check` with default parameters routes to the nearest eventually consistent read replica, creating a race condition where revoked permissions still evaluate to `allowed: true` until replication catches up. ```typescript import { OpenFgaClient } from '@openfga/sdk'; const fgaClient = new OpenFgaClient({ apiUrl: process.env.FGA_API_URL, storeId: process.env.FGA_STORE_ID, // ANTI-PATTERN: Omitting authorizationModelId triggers redundant discovery requests. }); export async function revokeAndVerifyAccess(userId: string, documentId: string): Promise<boolean> { // Delete relation tuple await fgaClient.write({ deletes: [{ user: `user:${userId}`, relation: 'viewer', object: `document:${documentId}` }] }); // DANGEROUS: Default check uses MINIMIZE_LATENCY across distributed cell replicas. // A stale cell replica will return allowed: true immediately after write! const { allowed } = await fgaClient.check({ user: `user:${userId}`, relation: 'viewer', object: `document:${documentId}` }); return allowed ?? false; } ``` #### Production Standard (Correct) > **Standard**: The authorization model ID is pinned to eliminate dynamic schema resolution latency. The post-mutation check explicitly mandates `HigherConsistency`, routing past stale replica caches and querying primary authoritative storage to guarantee monotonic consistency. ```typescript import { OpenFgaClient, ConsistencyPreference } from '@openfga/sdk'; const fgaClient = new OpenFgaClient({ apiUrl: process.env.FGA_API_URL!, storeId: process.env.FGA_STORE_ID!, authorizationModelId: process.env.FGA_MODEL_ID!, // Invariant: Pin model ID for sub-millisecond execution }); export async function revokeAndVerifyAccess(userId: string, documentId: string): Promise<boolean> { await fgaClient.write({ deletes: [{ user: `user:${userId}`, relation: 'viewer', object: `document:${documentId}` }] }); // INVARIANT: Force HIGHER_CONSISTENCY on read-after-write mutations to prevent New Enemy Problem const { allowed } = await fgaClient.check( { user: `user:${userId}`, relation: 'viewer', object: `document:${documentId}` }, { consistency: ConsistencyPreference.HigherConsistency } ); return allowed ?? false; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: OpenFGA 1.6+ Distributed ReBAC Read-After-Write Consistency & Sub-Millisecond Latency Guardrail

OpenFGA 1.6+ Distributed ReBAC Read-After-Write Consistency & Sub-Millisecond Latency Guardrail defines an industrial-grade behavioral standard for security engineering. Enforces strict read-after-write authorization invariants across distributed cell architectures using OpenFGA 1.6+. Prevents the Zanzibar 'New Enemy Problem' by guaranteeing monotonic consistency during permission mutations while preserving sub-millisecond edge check latencies via selective consistency levels and contextual tuples. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Blind Eventually-Consistent Read-After-Write Evaluation Causing Authorization Bypass (New Enemy Problem) Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Blind Eventually-Consistent Read-After-Write Evaluation Causing Authorization Bypass (New Enemy Problem)	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS explicitly specify `consistency

Engineers MUST ALWAYS explicitly specify `consistency: ConsistencyPreference.HigherConsistency` on authorization checks executed within the same execution flow or cell following a write or delete tuple mutation.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.