Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can I Bring My Own Agent Harness to a Secure Sandbox?

Yes, when the sandbox is built to run your harness as untrusted code and keep the credential outside it: Docker's sandbox documentation keeps credential values out of the VM, and E2B's configuration holds only a reference to the credential. Check where the credential sits and what your harness receives before you install it.

A credential reference travels from a browser record through a bounded route to a separate API destination.

For a buyer evaluating a secure sandbox, the agent harness is the program that runs the loop: the command line, the model client, the tool calls and the git commands. Putting one inside a secure sandbox raises two questions that a feature list answers separately. The first is whether the sandbox will run a program it did not write, with its own dependencies, its own model provider and its own list of tools. The second is what that program is handed once it starts: a credential it can read, or a reference that resolves somewhere it cannot reach. Which of those a design implements decides whether the sandbox is a boundary or a staging area. That split sets the order of this page. The scope comes first, because a sandbox and a browser control cover different surfaces, and a buyer who treats them as substitutes ends up governing neither. The credential designs that Docker, NVIDIA, 1Password, E2B and Infisical document come next, followed by what a harness can still do after the sandbox has admitted it. The page closes with the test for harness lock-in, run as one substitution: Claude Code, Codex CLI and Aider on the same task, in the same environment, against one policy.

Key findings

  • Docker's sandbox documentation states that "every sandbox runs inside a lightweight microVM with its own Linux kernel" and that "credential values are never stored inside the VM," the two properties that let a sandbox host a program it did not write (Docker, Isolation, 2026).
  • A study of prompt injection against agentic coding editors found that "attack success rates can reach as high as 84% for executing malicious commands," the exposure a harness carries into any sandbox that hosts it (Liu et al., 2026).
  • GitGuardian counted about 29 million credentials leaked in public repositories in 2025 and an 81% year-over-year rise in AI-service leaks, and its CEO names the pressure behind the question: "AI agents need local credentials to connect across systems" (GitGuardian, 2026).
  • Tokens replace the values a policy selects before any model reads a rendered page, so the model works on placeholders such as REPO_001 and real values resolve only at the destination a named person approved (What Is Render-Layer Tokenization?).
  • Meta's own agent design uses surrogate tokens the agent does not see and a separate component that approves every network egress, the ordering that makes a credential useless to a hijacked loop, though Meta documents it for its agent and not for a harness a customer installs (What Would an Enterprise Version of Meta Muse Need?).

What does a secure sandbox have to provide for a harness you installed?

Three things have to be in place before a harness you installed counts as portable, and none of them is the agent product itself. The sandbox needs an execution boundary that accepts a program it did not write, an egress path narrow enough to name, and a credential interface that does not hand the process a value it can print.

The scope of the control class this page tests comes first, because a sandbox and a browser control are not substitutes. A governed browser environment covers what the agent reads and does on a rendered page: dashboards, consoles, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A harness spends its working day in the terminal, so the browser control governs the pages the loop opens and not the loop itself.

Portability is a question about substitution. If the controls have to be rebuilt when the harness changes, the sandbox is a host rather than an environment. Model releases set the pace: Anthropic released Claude Opus 5.5 on September 22 at $4 and $20 per million tokens and Sonnet 5.5 on September 28 at $2 and $10 (Can AI Models Change Without Changing Their Controls?), and a harness swap is a smaller change than that. The record for this page is one substitution: Claude Code, Codex CLI and Aider in the same CodeCell, opening the same repository page against one credential policy.

Where does the credential sit when the harness is one you installed?

Docker's credential page describes the mechanism and names the weaker setting beside it: "An HTTP/HTTPS proxy on your host intercepts outbound requests from the sandbox" and "overwrites the auth header before forwarding," so "the real credential stays on the host when proxy management is active; the sandbox sees only a sentinel value" (Docker, Manage, 2026).

E2B documents the same shape with a reference in place of a sentinel: "Your sandbox configuration contains only a reference to the secret," and "the egress proxy injects the real value into matching outbound HTTPS requests outside the sandbox" (E2B, 2026).

Infisical states the principle without hedging: "In short, the agent should not be trusted with direct access to any secrets," and its post separates a proxy that forwards encrypted traffic opaquely from one that terminates TLS (Infisical, 2026). The volume explains the caution: 28,649,024 new credentials were exposed in public commits across 2025, with 24,008 unique credentials in MCP configuration files (How Do You Let an AI Agent Manage API Keys Without Reading Them?). AWS's advice against creating access keys for the root user is the same rule one rung up, and it applies to a harness with no more judgment than the person who installed it (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?).

Where the credential sits What the documentation describes What the harness still holds
Host proxy Docker: outbound requests intercepted, auth header overwritten, a sentinel inside the sandbox The sentinel, and anything it writes into the request
Passthrough kit Docker: a kit set to passthrough sends the real token response into the sandbox, which reduces isolation The real token
Sandbox reference E2B: configuration holds a reference, and the egress proxy injects the value outside The reference, and whatever the response returns
Gateway placeholder OpenShell: an opaque placeholder replaced only for an approved host The placeholder, and the approved response
Environment variable Any code in the sandbox can read it The real value

