Seal an AI worker input before validating and handing it off

Ask whether the approved bytes can still change

A trusted preprocessing service prepares an ordinary short note I-A for its fixed worker W-A. The service validates the note, then gives the worker access to its input object. If some other reference can still change that object, approval of the earlier bytes does not identify what the worker will read.

The existing anchored file-open profile explicitly assumes frozen contents. Its retained descriptor protects a different association; it does not supply this content-freezing step. Likewise, an inheritance allowlist decides which resources cross a launch boundary, not whether a permitted resource remains mutable.

This original worksheet concerns one application-created Linux data object. Source ownership, staging bounds, same-object lifetime and identity, current job rights and supported worker handoff are unimplemented prerequisites. Actual kernel, ABI and policy compatibility are unknown. Unknown prerequisites block real admission. All eight cards below are PROPOSED_UNRUN; no object, descriptor, mapping, seal or validation operation was created or exercised.

Freeze a narrow creation and ownership profile

The memfd_create manual describes an anonymous file descriptor opened for reading and writing. Select MFD_ALLOW_SEALING: without it, the initial F_SEAL_SEAL prevents adding other seals. Its name is a debugging label, so matching names establish no object identity.

Our proposed producer creates only ordinary bounded note data, with one lifecycle owner and no outside object references during staging. It uses no memory mappings, asynchronous I/O or outstanding writes at the sealing boundary. Finishing staging is a supported application responsibility, not a claim that returning from an unrelated operation proves every producer finished.

Both reviewed manuals identify Linux man-pages 6.19, with page dates of 8 February and 4 June 2026. Documentation availability establishes no installed support. This profile selects no executable-content behavior, huge-page option, descriptor-transfer API or alternative temporary-file fallback.

Require content and size restrictions together

The file-sealing manual makes seals inode properties shared by its descriptors; seals cannot be removed. F_SEAL_WRITE restricts contents but still permits size changes. F_SEAL_GROW and F_SEAL_SHRINK address the two size directions. F_SEAL_SEAL prevents adding further seals.

For I-A, the proposed complete set is F_SEAL_WRITE | F_SEAL_GROW | F_SEAL_SHRINK | F_SEAL_SEAL. The plan requires one successful addition of that full set and supported F_GET_SEALS evidence on the retained object. It does not lock the seal set first and hope to add missing protections later. Any operation failure or unexpected state holds admission.

The memfd discussion requires existing shared writable mappings to be unmapped before adding F_SEAL_WRITE. F_SEAL_FUTURE_WRITE instead leaves such mappings writable. It is therefore not an interchangeable substitute for this selected profile. Do not relax the policy merely to make a failed sealing attempt look successful.

Validate after sealing, then preserve the association

Represent the proposed sequence in a review record: staging finished; complete seal state established; bounded content validation accepted; current job association accepted; separately supported handoff eligible. Keep each disposition distinct. A successful seal operation cannot replace content validation, and a readable note cannot replace current permission.

The validator reviews I-A only after the required seal state is established. The later worker input must remain that same object through supported ownership and lifetime management. A reused descriptor number, reconstructed debugging name or second object with a familiar label is not this association. Those lifecycle controls have not been implemented here.

For the conditional positive, the ordinary note satisfies its intended text contract and current job rights remain valid. The service may then label the sealed input eligible for the independently reviewed W-A handoff. It does not report that W-A launched, consumed every byte, produced a correct summary or stopped when requested.

The existing descriptor inheritance worksheet remains a separate profile. Do not change its empty extra-descriptor allowlist by implication. This article supplies neither a launch adapter nor a descriptor transport.

Walk eight inert input-admission cards

These invented dispositions measure nothing. An eventual review record should use minimized input, job and profile labels, without copying private note contents or process details into ordinary logs.

Keep the useful claim smaller than isolation

Object stability does not establish provenance, confidentiality, harmless parsing or resistance to an untrusted worker. Independent source-size, validation-work and process-resource controls remain necessary. Neither an anonymous object nor this seal policy is a total memory, CPU or timing limit, and no physical RAM residency or persistence property is established here.

This is not the artifact publication contract: no durable name transition or synchronization is supplied. It is also not a peer-identity design. Known rights and separately supported handoff remain necessary even when the input cannot change under the selected policy.

No candidate syscall, OS inspection, content digest, runtime import, worker, API or model operation occurred. Boundary is prelaunch and does not provide a shipped file-sealing service or sandbox. Its synthetic policy evidence concerns different behavior.