How Superintelligence Works | Agent Temporary File Safety — Symlink Races, Atomic Writes and Secure Cleanup

Did you know that a temporary filename can be a security problem even when the AI agent never opens a suspicious website? Agents routinely download a worksheet, generate a PDF, convert a spreadsheet or save a draft before delivering it. A shared temporary directory can contain filenames chosen by other processes, symbolic links to unexpected destinations and partially written files. Reliable temporary-file handling creates private workspace under trusted ownership, avoids unsafe path reuse and verifies the completed artifact before telling the user the file is ready.

The practical method is to use secure temporary-file primitives instead of predictable names, restrict directories and file access, preserve open file descriptors where possible, validate path resolution, write final results under a clearly defined atomic replacement contract and clean up incidental copies without erasing unrelated files. This article works through one hundred invented file operations, a forty-artifact school transfer and the difference between atomic rename and crash durability. All numbers are teaching examples, not measurements of eduKate files or proof that artificial superintelligence already exists.

Continue from How Super Intelligence Works. The File Ingestion guide treats hostile uploaded content, and Download Resumption treats integrity across interrupted transfers. This chapter is about local filesystem authority and the transition from an agent’s scratch file to an independently verified user-owned output.

Choose a reading route

• Making PDF or spreadsheet artifacts? Start with secure scratch files, unique task workspaces and final replacement.
• Protecting storage? Study path resolution, symlink races, permissions and cleanup under the actual OS.
• Learning Mathematics? Recalculate the 100-file and forty-artifact disposition ledgers.
• Handling errors? Read atomicity, version-aware writes and independently verified final destinations.

Contents

• 1. Temporary storage belongs to a real security boundary
• 2. Predictable scratch filenames invite collisions
• 3. Symlinks can redirect an apparently ordinary open
• 4. Directory traversal needs more than a string filter
• 5. File permissions protect private working copies
• 6. Temporary directories reduce cross-task interference
• 7. Avoid reopening generated temporary files unsafely
• 8. Atomic final replacement prevents partial visible content
• 9. A successful rename is not proof of correct content
• 10. Concurrent writers require version-sensitive outcomes
• 11. Use bounded workspace size and processing time
• 12. Cleanup can fail after process termination
• 13. An original one-hundred-file-operation laboratory
• 14. The file ledger can reveal safe repair progress
• 15. A forty-artifact changed-context school task
• 16. Symlink race testing belongs in an isolated sandbox
• 17. Do not assume all temporary bytes stay local
• 18. Recovery after a final-state timeout
• 19. What students and parents can learn
• 20. A practical file-safety implementation checklist
• Frequently asked questions
• Official platform documentation
• Related specialist reading

1. Temporary storage belongs to a real security boundary

An AI assistant may download an official PDF, extract text, write a CSV and render a final explanation. Those intermediate files are not merely names in the model’s context: they are filesystem objects under a service account and operating system. The agent may share infrastructure with other tasks, plugins or containers. The application should not assume a filename is unique or a directory private because the model invented a reassuring name.

Treat workspace ownership and purpose as explicit. A private temporary directory can limit one task’s view of another’s files under the platform’s filesystem permissions. A generated scratch file might contain confidential learner information even if it will never appear in the final answer. Its access controls, retention and cleanup matter throughout processing, not only when the model writes a final message.

Python’s official tempfile documentation provides TemporaryFile, NamedTemporaryFile and TemporaryDirectory as high-level interfaces, and mkstemp or mkdtemp as lower-level primitives. It says these interfaces create random names with secure creation behaviour under the supported platform assumptions. That is preferable to picking a predictable path and opening it with ordinary write mode in a shared directory.

The correct design still depends on the operating system and storage environment. A network filesystem, container mount or platform-specific file locking rule can change available guarantees. The model cannot establish those facts by saying it used a safe temp name. Application code and deployment configuration must implement the actual filesystem constraints.

Return to contents or continue with Predictable scratch filenames invite collisions.

2. Predictable scratch filenames invite collisions

Imagine the agent always writes to a common name such as `/tmp/report.csv`. Two unrelated user tasks can compete for that same file. One task may overwrite the other’s output or read partial data while the other is writing. If a lower-trust process can create the path first, it may influence where a later open call resolves. A convenient constant filename does not provide isolation.

