# Before an AI Agent Unpacks a File, Check Where It Writes > Source: > Published: 2026-09-07 00:00:00+00:00 Before an AI agent unpacks an archive, treat its contents as proposed writes to the filesystem. Inspect the destination, entry types, overwrite behavior and resource limits. Use an isolated intake location, then move accepted files into the project after review. This is a practical acceptance decision for teams asking agents to import assets, documents or source bundles. It does not require the owner to understand archive internals. The agent should be able to explain what will be written, where it will land and what the extraction process is permitted to replace. 1. 01Choose a separate destination.A fresh intake directory makes proposed writes easier to inspect and contain. 2. 02Inspect more than filenames.Links, duplicate entries and filesystem naming rules can change where content lands. 3. 03Enforce a bounded import.File counts, expanded size and runtime limits need controls outside the prompt. ## 01 — Make the archive intake decision explicitMake the archive intake decision explicit An archive member is an entry inside the bundle. Some members represent regular files, while others can represent directories or links. A symbolic link redirects a path to another location. The table gives six intake questions; the extractor and operating environment must enforce the resulting policy. | Original editorial decision aid; examples describe proposed checks, not measured outcomes. Reviewed September 7, 2026. | | | |---|---|---| | Intake question | Evidence to inspect | Decision rule | |---|---|---| | Destination | Where will each member resolve? | Reject writes outside the authorized intake boundary. | | Entry type | Are regular files, directories and links all expected? | Allow only the types the task actually needs. | | Existing content | Can extraction replace something already present? | Prefer fresh intake; require a deliberate rule for promotion or replacement. | | Name collisions | Can members map to the same target? | Resolve ambiguity before accepting one file over another. | | Resource budget | How much expanded data and work are allowed? | Enforce limits in the extraction environment, not only the prompt. | | Completion evidence | Did extraction finish, and which members were accepted? | Keep partial intake separate and record omissions or rejection reasons. | ## 02 — What the archive documentation warns aboutWhat the archive documentation warns about [Python’s tarfile guidance](https://docs.python.org/3/library/tarfile.html#hints-for-further-verification) says extraction filters do not prevent every dangerous behavior, including resource exhaustion. It recommends additional checks and a new temporary directory. Those warnings support treating extraction as a bounded operation even when a filter is enabled. [Python’s zipfile documentation](https://docs.python.org/3/library/zipfile.html#decompression-pitfalls) describes decompression pitfalls, including resource limits and overwriting files when the same archive is extracted again. That is specific library guidance. Do not assume every archive format or tool has the same defaults. This article derives an intake review from those sources. It does not certify an extractor or publish a universal sanitization recipe. Inspect the actual library, its installed version and the controls the workflow uses. The source documentation includes version-dependent behavior; no release-version recommendation is needed for the decision here. ## 03 — Keep the import separate from the working projectKeep the import separate from the working project Consider a hypothetical asset bundle supplied for a website update. The request is to inspect images and copy selected assets into the project. Extracting the entire bundle directly over the working tree grants more write authority than that task needs. A separate intake directory lets the agent compare the proposed files with the intended destinations first. A filename that looks harmless in a list is not the complete check. Resolve the destination using the extractor’s actual rules and account for links and filesystem behavior. The policy should reject writes that escape the intended boundary. A prompt saying “stay in this folder” is a task instruction, not a filesystem enforcement mechanism. Our [agent sandbox reference](/blog/agent-runtime-sandbox-matrix) covers the broader runtime boundary. Archive inspection is an additional input check: a sandbox can limit reach while still allowing an import to overwrite valuable files inside the permitted workspace. ## 04 — Separate file acceptance from executionSeparate file acceptance from execution Opening a bundle is not authorization to run its scripts or install its dependencies. For an asset task, define the accepted content types and move only the files needed. If the task requires code inspection, keep extraction and execution as distinct steps with their own scope. Review naming collisions before copying into the project. Different filenames can map to the same destination under the target filesystem’s rules. A later entry can also compete with an earlier one. The owner’s relevant decision is which content should be retained, not which one the extraction order happened to leave behind. Keep the original bundle available for reference without repeatedly unpacking it over the same output. Record the accepted members and any omissions. The [file-output acceptance reference](/blog/ai-file-output-acceptance-reference) helps specify what the resulting accepted files must contain. ## 05 — Stop and report partial extraction clearlyStop and report partial extraction clearly Give the import explicit bounds appropriate to the task: allowed destination, expected member types, maximum expanded data and a stopping condition. Enforce resource limits through the runtime or operating environment. A small compressed download can require much more space after expansion, so the download’s size alone is insufficient. If extraction stops, label the intake incomplete. Inspect the partial output before any accepted files are promoted into the project. Do not treat the presence of a few expected assets as proof that the complete bundle was processed successfully. Use the [test-data reference](/blog/ai-agent-test-data-reference) to verify benign boundary cases in a disposable environment: duplicate destinations, unexpected entry types and an intentionally small size allowance. These checks demonstrate the configured behavior for those cases; they do not prove every possible archive is safe. Keep the outcome and unresolved checks in the intake record. ## 06 — DecisionWhat to do next ### Approve a bounded import, then accept the files. Inspect where the archive writes and what it can replace. Keep extraction separate from execution and promotion, enforce the chosen limits and report partial results honestly. For implementation support, explore our [AI transformation services](/services/ai-transformation).