Control use after access
Access control decides whether a subject may perform an action on an object. Information flow control constrains where information may move after it is read, derived, transformed, copied, aggregated, or sent. It can apply to files, messages, database fields, memory, network domains, tenants, classifications, and privacy purposes.
A permitted read followed by a permitted write can still create a prohibited flow. Flow policy must consider both operations together.
Labels, paths, and transformations
Identify source and destination domains, data labels, subject clearance or authority, operation, transformation, and release rule. Bind labels to data through parsing, storage, queues, caches, exports, logs, backups, and derived values. Protect label integrity and provenance.
Some systems enforce mandatory rules such as no read up or no write down. Others track taint, tenant, region, purpose, or personal-data state. The policy must define how joins, summaries, encryption, redaction, and declassification change a label.
Declassification and trusted subjects
Useful systems need controlled release. A declassifier can redact, aggregate, review, encrypt, or approve a transfer. It is a high-authority component in the TCB. Define its permitted input, output, transformation, reviewer, evidence, and failure state.
Do not assume encryption always permits a lower-domain flow. Key holders, metadata, length, destination, retention, and future decryption remain relevant.
Failure and residual risk
Missing or attacker-controlled labels can make enforcement meaningless. Derived data can reveal protected inputs even when raw values never cross. Logs, metrics, errors, timing, caches, model outputs, and backups can create unmodeled flows. A trusted subject can intentionally or accidentally release data.
Precise tracking adds complexity and can block legitimate work. Coarse labels are easier to operate and can over-share or over-restrict. Covert and side channels can remain outside the modeled flow system.
Pomerium boundary
Pomerium can restrict which identities reach a route and can pass documented identity context. It does not track data after an authorized upstream reads it or enforce field, tenant, purpose, export, log, or derived-data flow inside the application. Applications and data systems own those labels, transformations, declassification, and evidence.
Evaluation checklist
- Which allowed read-and-write sequence can move data into a prohibited domain?
- Are labels bound to raw, derived, cached, logged, backed-up, exported, and transformed data?
- Which component can declassify, under what exact transformation, approval, destination, and evidence?
- Can missing labels, joins, summaries, errors, metadata, timing, or model output reveal the protected input?
- Does route authorization stop at the application boundary while later information flow remains uncontrolled?