Use securely generated unique names or create a private task-owned directory. Python’s mkstemp uses secure creation and the O_EXCL-related platform guarantee described in its documentation, preventing a race in creating that file under supported assumptions. It returns a file descriptor and pathname. The caller must close and delete them appropriately; creating the file securely does not automatically perform its business processing or cleanup.

A task ID can be useful for correlation, but do not treat it as a secret unpredictable temporary filename unless the storage layer has deliberately designed it that way. A sequential task ID may be easy to guess, and a source document title can contain awkward path characters. Let the file library choose a safe object name while storing the task-to-path mapping behind the trusted service.

Keep the result’s final name separate from the scratch filename. A user may want `maths-practice-summary.pdf`, while the agent’s working file should use an independent secure generated path. The final publishing or download step can give the artifact a friendly name after verifying the actual bytes and correct destination.

Return to contents or continue with Symlinks can redirect an apparently ordinary open.

3. Symlinks can redirect an apparently ordinary open

A symbolic link is a filesystem object that points path resolution toward another location. If the agent checks that a particular pathname looks safe and later opens it, another process might change the path in between. The eventual open could resolve to a different target than the one inspected. That gap between check and use is a familiar time-of-check/time-of-use problem.

Restrict untrusted path components and use appropriate descriptor-oriented filesystem APIs where supported. Linux openat2 supports resolution restrictions such as RESOLVE_BENEATH, RESOLVE_NO_MAGICLINKS and RESOLVE_NO_SYMLINKS. These can constrain how a pathname is resolved relative to a trusted directory descriptor. They are Linux-specific facilities whose availability and exact semantics need to be checked, not general Python APIs every platform guarantees.

Do not assume checking a path’s string for two dots is sufficient. A symlink in an intermediate directory or a mounted filesystem may change the resolved destination. Similarly, resolving a name once and then reopening it later by name can reintroduce the race. Retaining a trusted open file descriptor and avoiding a fresh unsafe lookup can be safer under the applicable operating-system design.

Negative tests should use controlled fake files, not try to reach live secrets. Create a safe sandbox where a symlink switches during an attempted operation and verify the protected code refuses to open outside the intended directory. A model’s narrative claim that the path stayed inside the workspace is not evidence of what the kernel actually opened.

Return to contents or continue with Directory traversal needs more than a string filter.

4. Directory traversal needs more than a string filter

A filename supplied in an uploaded archive or model tool argument can contain relative components intended to escape the chosen extraction directory. A naive join operation does not guarantee that the final resolved path remains inside it. The service should apply the actual path-resolution and extraction rules before creating files, including appropriate checks on symbolic links and archive entries.

An absolute path is a different type of request from a relative filename under a controlled root. An arbitrary document title should not be permitted to decide the directory where the agent writes an output. Whitelist relevant file types and let the trusted application map user-facing names to safe storage identities. Access to an API that writes a file is not authority to choose every filesystem destination.

Path canonicalization can help interpret simple inputs but is not always sufficient against concurrent namespace changes. On supported Linux systems, openat2’s RESOLVE_BENEATH or RESOLVE_IN_ROOT semantics can constrain path resolution at the actual operation. Other environments need equivalent secure primitives or a narrower design. Avoid inventing a universal protection based on one string-regex pattern.

Test positive and negative cases. A normal Mathematics worksheet should be saved within its approved directory, while a path that escapes the root should be refused. The application should produce an understandable error without revealing the existence of protected files elsewhere. One legitimate path failure should not trigger an administrator-mode fallback or a retry outside the sandbox.

Return to contents or continue with File permissions protect private working copies.

5. File permissions protect private working copies

A scratch file may contain a student’s practice marks, correspondence or unpublished article draft. Ordinary shared-directory defaults might allow other service processes to inspect it under an inappropriate deployment configuration. Set access at creation and use task-specific directories or separate service identities where necessary. A later attempt to hide the file in the UI is not a substitute for storage permissions.

