Confidentiality

Approved recipient

1. Original. MV-17 contains the approved burn vector for chronos-gs-17. Chronos Hub retains this original. A readable copy can leave the store without changing or deleting it. This is a fictional sharing exercise. Flight dynamics may read assigned burn vectors; each tenant may read only its own. Kael is assigned to MV-17; contractor Dax has no permission to read it. The sender can export MV-17 and is responsible for sharing it only with an approved recipient. This drawing does not simulate an authorization implementation or encrypted transport.
2. Copy. The sender prepares a separate readable copy of MV-17 for Kael, an approved flight-dynamics reader. The original stays in the store. Preparing the copy is separate from delivering it. The copy appears after preparation finishes. The recipient remains empty until delivery. The example assumes that these sample bytes are accurate; it does not claim that an export verifies integrity. Recipient approval is part of the exercise’s stated policy, not a check performed by the moving token.
3. Deliver. The copy travels to Kael's approved work inbox. The burn vector becomes readable there only after arrival. The original and prepared copy remain visible. Receipt does not establish that the recipient was appropriate. The labeled token represents only the transmitted copy. The destination displays MV-17 after receipt. This transfer illustrates data disclosure, not a request granting access to the source service. It assumes a readable attachment and omits transport, mail-server, and storage details.
4. Assess. Kael is an approved reader for MV-17, so this illustrated transfer respects the stated audience. The original stays available in the store. This one approved delivery does not establish that every copy or sharing route is protected. Confidentiality permits intended recipients to learn information; it does not require that nobody read the record. This conclusion is bounded to MV-17, Kael's stated assignment, and the shown delivery. It says nothing about unknown additional readers, correctness of the vector, or timely service for all users.

Unapproved recipient

1. Original. MV-17 contains the approved burn vector for chronos-gs-17. Chronos Hub retains this original. A readable copy can leave the store without changing or deleting it. This is a fictional sharing exercise. Flight dynamics may read assigned burn vectors; each tenant may read only its own. Kael is assigned to MV-17; contractor Dax has no permission to read it. The sender can export MV-17 and is responsible for sharing it only with an approved recipient. This drawing does not simulate an authorization implementation or encrypted transport.
2. Copy. The sender prepares a separate readable copy of MV-17 for Dax, an unapproved contractor. The original stays in the store. Preparing the copy is separate from delivering it. The copy appears after preparation finishes. The recipient remains empty until delivery. The example assumes that these sample bytes are accurate; it does not claim that an export verifies integrity. Recipient approval is part of the exercise’s stated policy, not a check performed by the moving token.
3. Deliver. The copy travels to Dax's personal inbox. The burn vector becomes readable there only after arrival. The original and prepared copy remain visible. Receipt does not establish that the recipient was appropriate. The labeled token represents only the transmitted copy. The destination displays MV-17 after receipt. This transfer illustrates data disclosure, not a request granting access to the source service. It assumes a readable attachment and omits transport, mail-server, and storage details.
4. Assess. Dax has no permission to read MV-17, yet received a readable copy. That is a confidentiality loss even though the original remains intact. Removing the source would not recall the delivered copy. The loss is disclosure beyond the permitted audience, not alteration of the original. An encrypted connection or encrypted source storage would not repair the decision to deliver readable data to an unapproved recipient. Deleting or restricting the source later cannot reliably recall a copy that was already downloaded or forwarded.

This is a bounded sharing example, not an access-control design. An unchanged original does not prevent disclosure, and deleting it cannot reliably recall delivered copies.

Flow references: NIST SP 800-12 Rev. 1 - Confidentiality, Integrity, and Availability · OWASP - Authorization and Recipient Permissions