wGrow
menu
Mounted Inputs Need Data Classification Labels
Compliance 12 September 2026 · 7 min

Mounted Inputs Need Data Classification Labels

By wGrow Project Team ·

Two Lines of Code In, An Architectural Overhaul Out

Mounting a file into an OpenAI Agents SDK sandbox is operationally trivial. Proving to an auditor what exactly entered that black box takes an architectural overhaul. That gap — trivial ingress, brutal accountability — is the whole problem this piece is about.

The Sandbox Is an Ephemeral DMZ

In the sandbox workspace setup we’ve tested in the OpenAI Agents SDK, defining a manifest and mounting local files or cloud objects into a workspace takes only a few lines of code. That’s the point of the design: give the agent a workspace, give the workspace data, let it iterate. From an engineering desk, that’s a genuine productivity win. From a compliance desk, it’s a new ingress point that nobody has classified yet.

Here’s the thing auditors actually check. Not whether an AI did the work — they don’t care about that. They care about two questions: what data went in, and what data came out. Everything in between — the reasoning, the tool calls, the token count — is largely secondary to the data-flow questions a data protection impact assessment actually has to answer: what personal data went in, who or what processed it, where it persisted, and what came out.

I’ve found it useful to treat the agent sandbox as what it functionally is: an ephemeral DMZ. A workspace that exists for the duration of a task, touches sensitive material, then disappears. In network security, nothing crosses a DMZ boundary without inspection. Same rule here — except the “packet” is a spreadsheet with someone’s NRIC sitting in column C, and the “firewall” is whatever your manifest schema decided to enforce. Or didn’t.

An unclassified file entering that DMZ is a liability the moment it’s mounted, not the moment something goes wrong with it. You can’t rely on the LLM to classify the data after ingestion — by the time the model reads the file to figure out what it contains, the file is already inside the boundary. If the file violates the boundary policy, the control failure already happened. Classification has to happen before the mount. Not after.

Cryptographic Hashes and the 2012 Precedent

Male IT professional analyzing system architecture at a modern workstation.

None of this is new, actually. The AI is a new kind of processor sitting on top of an old problem: you cannot control what happens to data you didn’t classify before it entered your system.

In 2012 we built a vendor management portal for a public-sector procurement desk. Every PDF a vendor uploaded — tender documents, financial statements, compliance certificates — had to clear two gates before our processing engine touched it. First, a SHA-256 hash generated at upload and stored against the vendor record, giving us an immutable fingerprint of exactly what was submitted and when. Second, a classification tag applied at the point of intake, not after review. Restricted-tender documents were tagged before a human or a script ever opened them. The hash gave us tamper evidence; the tag gave us handling rules. Neither was optional. Neither happened downstream of ingestion.

We ran the same discipline in 2018, on WaterDoctor’s diagnostic pipeline. Sensor telemetry coming off field units carried device IDs, GPS coordinates, and site metadata that could de-anonymize a client’s infrastructure if it leaked. Before that telemetry ever reached the analysis layer, it passed through a stripping-and-tagging step — metadata removed or hashed, a classification label attached to describe what remained. The analysis engine never saw an unlabeled file. It didn’t need to. The label was decided upstream, by a process that understood the data’s provenance, not by the algorithm about to consume it.

Fourteen years after the 2012 portal, the baseline is unchanged: an unclassified file is an untrusted file, and untrusted files don’t get mounted. Agent sandboxes inherit that baseline whether the SDK documentation mentions it or not.

Defining the Manifest Geometry

Mount Manifest
1 {
2 "file_id": "file-8xyz",
3 "metadata": {
4 "class": "Confidential", ← ①
5 "owner": "t.mo@wgrow",
6 "retention": "session_only" ← ②
7 }
8 }
9
  1. Mandatory tier enforcement
  2. Immediate destruction post-run