Python’s mkstemp documentation states that the resulting temporary file is readable and writable only by the creating user ID, and not executable under permission-bit platforms. That is a useful default within the library’s documented assumptions. The parent directory, shared service identity, backup system and later copies still need their own risk assessment.

Do not use world-readable permissions merely because an assistant needs a companion converter to process the file. A controlled worker can receive a file descriptor, restricted handle or authorized internal reference rather than widening the filesystem’s access to everyone. The particular approach depends on the process boundary, platform and actual user task.

Permission changes are consequential operations too. The model should not decide to make an unpublished answer key public to resolve a file-open error. Access scope comes from the authenticated task owner and designated tools. If a required converter cannot read a permitted file under the designed pipeline, repair the application boundary rather than silently broadening authority.

Return to contents or continue with Temporary directories reduce cross-task interference.

6. Temporary directories reduce cross-task interference

An application can allocate a private temporary directory to each logical task, then put derived files below that controlled root. This simplifies ownership, resource limits and cleanup because all ordinary scratch objects belong to one workflow rather than to a global directory full of unrelated files. It also helps avoid collisions between two simultaneous article-generation agents.

Python’s TemporaryDirectory can be used as a context manager to create and clean up an isolated directory under its documented rules. It is not a guarantee against every modification performed by hostile processes with access to that directory. The official documentation warns that cleanup of a tree being modified concurrently needs care, and that platform-specific symlink-attack protections affect some recursive removal methods.

Name the lifecycle. The task may run for minutes, fail after an external tool call or resume from a durable checkpoint. A scope-limited context manager helps for ordinary short tasks, but a long-running workflow needs explicit ownership and recovery so a restarted worker does not mistakenly delete another task’s still-needed files.

TemporaryDirectory is also not a replacement for data retention governance. A service might intentionally keep a protected audit receipt after the scratch directory is removed. Conversely, a copied private source left in a backup or vendor log is not erased when a local directory closes. Report actual cleanup scope rather than claim every copy everywhere was deleted.

Return to contents or continue with Avoid reopening generated temporary files unsafely.

7. Avoid reopening generated temporary files unsafely

Creating a file securely and then discarding its descriptor before a later tool opens the same pathname can reduce the benefit of secure creation if the name is in a namespace another actor can modify. The appropriate design might pass an open descriptor to a worker or keep a private directory whose entries cannot be replaced by untrusted principals.

Some libraries require a named pathname for conversion. Python’s NamedTemporaryFile supports a visible name, with deletion parameters whose behaviour differs by platform. The documentation explains that reopening a named temporary file while it remains open may require special treatment on Windows, and that cleanup can fail if another handle retains incompatible sharing rights.

Do not assume file-like object lifetimes are identical on every operating system. A conversion pipeline validated only on Linux may behave differently on Windows when it tries to reopen and remove a named temporary file. Test supported deployment targets and use proper exception handling rather than silently leaving sensitive scratch material after a failed converter call.

Keep the converter itself in the threat model. It may parse untrusted PDF or spreadsheet content, generate another temporary file or call external tools. The File Ingestion chapter explains parser isolation. Temporary-file permissions protect the scratch workspace but do not automatically make the bytes safe to parse.

Return to contents or continue with Atomic final replacement prevents partial visible content.

8. Atomic final replacement prevents partial visible content

Suppose an agent writes the first half of a PDF directly to the final user-visible path and crashes. The user might see a truncated or corrupt artifact with the intended filename. A safer pattern can write the full result to a secure file on the same filesystem, verify it, and then replace the final target using a supported atomic rename operation under the appropriate ownership and permission checks.

Python’s os.replace documentation states that a successful rename is atomic under the documented POSIX requirement and may fail when source and destination are on different filesystems. This supports changing which complete file a path names without exposing a partially written file through that same path during the replacement. It does not by itself establish that the file contains the correct answer or that the user authorised the destination.

Atomic rename and crash durability are distinct. Applications that require persistence through sudden power loss may need suitable file and directory sync operations and storage-specific guarantees, beyond merely calling replace. Do not promise durable completion across every filesystem just because the rename succeeded. Define the guarantee that matters to the task and test under the actual platform.

