Permission to Read Is Not Permission to Release: An AI Output Gateway

An analyst is allowed to read internal contract prices. Their AI assistant is therefore allowed to retrieve those prices while preparing a negotiation brief. The analyst then asks the assistant to email a summary to a supplier. Nothing in the original read permission proves that the supplier may receive competitors' prices, a derived ranking, a hidden attachment, or even the recipient list. Yet many AI systems treat generation as the last security step and delivery as plumbing.

The reader decision is: for each AI-produced message, file, tool argument, or export, should the system release it unchanged, minimize and transform it, require a human decision, or block it? The answer must bind the content to its provenance, requester, purpose, exact destination, amount, time, and governing policy.

The central rule is: permission to use information inside a task is not permission to disclose the result outside that task's trust boundary. Put a deterministic release gateway between AI execution and every outbound connector. The model may propose a payload; it must not grant itself authority to send one.

Reading authority is not release authority

Ordinary access control answers whether a subject may use a resource. Release control answers a different question: whether a particular information object may travel from this source context to that destination under these conditions.

The distinction matters because generation changes the object. A response may quote source records, compress many records into an aggregate, infer a sensitive fact, combine two harmless fields into an identifying pair, or embed content inside a spreadsheet, image, archive, URL, or tool parameter. A user who can inspect ten customer cases separately may not be entitled to export all ten. A support agent may see a customer's address but may not send it to an unverified chat identity. A cross-tenant summary can leak even when every individual retrieval passed its own check.

This is why the tenant-boundary design must propagate tenant and source labels into generated artifacts. Dropping provenance at the model boundary converts a known policy problem into guesswork over prose.

What primary guidance establishes—and where design begins

The underlying control model is established security practice. NIST SP 800-53 Rev. 5 AC-4 Information Flow Enforcement distinguishes information flow from later access. Its enhancements describe decisions based on information, source, and destination attributes; filters that block, strip, modify, or quarantine; and human review when automated decisions are not possible.

CISA's April 2023 Zero Trust Maturity Model v2 tells agencies to inventory, categorize, and label data and to deploy mechanisms that detect and stop exfiltration. Its optimal maturity example dynamically blocks suspected data exfiltration. The international Guidelines for Secure AI System Development, reviewed by the UK NCSC in November 2023, add AI-specific obligations: measure system outputs and behavior, log inputs consistently with privacy requirements, protect exposed interfaces, and plan incident response.

The AI failure evidence is equally direct. OWASP's Prompt Injection guidance says RAG and fine-tuning do not fully remove injection risk and lists sensitive disclosure and unauthorized actions among the outcomes. Its Sensitive Information Disclosure guidance warns that restrictions written in a system prompt may not be honored and can be bypassed.

Those sources do not prescribe the exact gateway, release tuple, receipt, or metrics below. Those are ZharfAI analysis: a vendor-neutral operating design derived from information-flow controls, AI threat evidence, and production failure modes.

Define the decision before choosing a detector

A release request is not just a string. Represent it as a versioned tuple:

The safe invariant is explicit allow, not absence of a detector hit. Unknown provenance, an unresolved recipient, a stale label, an unsupported file type, or a policy-engine error must not quietly become permission.

{
  "release_id": "rel_7f2c",
  "requester": "workload:sourcing-assistant@tenant-42",
  "purpose": "supplier-negotiation-brief",
  "source_labels": ["tenant:42", "commercial-confidential", "rival-pricing"],
  "destination": "mailbox:supplier-a@example.org",
  "destination_class": "external-counterparty",
  "payload_hash": "sha256:...",
  "records": 18,
  "policy_version": "release-2026-08-4",
  "proposed_action": "send_email"
}

Keep labels bound to source spans through retrieval, generation, and serialization. Content inspection can supplement that evidence, but it cannot reconstruct a source label that was discarded.

Put the gateway outside the model

The model and its working process should have no unrestricted outbound credentials or network path. Connectors receive only short-lived release capabilities minted after policy evaluation and bound to the destination, payload hash, action, tenant, and expiry.

A practical path is:

1. The retriever returns content with immutable source identifiers and policy attributes.
2. The model proposes structured output and a destination; it does not send.
3. A canonicalizer resolves recipients, expands templates, normalizes Unicode, decodes supported containers, and serializes the exact bytes under review.
4. The release gateway joins source labels, requester context, task purpose, destination trust, cumulative volume, and policy.
5. Deterministic rules choose allow, transform, review, or deny. Detectors and classifiers contribute bounded signals rather than final authority.
6. If allowed, a connector uses a single-purpose capability. Any change to bytes, recipient, connector, or expiry invalidates the decision.
7. The system records a tamper-evident receipt and outcome without copying sensitive content into general logs.

Network containment remains necessary, but it operates at a different layer. Kubernetes documents NetworkPolicy as IP- and port-level control and explicitly notes that its API cannot force traffic through a common gateway, handle TLS policy, or target services by name. A network allow-list cannot decide that one paragraph may go to an approved supplier while a rival's price must not. The release service needs application identity and message semantics, while the network ensures the model cannot bypass it.

The destination binding extends the browser-agent security pattern: authorize the final resolved recipient and action, not a model-written URL that can redirect after approval.

Use minimization as a controlled transformation

Detectors can find known patterns; transforms can reduce exposure. Google Cloud's Sensitive Data Protection documentation shows concrete mechanisms including masking, token replacement, encryption, deletion, field transformation, and record suppression. It also makes the dependency clear: info-type transformations apply to content identified by the configured inspection criteria.