What do the vendors themselves say?

NVIDIA's security guidance for OpenShell starts with the boundary and then places the credential outside it: "OpenShell enforces sandbox security across four layers: network, filesystem, process, and provider credentials," and inside that boundary "the agent receives an opaque placeholder, not the real API key or access token" (NVIDIA, OpenShell Security, 2026). The same page is direct about the cost of an allowlist: "Every outbound connection from the sandbox goes through the CONNECT proxy" and "Each allowed endpoint is a potential data exfiltration path" (NVIDIA, OpenShell Security, 2026).

1Password's post on the integration describes what the agent sees and when a real value appears: "Inside the sandbox, the agent sees placeholders rather than real credentials, including a placeholder for its model key," and "OpenShell Gateway replaces a placeholder with the real value only when the agent sends a request to an approved host" (1Password, 2026). The page describes no independent test or audit of the integration.

Read together, the pages describe a boundary and a credential path and leave the harness question where they found it. Which harnesses run inside is not described in the pages reviewed; Docker documents a microVM and a host proxy, E2B documents a reference and an egress proxy, and NVIDIA documents four layers and a placeholder, and none of the three makes harness support a documented feature. That absence is what a buyer is testing, and it is not a finding that any of them refuses a harness.

Dimension Vendor, per its documentation What a buyer should verify
What the model receives OpenShell: an opaque placeholder, not the real API key or access token Whether every value on a page is covered, not only credentials
Egress OpenShell: every outbound connection through the CONNECT proxy, with each allowed endpoint a potential exfiltration path Who adds an endpoint, and what a harness may send to it
Where the value lives 1Password: stored by reference, resolved by the gateway for an approved host Whether the store belongs to the customer or the vendor
Harness support Not a documented feature on the pages reviewed Run three harnesses against one policy and compare the records

What can the harness do once the sandbox has let it in?

The sandbox settles what the process may reach, not what the loop does with what it reached. Agent Security Bench reports "critical vulnerabilities in different stages of agent operation," with "but limited effectiveness shown in current defenses" (Zhang et al., 2025). Its abstract does not say which defense performed best or by how much, so read the result as a direction and not a ranking.

Authorization is the other half, and it is not a sandbox setting. Arcade's post frames the question every agent system has to answer, "Can this agent, acting for this user, perform this action on this resource?", and gives the everyday case: "Even if a user can delete files in Drive, their agent should only get read access unless deletion is explicitly needed" (Arcade, 2025). A network allowlist answers whether the process may reach a host. It does not answer whether this harness, for this person, may take this action, and no page reviewed puts that decision inside the sandbox.

"The tether is a description of authority, not of capability," and a tethered agent goes anywhere its supervisor could go (What Is a Tethered Agent?). A harness you installed inherits the authority of whatever identity you gave it, while its capability is the tool list you allow it to call. A sandbox that narrows capability and leaves authority at the person's full reach has narrowed the machine, not the mandate.

What is harness lock-in, and how do you test for it?

Lock-in in a sandbox pitch has four common shapes. The sandbox ships its own agent, and the harness you brought is supported as a legacy path or not at all. The credential interface speaks one harness's configuration format, so a second harness needs a second integration. Approvals and the record are produced for the vendor's agent, so the accounting stops at the edge of the harness the vendor knows. Egress rules enumerate the hosts one harness calls, so a different harness is either blocked or granted more than it needs.

The test is a substitution, run on one task. Put Claude Code, Codex CLI and Aider in the same CodeCell and give each the same job: open a repository settings page, read the token list, request a branch protection change. Compare what each model received, where the real value was released, and whose name is on the approval. If any answer changes with the harness, the control sits in the harness and the environment only hosts it.

Two questions sit beside portability. Google's guidance for Workspace administrators says the super admin account should be used only when needed, a rule written for people that a harness does not improve on (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?). Coverage is the other: a Cloud Security Alliance note reports that eight in ten employees use AI tools their organizations did not approve, so a control inside one approved harness governs a minority of runs (How Do You Keep Data Access Policies Consistent Across AI Tools?).

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values a policy selects are replaced with consistent tokens for the whole run, so a harness works on placeholders such as REPO_001. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, and every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

The mechanisms reviewed above sit inside the sandbox, the proxy or the harness, and each of them has to be configured again when the harness changes. A control at the render step does not: the policy names values, not tools, so the same page renders the same tokens whether the loop is run by Claude Code, Codex CLI, Aider or a program the team wrote last week.

Its scope is the rendered page. The class does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so a token written into a shell environment stays with the sandbox and the credential store configured for it. The two are complements: the sandbox decides what the harness may reach, and the class decides what the harness is shown.