Prevent wrong-target replacement. Atomic operation on an incorrect path can still destroy or supersede somebody else’s file. Use stable artifact IDs, an approved destination root and appropriate version or overwrite rules. A user asking for a new practice worksheet has not necessarily authorised overwriting a prior file with a similar title.

Return to contents or continue with A successful rename is not proof of correct content.

9. A successful rename is not proof of correct content

A converter can finish and produce a complete but wrong file: pages may be blank, data may belong to a different user or a document may contain last year’s school rule. An atomic replacement only ensures one particular filesystem visibility transition under its supported semantics. The controller still needs independent acceptance checks appropriate to the artifact.

Validate file type and structure. For a generated PDF, a parser can check basic readability, expected pages and relevant content; for a spreadsheet, formula references and recalculation may need review. A checksum can tie final bytes to a verified staging artifact, but it does not certify facts or permission. Keep mechanical integrity and semantic correctness as separate gates.

Check the actual saved destination. A success status returned by a file tool may describe a temporary staging object rather than a public downloadable artifact. If the user needs a link, the application should verify the final file exists at the exact authorized location and that the link resolves through the user’s intended access policy.

Do not invent or guess a sandbox path in the agent’s response. A plausible filename generated in language is not evidence of a created file. The final user-facing artifact link should come from actual storage or a trusted provider receipt. If verification is unavailable, state the limitation instead of presenting an unverified link.

Return to contents or continue with Concurrent writers require version-sensitive outcomes.

10. Concurrent writers require version-sensitive outcomes

Two AI workers might prepare revisions of the same worksheet at once. Each can write a complete staged file, but if both replace the final destination unconditionally, the later one can overwrite a valid newer revision. Atomic replacement protects against a partially visible file; it does not prevent logical lost updates between competing writers.

Bind the expected resource version or owner to the final commit. A source store may expose ETags or conditional writes, and a workflow can use a lease or compare-and-swap rule where supported. The Concurrent Document Edits guide covers these problems in more detail. A filesystem path alone does not identify which revision is current.

Consider the user approving revision 5, then another worker producing revision 6 with a changed deadline. The first worker must not use its approval for revision 5 to replace the document with unapproved revision 6. Check current content and human authority at the actual commit boundary, not just when generation began.

An unsuccessful conditional replacement should produce a meaningful Conflict or Needs Review status. It must not trigger an administrator write that bypasses the version guard. Preserve both staged artifacts under controlled ownership long enough for legitimate reconciliation, then remove unnecessary copies according to the retention policy.

Return to contents or continue with Use bounded workspace size and processing time.

11. Use bounded workspace size and processing time

A temporary-file directory can fill a disk or exhaust file descriptors if an agent repeatedly downloads large content, creates intermediate copies or loops after a converter failure. Quotas, file-size limits, count limits and task deadlines protect other users sharing the same infrastructure. A clean permission design is not sufficient if one permitted workflow can monopolize storage.

Use actual measured resource controls rather than ask the model to remember that files should be small. An archive that expands during conversion can consume far more space than the original compressed upload. A multi-step workflow needs a parent-task budget that accounts for every child converter, not only the final artifact size.

When a limit is exceeded, the application should stop optional processing, preserve necessary error evidence and remove safely owned scratch data. It should not delete a shared directory to free space or bypass a size limit through another uncontrolled tool. A bounded failure can be a responsible outcome even when the user’s report remains unfinished.

Report resources distinctly from success. A ninety-percent disk utilization alert is not evidence that a worksheet file is wrong; a complete file may still contain an unsupported educational claim. Monitor both workspace health and artifact verification, with the proper owners and consequence levels.

Return to contents or continue with Cleanup can fail after process termination.

12. Cleanup can fail after process termination

TemporaryFile and TemporaryDirectory context managers help with ordinary cleanup, but a process can be abruptly terminated before its normal exit handlers run. Python documentation notes that on POSIX a NamedTemporaryFile may remain after SIGKILL, and that certain cleanup behaviours differ across platforms. A robust production workflow needs an orphan-cleanup plan in addition to routine context managers.

