Skip to main content
Gateway’s privacy story is not simply “the database stores no prompts.” A request still crosses an authenticated entry point, uses credentials and may disclose content to a provider. The selected design protects those boundaries separately and keeps the resulting diagnostic records from becoming an accidental content archive.

​
Do not trust self-declared authority

A tenant, purpose, actor identifier or grant-looking field inside an untrusted request cannot widen the authenticated caller’s scope. The relevant host, authority and credential owners establish current permission. Gateway must apply that permission to the actual operation, destination and data—not infer it from the presence of a syntactically valid identifier or matching hash.

​
Preserve restrictions through recovery

A retry or provider change must preserve applicable region, provider, handling and disclosure requirements. A temporary failure does not grant permission to send the material somewhere else. Credential failure is scoped to the affected credential where the evidence supports that classification. Compliance signals must stop the prohibited recovery behavior rather than trigger account rotation intended to bypass it.

​
Keep sealed content intact

For a governed Context request, accepted shaping happens before sealing. The final provider-visible material must match the applicable package and disclosure contract. No hidden prompt additions or last-minute trimming should occur after that boundary. The token and output-window handshake must use the accepted content, not a convenient modified version that the caller never authorized. An ordinary caller profile must still satisfy its own applicable controls. This guide does not claim that every current route already has a fully qualified Context supplier.

​
Leave useful records, not secret copies

O1 retains content-free execution evidence. The observation reporter also excludes prompts, answers, private reasoning, credentials, unfiltered headers and raw provider bodies. Errors should carry bounded, sanitized diagnostic facts such as classified failure and attributable native identifiers. A debug path that leaks content can undermine the intended boundary even when the main database schema is content-free. Answer and source retention stay with their actual owners and policies. Separate diagnostic capture, when applicable, needs its own explicit access and retention rules.

​
Permissions must be demonstrated, not diagrammed

Serving, recovery, correction, settlement acknowledgement and protected readback have distinct privileges. A serving identity does not automatically receive direct access to private native history or another tenant’s call. Deployment evidence must establish effective database grants, credential custody, revocation behavior and current target mapping. Tests should reject wrong-scope requests before prohibited provider disclosure, not merely raise an exception after sending. No production credential, live endpoint secret or internal source archive is required to read this guide. For the conceptual boundaries, see Data and permissions and Database boundaries.