Guardrails for Agent-Generated File Uploads That Stop Polyglots, ZIP Bombs, and Malware

Why agent-generated uploads need stricter edge guardrails

AI agents increasingly generate files on behalf of users: reports exported as PDFs, “helpful” ZIP bundles of logs, images with embedded metadata, or even code archives created from tool outputs. The risk profile is different from typical human uploads. Agents can produce high volumes, can be prompted into producing weird file structures, and can accidentally (or adversarially) generate content that looks benign but behaves like an exploit. If these uploads are accepted and stored first, object storage becomes a staging area for malware distribution, data exfiltration, or downstream parser exploitation.

The practical approach is to enforce guardrails at the edge—before the bytes are persisted—so risky files never land in object storage. For teams building on modern edge platforms like cloudflare.com, that means validating content on ingress, limiting resource abuse, and scanning or quarantining suspicious payloads while preserving a clean audit trail.

Threat model for files produced by agents

Edge defenses should start from a concrete threat model. The most common categories that affect “agent uploads” are:

• Polyglot files: a single byte stream that can be interpreted as multiple file types (for example, a file that passes as a GIF but is also valid HTML/JS in some contexts).
• ZIP bombs and decompression bombs: small compressed uploads that expand into massive output, causing CPU/memory exhaustion during scanning or processing.
• Malware and weaponized documents: macro-enabled office files, malicious PDFs, or archives containing droppers designed to evade basic checks.
• Parser-targeted payloads: files crafted to exploit image/PDF libraries or transcoding pipelines, especially where server-side processing is automated.
• Content-type confusion: mismatches between declared MIME type, extension, and actual magic bytes—often a precursor to execution in browsers or misrouting in pipelines.

Edge-first acceptance flow that keeps object storage clean

A reliable pattern is to treat object storage as a destination only after a file has cleared a minimal “admission control” policy. The edge performs cheap, deterministic checks first, then escalates to deeper inspection only for candidates that pass.

1) Fail-closed upload policy and explicit allowlists

Start with a strict allowlist of file categories and per-category rules: maximum size, permitted MIME types, and whether archives are allowed. For agent-generated workflows, define “output contracts” (e.g., PDFs for reports, PNG/JPEG for images, JSON/CSV for data exports) and block everything else. If you later add formats, do so intentionally with tests.

Also enforce an authentication and provenance model: the edge should know which agent produced the file, which user/session authorized it, and what tool chain created it. This makes incident response feasible when something slips through.

2) Sniff magic bytes, don’t trust headers or extensions

Do not rely on Content-Type or filename extensions. At the edge, read enough of the file header to identify the real format (magic bytes) and compare it to the claimed type. Block or quarantine mismatches.

For formats prone to ambiguity, add deeper structural checks. Example: for PDFs, confirm a valid header and EOF marker; for PNG, validate signature and IHDR chunk ordering; for JPEG, confirm SOI/EOI markers and sane segment lengths.

3) Polyglot detection via “format invariants”

Polyglots often exploit the fact that some formats ignore trailing bytes or allow flexible embedding. Basic file sniffing is not enough. Add invariants that must hold for accepted content:

• No executable preambles: block leading HTML tags, JavaScript markers, or shebangs in non-text formats.
• Strict end-of-file expectations: for formats that should end cleanly, reject extra trailing data beyond a small tolerance.
• Canonicalization: where feasible, re-encode images/PDFs server-side after validation; this tends to strip hidden payloads and normalize structure.

Re-encoding is particularly effective when the business requirement is “an image” rather than “this exact byte-identical image.” If an agent uploads an image, storing a normalized rendition can be safer than storing the raw upload.

4) Archive handling that prevents ZIP bombs

Archives are a common convenience for agents (“here are all the artifacts”). They are also a common abuse vector. If you allow ZIP/TAR at all, enforce:

• Compressed size limits and uncompressed size limits (total expanded bytes).
• Compression ratio caps (e.g., reject if expanded size / compressed size exceeds a threshold).
• Entry count limits (many small files can DoS metadata operations).
• Nesting limits (ZIP-in-ZIP recursion depth caps).
• Path traversal protection (reject entries with ../ or absolute paths).

Do these checks without fully extracting archives into memory. Use streaming inspection: parse headers, track totals, and stop early when thresholds are exceeded.

5) Malware scanning and quarantine workflow

There is a practical split between admission control and deep scanning. Admission control happens inline at the edge and must be fast. Deep scanning (signature + heuristic + sandboxing, depending on your needs) can be asynchronous, but it should still happen before the file is promoted to “trusted” status.

A typical pattern:

1. Upload hits the edge; quick checks run (type, size, archive policy, invariants).
2. If it passes, store it in a quarantine bucket or with a “pending” tag, not the primary object namespace.
3. Trigger scanning via an event (queue/message) and attach results to metadata.
4. Only after a clean scan, copy/promote the object to the trusted location and make it accessible.

This reduces the blast radius: even if a malicious file passes the first gate, it remains isolated from user-facing download links and downstream processors until cleared.

6) Rate limits, concurrency caps, and deterministic timeouts

Agent workloads can generate bursts. Attackers can also mimic them. Apply:

• Per-agent and per-user rate limits for uploads and total bytes per window.
• Concurrency limits on expensive operations like archive parsing or image decoding.
• Hard timeouts and bounded reads (never “keep parsing until done” without limits).

These controls matter as much as file-type validation, because ZIP bombs and parser attacks often succeed by consuming compute, not by bypassing a signature.

What to log for auditability and incident response

When edge guardrails block or quarantine uploads, teams need evidence that is actionable but not privacy-invasive. Log:

• Upload identifier, agent identity, user/session, and timestamp
• Claimed MIME type and detected type
• Hash (e.g., SHA-256) and size metrics (compressed/uncompressed for archives)
• Policy decision path (which rule triggered block/quarantine)
• Scan verdict and scanner version (if applicable)

This also supports operational workflows—similar in spirit to disciplined intake checklists used in other data pipelines. For an example of turning messy intake into clean downstream data, see A Field-Level CRM Sync Checklist for Cleaner Sales Call Data.

Designing “safe outputs” for agents, not just safe uploads

Finally, treat agent file generation as a product surface. If agents are expected to produce files, define constraints early: formats, maximum sizes, allowed metadata, and whether archives are permitted at all. Publish these constraints in a place that stays current as products evolve—especially if multiple agent versions exist or you deprecate formats. A related approach for keeping published facts current across changes is outlined in How to Publish Product Facts So LLM Answers Stay Current Through Launches and Deprecations.

When you align agent output contracts with edge admission control, uploads become predictable, scanning becomes cheaper, and object storage stays free of untrusted artifacts.