Associate each scratch workspace with a stable owner, creation time and lifecycle state. A controlled cleanup job can identify expired workspaces after confirming no active task still owns them and no unresolved operation needs their contents. A filename merely looking old is not enough to establish safe deletion if another worker is still using it.

Careless recursive cleanup can be dangerous in directories modified by untrusted actors. Python’s TemporaryDirectory documentation cautions about concurrent tree modification and symlink-attack susceptibility depending on the platform and implementation. Use appropriate secure directory traversal and restrict who can modify the tree; a general command that recursively deletes an unchecked user path is not a safe recovery tool.

Retention and privacy remain separate. Cleaning one local working copy does not prove cloud backups, provider conversion outputs or logging attachments have also been deleted. Conversely, a legitimate user artifact should not disappear because it was stored accidentally under a temporary directory that a cleanup job removes. Distinguish final deliverables from scratch by actual ownership and lifecycle.

Return to contents or continue with An original one-hundred-file-operation laboratory.

13. An original one-hundred-file-operation laboratory

Imagine a fictional Cedar File Workshop attempting one hundred artifact operations. Sixty-four produce independently verified output at permitted destinations. Fourteen are safely rejected because a proposed path escapes the approved root or violates naming rules. Ten are refused because path or symlink resolution is unsafe. Seven have finished content processing but need cleanup or retention disposition. Five have uncertain final-state evidence after an interrupted replacement or provider response.

The categories are mutually exclusive: 64 + 14 + 10 + 7 + 5 = 100. Verified artifacts represent 64%, path refusals 14%, unsafe-resolution refusals 10%, cleanup-pending cases 7% and unknown final effects 5%. These are invented teaching proportions, not observed file incident rates, model success rates or actual eduKate storage statistics.

Do not call every refused path a service failure. Preventing an untrusted file from escaping its designated workspace is exactly what the control was designed to do. On the other hand, a staged file that still awaits cleanup is not automatically a completed user artifact. Its disposition may require a verified final destination or an authorized retention decision.

Use distinct evidence for each class: actual secure file creation, a verified refusal before unsafe resolution, a final target readback or a cleanup receipt under the task’s ownership. A model’s statement that it wrote the file safely is weaker than the operating system’s actual file identity and authorized destination.

Return to contents or continue with The file ledger can reveal safe repair progress.

14. The file ledger can reveal safe repair progress

Suppose the five unknown effects are investigated. Three are confirmed to have produced the intended output without needing another write, and two remain unresolved. The verified count becomes sixty-seven, unknown becomes two, and the other categories stay unchanged. Check 67 + 14 + 10 + 7 + 2 = 100. This later snapshot should not rewrite the fact that five cases were originally uncertain.

The three newly verified items were not created a second time; only evidence improved. Reissuing every file-write operation after a timeout could overwrite a newer user revision or create duplicate output. A stable artifact ID and conditional write rule are valuable even for local files, especially when workers resume from checkpoints.

Do not count individual file-open attempts as new user tasks. One document conversion may involve several scratch reads and writes but produce only one intended PDF. A resource dashboard can count I/O operations for performance, while the user-value ledger counts correct verified artifacts. Mixing these denominators inflates progress.

Keep the exercise transparent. The percentages are chosen for arithmetic, not as evidence that a real filesystem is sixty-four percent safe. A production estimate would require a defined population, sampled operations, independent labels and the platform’s actual permissions and failure conditions.

Artifact disposition	Cases	Share	Required evidence
Verified completed artifact	64	64%	Correct destination and content
Unsafe path rejected	14	14%	Stay within permitted root
Symlink or path race refused	10	10%	No unintended resolved target
Cleanup or retention review pending	7	7%	Check legitimate ownership
Final effect unknown	5	5%	Reconcile original artifact
Total designed operations	100	100%	Fictional task population

Return to contents or continue with A forty-artifact changed-context school task.

15. A forty-artifact changed-context school task

Transfer the method to a fictional school worksheet service processing forty artifacts. Twenty-seven are verified at their correct final destinations. Six path requests are rejected as outside the task root, three symlink conditions are blocked, two operations need cleanup review and two final saves remain externally uncertain. The counts add to 27 + 6 + 3 + 2 + 2 = 40.