The fix is to inject classification at the manifest level, before the SDK’s mount sequence fires. Schema enforcement, not a comment field somebody forgets to fill in.

At minimum, a sandbox manifest needs four fields per mounted item: source origin (which bucket, which repo, which local path), classification tier (Public, Internal, Confidential, Restricted — pick a taxonomy and enforce it), retention policy (how long the sandbox instance and any derived artifacts may persist), and data owner (a named, accountable person — not a team distribution list). Leave any one of those four blank, and the mount request should fail. Not warn. Fail.

Cloud bucket mounts deserve the same scrutiny our 2012 portal gave PDF uploads. The temptation with the updated SDK is to mount a whole directory “just in case” the agent needs broader context mid-task. Resist it. Mount least-data fixtures — the exact object, or the exact byte range, that the manifest declares the agent needs for this run. Yes, that means more manifest entries and slower setup for exploratory work, and I won’t pretend that friction disappears. It’s the cost of running a classification model that still means something. A directory-level mount collapses the model, because now the manifest describes a folder that could contain anything, tagged with whatever the loosest file inside would justify. That’s not classification. That’s a shrug wearing a compliance hat.

Inherited Labels in Output Directories

Egress Flow
step 01
Classified Input
step 02
Agent Execution
step 03
Verify Inheritance
step 04
Export or Halt

Ingress control solves half the problem. The other half is egress: what leaves the sandbox has to carry the same restrictions as what went in.

The rule here is mechanical, not a judgment call: the output manifest inherits the highest restriction tier of every input file mounted during the session. Mount one Internal file and one Restricted file in the same session, and every artifact the agent produces — a summary, a generated report, a code snippet referencing the data — is Restricted by default. No averaging. No “mostly public” exception.

Before any generated artifact leaves the sandbox for permanent storage, it has to clear an export gate that checks the output manifest’s inherited tag against the destination’s access policy. That gate exists because you cannot assume the SDK’s default output handling enforces this inheritance for you — verify it explicitly, and where it doesn’t, write the export gate yourself. If an agent produces a document derived from Confidential input and the export step fails to carry that tag forward, the system halts the export and tears down the sandbox. No partial write. No “we’ll fix the label later.” A dropped sandbox costs a few seconds of compute to respin. An unlabeled Confidential document sitting in a shared bucket costs you a breach notification.

Replay States and Clearance Hazards

Technical illustration of a strict data filtration pipeline and secure gateway.

Replay Architecture
Request
Validation
Execution
developer
trigger trace
debug mocked state
system
verify manifest tag
redact payload

Any trace-replay tooling around agent runs is useful for debugging, and it opens a second exposure path most teams won’t see coming. Replaying a sandbox trace to see why an agent made a bad tool call means replaying whatever was mounted in that session — including the Restricted file the on-call engineer debugging the failure was never cleared to see.

The fix mirrors the mount-time check: replay mechanisms must read the manifest’s classification tags before rendering anything to a developer’s screen. If the developer’s clearance doesn’t match the manifest’s tag, the replay runs against mocked or redacted inputs instead. The agent’s step-logic — which tool it called, in what order, with what reasoning trace — stays intact for debugging. The payload doesn’t. This will occasionally cost you diagnostic fidelity; a masked value can hide the exact reason a tool call failed, and there’s no getting around that trade-off cleanly. But it’s a narrower problem than an uncleared engineer reading a Restricted file by accident. It’s the same principle behind handing a support engineer a masked customer record instead of the live one — agent tooling just makes it easier to forget, because the “record” is now buried in a JSON trace file three directories deep.

Stop framing autonomous agents purely as a reasoning problem. The enterprise adoption ceiling for agentic software won’t be set only by how well a model plans multi-step tasks — it’ll be set by whether the audit trail holds up when someone asks what data an agent touched last Tuesday. Classify at the perimeter. Enforce inheritance on the way out. Mask on replay. The AI can do its work. Just do it inside a box you can account for.