That is useful machinery, not a proof of safe release. A detector can miss a project codename, Persian free text, a novel identifier, a value split across cells, or an inference such as “the only employee in this small branch.” It can also over-redact harmless material. Source labels and structured fields should therefore carry most of the policy load; content detection is defense in depth.

Treat each transform as a new artifact:

• produce a deterministic transformation manifest;
• preserve the original only in the protected task context;
• rescan and reevaluate the transformed bytes;
• check aggregates for minimum group size and differencing risk where relevant;
• invalidate approval if a human edits the result, adds an attachment, or changes the recipient;
• never let a failed parser, encrypted archive, or unsupported media type pass as “no findings.”

For some flows the right minimization is not redaction. It may be a fixed aggregate, a yes/no answer, a reference to an internal portal, or no release at all.

Make four outcomes operationally distinct

Review is not a fallback for every inconvenient case. Some flows—cross-tenant secrets, credential material, export-controlled data to an ineligible destination—should remain structurally impossible. Conversely, routing every low-risk release to a queue produces delay and approval fatigue.

Worked example: the supplier email that should not send yet

Consider a hypothetical bilingual procurement assistant. It can read tenant 42's contracts, quotes, delivery history, and negotiation notes. An authorized buyer asks: “Summarize our position in Persian and email it to Supplier A.” The draft is fluent and its visible body contains no account number. A naive DLP scan returns clean.

The provenance envelope tells a different story. Eighteen records contributed, including two rivals' quotes labeled commercial-confidential and a legal note restricted to internal counsel. The requested external mailbox is known, but the purpose policy permits Supplier A to receive only its own performance data and category aggregates above a minimum group size.

The gateway chooses transform, then review. A deterministic template removes rival-level prices, computes an allowed band from a sufficiently large group, replaces the legal note with an internal follow-up, and produces a source-to-output manifest. The transformed message is rescanned and assigned a new hash. The reviewer sees the destination, policy reason, removed fields, aggregate method, and final bytes—not a vague “AI thinks this is safe” badge.

Approval mints a capability valid for one email, one mailbox, one payload hash, and ten minutes. If the buyer adds an attachment, changes the address, or edits the body, the connector rejects it and starts a new decision. The numbers and policy are illustrative; this is not a claimed ZharfAI deployment.

Design review for judgment, not ceremony

A useful review package lets a person answer the unresolved policy question. It should expose:

• authenticated requester, task purpose, tenant, and destination trust;
• source objects, owners, classifications, and the spans or fields they influenced;
• original-to-transformed differences without unnecessarily widening access;
• detector findings, rule matches, uncertainty, cumulative release volume, and prior related attempts;
• the exact action, bytes hash, expiry, and consequences of approval;
• safer alternatives such as internal sharing, a smaller aggregate, or a portal link.

Apply the capacity and independence tests from the human-approval design guide. A reviewer who lacks context, time, authority, or a readable diff is not a control. High-consequence exceptions may require a second role or data owner; ordinary approved flows should remain automated.

Failure modes that appear compliant

Test bypasses, not only the happy path: alternate connectors, redirects, shared links, copy-to-clipboard, screenshots, encoded archives, multimodal payloads, streaming output, retries, queued jobs, and administrator overrides.

Record evidence without building a second leak

Each attempt needs a receipt that can answer who requested what kind of flow, from which sources, to which resolved destination, under which policy, with what decision. It rarely needs the full secret payload.

release_id, task_id, requester_id, tenant_id
source_object_ids, source_label_digest, provenance_coverage
destination_id, destination_class, connector_id
original_hash, transformed_hash, transform_manifest_id
policy_version, matched_rule_ids, detector_versions
decision, reviewer_id, approval_expiry, capability_id
attempted_at, delivered_at, connector_receipt, incident_link

Protect the ledger, separate reviewer access from general observability, and define retention. Join it to the broader AI audit-evidence architecture so an investigator can reproduce the decision without searching scattered model traces and mail logs.

Measure the boundary as a control system

Before enforcement, run policy in shadow mode against representative historical and live flows; record proposed outcomes without releasing anything new. Compare with known incidents, data-owner judgments, and existing business processes. Then canary by connector, data class, tenant, and destination class—not with one global switch.

Monitor:

• provenance coverage and the share of attempts with unknown or stale labels;
• allow, transform, review, and deny rates by policy, connector, tenant, and destination class;
• residual findings after transformation and releases invalidated by later edits;
• reviewer queue age, reversal rate, override rate, and disagreement by risk class;
• cumulative bytes, records, subjects, and unique recipients over rolling windows;
• direct-network bypass attempts, unsupported containers, parser failures, and policy timeouts;
• delivery receipts, recipient changes, post-release incidents, and mean time to revoke a connector capability.

Revisit policy when data ownership, destination contracts, jurisdiction, model behavior, connectors, or transformations change. Exercise a release freeze and connector revocation before an incident. Sample allowed flows for false negatives and denied flows for unnecessary friction; optimizing only the deny rate will either hide leaks or stop useful work.

The durable design is simple to state and demanding to operate: carry provenance forward, bind permission to final bytes and an exact destination, minimize deterministically, review only genuine judgment, and make every uncontrolled path incapable of sending.

Source Notes — Reviewed 2026-08-26

• NIST — SP 800-53 Rev. 5, Security and Privacy Controls
• CISA — Zero Trust Maturity Model v2
• UK NCSC and international partners — Guidelines for Secure AI System Development
• OWASP GenAI — LLM01:2025 Prompt Injection
• OWASP GenAI — LLM02:2025 Sensitive Information Disclosure
• Google Cloud — De-identifying sensitive data
• Kubernetes — Network Policies