Verified completion is 27 ÷ 40 = 67.5%, path refusals 15%, symlink refusals 7.5%, cleanup review 5% and unknown effects 5%. These categories help distinguish legitimate protective stops from unfinished user outcomes. The exercise does not model a real school’s production incident history.

Now the user changes the requested final filename but not the worksheet contents. This may be a permitted presentation change, but the application must still check the authorized destination and whether the new name collides with an existing file. A safe staged artifact need not be regenerated from scratch simply because the display name changed; a verified controlled replacement may be sufficient under policy.

Change the platform too: a converter that previously ran only on Linux must now support Windows. Named temporary-file reopen and deletion semantics differ, as Python’s documentation explains. Test the real platform behaviour, including open handles and cleanup after exceptions, rather than assume every file operation that passed on one system is universal.

Return to contents or continue with Symlink race testing belongs in an isolated sandbox.

16. Symlink race testing belongs in an isolated sandbox

A security regression suite can create a trusted scratch root, generate a temporary file and simulate a path component being replaced with a link before a subsequent open. The intended protected implementation should remain within the permitted root or refuse the operation. This tests the filesystem API and path-resolution enforcement without aiming at real private service files.

Test intermediate path components as well as the final filename. On supported Linux configurations, openat2 resolution flags can restrict symlinks across the path; merely using O_NOFOLLOW on a final component has different semantics. A developer should understand which layer the selected primitive actually protects and how mount points or network filesystems affect it.

Include positive controls: legitimate nested paths and normal conversions should succeed. A system that blocks all file writes may appear safe in denial-only tests but cannot deliver the worksheets users requested. Confirm that the result remains readable and that a second unrelated task cannot access the first task’s private temporary content.

After a fix, inspect actual resolved targets and ownership using trusted filesystem evidence. A model can help explain a failure path to developers, but its text cannot certify that no unsafe handle was opened. Preserve the controlled fixture and versioned environment for future regression.

Return to contents or continue with Do not assume all temporary bytes stay local.

17. Do not assume all temporary bytes stay local

A file-processing tool might upload a working copy to an external document converter, OCR provider or cloud storage service. The local temporary-file policy does not govern what that provider retains or where it processes data. A teacher’s private worksheet may require separate processor approval, residency, retention and access controls before that operation is allowed.

Keep a source-and-copy inventory. The original user file, extracted text, compressed download, model prompt fragment and final artifact can have different locations and lifetimes. A local cleanup claim should identify which copies were actually removed. Do not promise universal erasure because one TemporaryDirectory context exited.

An uploaded document may contain executable-looking text, malformed metadata or unexpected links. Local file safety controls the path, not the meaning of the bytes. The parser and AI prompt trust boundaries remain relevant after secure creation. A safe filesystem write should not elevate embedded source instructions into tool authority.

Use purpose-specific connections. An agent that only needs to render a PDF should not inherit a broad cloud publishing credential or unrestricted network capability. Every extra permission increases the consequence of a filesystem or parser defect. Restrict where intermediate files can flow and which service accounts may read them.

Return to contents or continue with Recovery after a final-state timeout.

18. Recovery after a final-state timeout

Some artifact services expose an API that returns a timeout after a write may have committed. The local filesystem may have successfully replaced the final path, or a cloud upload may have accepted the file while its acknowledgement was lost. The controller should inspect the original stable artifact identity and expected revision before creating another resource.

An atomic local rename does not automatically cover a subsequent upload or public link creation. The workflow should record a state for staging complete, local final file verified, remote upload accepted and destination link verified. This prevents the assistant from saying ‘ready to download’ when only an internal scratch file exists.

If one operation remains Unknown, preserve the authorized workspace and operation reference under a bounded recovery policy. Do not delete all evidence or publish a guessed sandbox link. If readback later confirms the file, attach its actual verified destination. A truthful uncertainty status is better than an invented success.

A proper failure-injection test can pause a worker just after an atomic replacement but before its response is returned. On resumption, the agent should discover the intended file already exists and avoid an unapproved overwrite. This is the same recovery principle that protects external email and WordPress publication, applied at a filesystem boundary.

Return to contents or continue with What students and parents can learn.

