Design Information Flow Controls

Protection need

Choose one prohibited flow. Example: production customer support data can be read by an approved responder for one case, but it must not enter general analytics, development logs, model training, another tenant, or an unmanaged export.

Inventory raw values, identifiers, metadata, aggregates, inferences, files, messages, caches, logs, metrics, traces, backups, search indexes, exports, and model inputs and outputs. Map every process and person that can transform or copy them.

State confidentiality, integrity, purpose, tenant, region, retention, and release needs. Access to a source does not grant authority to write it to every destination.

Security objectives and requirements

Define a label model that applications can enforce. Use the fewest dimensions that express the requirement, such as tenant, sensitivity, purpose, origin, integrity, and retention. Define label authority, default label, unknown-label behavior, join rule, downgrade rule, and lifecycle.

Write allowed flows as source label, subject or process authority, transformation, destination label, purpose, time, and evidence. Example: a case export may contain one tenant's redacted fields, only after approval, encrypted to a named recipient, with a seven-day expiry and an immutable record.

Require labels on creation and import. Preserve them through serialization, queues, storage, caches, and backups. Reject or quarantine data with missing, invalid, or conflicting labels. Apply policy to metadata as well as payload.

Security invariants and evidence

Important invariants include:

• A process cannot remove or weaken a label without narrow declassification authority.
• Joining records produces a label at least as restrictive as all inputs unless an approved transformation states otherwise.
• Logs, metrics, traces, errors, and indexes do not receive fields forbidden by their destination policy.
• A subject with read access cannot write the value to a destination outside its permitted flow.
• Export, backup, restore, deletion, and recovery preserve labels and release constraints.
• Every declassification records input, transformation, approver or policy, output, destination, and reason.

Evidence combines schema and policy review, data-lineage records, label-integrity tests, negative flow tests, destination scans, export records, and recovery exercises.

Failure cases

• A background worker strips label metadata when it converts a message.
• An error tracker receives a sensitive payload after a parser failure.
• An aggregate reveals whether one protected individual appears in a small group.
• A support export is copied to a general object store without expiry.
• A model summary preserves sensitive facts while the raw source is deleted.
• A backup restores data without current labels or retention state.
• A trusted declassifier accepts attacker-selected output fields or destination.

Test each through real storage and delivery, not only policy-unit evaluation.

Trusted transformations and release

Keep declassification in a small, separately authorized component. Fix the permitted input labels, transformation, output schema, destination classes, review conditions, rate, and evidence. Validate output after transformation. Do not let a caller supply arbitrary templates, code, destinations, or encryption keys.

Use independent approval for high-impact or unusual release. Protect reviewers from misleading previews by showing trusted source, destination, field, count, purpose, expiry, and residual inference risk.

Design tradeoffs and residual risk

Fine-grained labels improve precision and add policy, storage, query, and migration complexity. Coarse labels are easier to operate and can block useful work or permit broad flows. Strict denial can drive people to manual side channels if approved release is too slow.

Derived data, human memory, screenshots, endpoint compromise, timing, traffic analysis, and covert channels can remain. Record which are outside the enforced model and reduce source access and data lifetime accordingly.

Pomerium boundary

Pomerium can authenticate users and workloads and restrict access to routes. It can supply documented identity context to an upstream. It does not attach labels to application fields or follow data after access. The application, data platform, export service, logging pipeline, backup system, and human workflow own information-flow enforcement.

Exercise

Select one sensitive data class. Draw its complete lineage from collection to deletion. Define labels, authorities, joins, allowed destinations, unknown-label behavior, and one declassification path.

Create negative tests that attempt to move the value through an API response, queue, log, metric, trace, cache, search index, export, backup, model summary, and restored environment. Prove that prohibited destinations reject or redact it and that approved release produces complete evidence.

Evaluation checklist

• Does the model cover raw, derived, aggregate, metadata, log, cache, backup, export, and model output?
• Are label creation, integrity, joins, unknown values, transformation, and deletion rules explicit?
• Can any ordinary reader, owner, worker, or administrator weaken a mandatory flow rule?
• Is each trusted transformation narrow, independently reviewable, destination-bound, and evidenced?
• Do negative tests follow real data paths and cover failure, recovery, inference, and residual channels?