The class is testable without naming a product. Open one page in one run, ask which values arrived as placeholders, ask whether the same value carried the same placeholder on a second page, ask where the real value was released, and ask whose name is on the approval. A design that answers the four questions has the property this page's question turns on.

Methodology and limitations

This page rests on two research preprints, one on prompt injection against agentic coding editors and one benchmarking attacks and defenses in LLM agents, vendor documentation from Docker, NVIDIA, 1Password and E2B, two vendor credential designs from Arcade and Infisical, one industry report from GitGuardian as published by CIO Dive, and existing RedactSure research pages on tokenization, authority and credential custody. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and the GitGuardian figures are cited as reported, not measured here.

RedactSure did not test any named sandbox hands-on and built no environment for this page. The phrase "not described in the pages reviewed" means the recorded facts for a page do not cover the point; it is not a finding that a vendor refuses a harness. Vendor features change, and the page carries its date, so a release after that date should be treated as unreviewed until the substitution test is run again. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, three harnesses in one environment, and not an organization.

Determinations about whether a sandbox, a proxy or a harness meets a contractual, regulatory or internal control requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a run of the organization's own harness on one task the team can describe, repeated after each harness or vendor release. The page is a reading of public documentation and recorded research, not an assessment of any deployment.

What the record shows

The record answers the title narrowly. A sandbox can host a harness it did not write, and the designs reviewed keep the credential out of the process by a host proxy, by a reference resolved outside the sandbox, or by a gateway that substitutes a placeholder. None of that decides what the harness reads on the pages it opens, and none of it survives a change of harness by itself: the proxy still needs configuring, and the approval still needs a name. RedactSure's environment is built at the render step, which is where the portability question lands. Comparing harnesses is the practical test: run one agent and one task under two different harnesses, and for each value on the page ask whether the model received the value or a token, where the value was released, and whose name is on the approval.

Frequently asked questions

Can I bring my own agent harness to a secure sandbox?

Yes, when the design is built for it. Docker puts each sandbox in a microVM with its own kernel and keeps credential values out of the VM, E2B holds only a reference to the credential in its configuration and injects the value outside the sandbox, and OpenShell gives the agent an opaque placeholder. What none of those pages documents is a harness it will not run, so ask which harnesses the vendor supports and what a second one needs on its first day.

Does the sandbox protect the credential my harness uses?

To the extent of its credential path. A host proxy that overwrites an auth header keeps the real value on the host, and a configuration that holds a reference keeps it outside the sandbox. The proxy design has an opt-out: a passthrough kit can send the real token into the sandbox and reduce isolation. Read the setting rather than the product page, and check whether the harness can print whatever it receives, because that is what a compromise would carry out.

What does harness lock-in look like in a sandbox pitch?

Four shapes are common. The sandbox ships its own agent and treats yours as unsupported. The credential interface is built for one harness's configuration format. Approvals and the audit record exist only for the vendor's agent. Or the egress rules list the hosts one harness calls, so a second one is blocked or over-granted. Each shape is testable in an afternoon: install a second harness on the same task and compare the two records side by side.

Is an allowlist enough to stop a hijacked harness from sending data out?

No. An allowlist narrows where a request may go and says nothing about what the request carries. NVIDIA's guidance calls each allowed endpoint a potential data exfiltration path, and the endpoint a harness legitimately uses is often the one an injection needs. The useful question is what the harness read before it sent, which is settled earlier, at the page that rendered the value and at the approval that released it.

Do I need a browser control if my harness runs in a sandbox?

They cover different surfaces. A sandbox governs the process: what it may execute, which files it mounts and which hosts it reaches. A browser control governs the rendered page: what the model is shown on a dashboard, a console or a settings page. A developer harness needs both, because the loop lives in the terminal and the pages it opens sit outside the sandbox's question, so buying one and expecting the other leaves a gap.

What should a team check before installing a harness in a sandbox?

Four things, in this order. Which process holds the credential, and whether the harness can reach it. Which hosts the egress policy allows, and who may add one. What the harness receives when it opens a settings page, and whether the values arrive as tokens. What record shows, after the run, which values the model saw and whose name is on the approval. A design that answers all four in writing can be tested against a second harness, on the same task, in the same week.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Keeps a Sandbox Harness-Agnostic

The designs reviewed above keep a credential out of a team's own harness, but leave open what it reads on pages and whether controls survive the next harness.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: each harness opens the repository settings page and reads the deploy key into its context, and each transcript carries it out. Inside: the page renders REPO_001 for Claude Code, Codex CLI and Aider alike, and a named person approves the branch protection change that releases the real value.

RedactSure is deploying now with enterprise and government customers. Coding-editor injection reached 84% success for executing malicious commands.

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

Keeping your own harness matters when your team has already built around it. Bring the harness you use today and see, with test values, what the model reads on a repository settings page inside the governed environment. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.