19. What students and parents can learn

Students can imagine two friends saving different Maths answers to the same shared filename at the same time. One may overwrite the other or leave a half-written file. Unique workspaces and a complete-then-replace step make the problem easier to understand. A final checksum or content check then answers a different question: was the correct worksheet actually saved?

Parents can distinguish a downloaded file from a final verified artifact. A browser showing progress or an AI model saying ‘I’ve prepared the PDF’ may describe an intermediate stage. An actual correctly named, readable file at the intended destination is the relevant outcome. Private student information should not be copied into broad scratch folders or debug logs without good reason.

The one-hundred-file table teaches conservation and categories: completed, blocked path, blocked symlink, cleanup pending and unknown. Correct security blocks can be successes for the permission boundary even when they do not produce the requested document. This encourages critical thinking about what a percentage actually measures.

An education service should design its files for legitimate study and review. Good defaults protect private learner records, keep tasks from overwriting one another and make finished artifacts reliably accessible to the intended recipient. More capable AI cannot eliminate the operating system’s real file and permission rules.

Return to contents or continue with A practical file-safety implementation checklist.

20. A practical file-safety implementation checklist

First identify authorized storage roots, task ownership, input file types and expected final outputs. Use secure temporary-file creation primitives and private directories appropriate to the supported platform. Keep source-generated filenames from controlling arbitrary filesystem paths. Decide where and under what conditions scratch content may be passed to a parser or external service.

Second, bound workspace resources and enforce path resolution at the actual operation. Where relevant, use descriptor-relative APIs and platform-supported symlink restrictions, and test them rather than trust a string check. Handle exceptions, cancellations and process termination without indiscriminate recursive deletion of shared directories.

Third, write final bytes to a controlled staging file, validate content, apply appropriate sync and atomic replacement or object-store conditional semantics, and independently verify the user’s intended destination. If the result is a public artifact, confirm the storage system actually provides a usable permitted link. Keep the full source of truth outside the model’s guesses.

The durable lesson is that a temporary file is an actual resource with owner, identity, location and lifetime. Reliable AI automation respects those properties from creation to cleanup, then reports only the final effects that the system can verify. Secure files are not merely well-named files: they are controlled capabilities supporting the user’s real task.

Return to contents.

Frequently asked questions

Why are predictable temporary filenames unsafe?

They can collide across tasks and, in shared writable namespaces, can be influenced by other processes before use.

Does Python tempfile guarantee secure cleanup after every crash?

No. Secure creation and normal context-manager cleanup have platform and termination limitations; orphan handling may still be needed.

What is a symlink race?

A pathname resolves differently between validation and use, potentially directing the actual file operation outside the intended location.

Does os.replace make a file durable through power failure?

Not by itself. It provides documented rename atomicity on supported systems; durability may require separate file and directory synchronization.

Can a securely created scratch file be published automatically?

No. Publication or overwrite needs current target identity, user permission, content verification and a confirmed final destination.

What should the assistant do when it cannot verify the final file?

Keep an honest unresolved status, preserve suitable operation identity and avoid inventing a link or blindly recreating the artifact.

Official platform documentation

Sources checked 24 October 2026. Python, Linux and other platforms provide different filesystem guarantees; the invented Cedar case counts and test files are not actual incidents or proof of universal protection.

• Python tempfile Documentation: Secure temporary creation, named files, directory cleanup and platform limitations.
• Python os Filesystem Operations: os.replace atomic rename, dir_fd and operating-system behavior.
• Linux openat2(2) Manual: Kernel path-resolution controls including RESOLVE_BENEATH and RESOLVE_NO_SYMLINKS.
• Linux open(2) Manual: File descriptor flags, O_EXCL and symbolic-link handling.
• Python shutil Documentation: Recursive cleanup considerations and symlink-attack resistance where available.
• OWASP File Upload Cheat Sheet: Storage, permission and filename boundaries for untrusted files.

Related specialist reading

Continue with Super Intelligence curriculum; File Ingestion; Download Resumption; Concurrent Document Edits; Agent Data Erasure; Data Export; Mathematics Tutorials. A finished artifact is defined by its permitted source, validated bytes and actual saved location.