Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Is a CodeCell?

A CodeCell is a sandboxed execution environment on a machine you choose; it runs your own agent harness with access to only the services one task needs, and the credential stays outside it in a private adapter. Check which process holds the key before you run anything consequential inside one.

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

The term names a component in a developer workspace, not a product category. A CodeCell is the box the agent works in: an execution environment on a machine the team chooses, a laptop, a server or an account in a cloud, that runs the team's own agent harness and the tools that harness calls. Its access is narrowed to the services one task needs, and the credential that opens those services is kept outside the box in a private adapter, so the process doing the work is not the process holding the key. That last property decides whether the definition means anything: a sandbox that isolates a command and then exports the token into the command's environment has moved the exposure, not removed it, and several of the designs reviewed below show that pattern. A sandbox and a credential store are each half of the design, and the term only means something when both halves are named. This page states the scope of the term, places the credential, reads what vendors document for the adjacent mechanisms, sets out what isolation covers and what a hijacked run can still reach, and ends with the control class that makes the definition testable. The running example is a CodeCell on a laptop running Claude Code, working one repository.

Key findings

  • A CodeCell is a sandboxed execution environment, on a machine the team chooses, that runs its own agent harness; its defining property is that the credential stays outside it in a private adapter (What Is Least Exposure?).
  • Tokens are issued before any model reads a rendered page, and real values resolve only at the destination a named person approved, so a run works on placeholders it cannot spend (What Is Render-Layer Tokenization?).
  • 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," isolation a cell inherits and custody it does not (Docker, 2026).
  • Anthropic's Claude Code documentation describes a sandbox that can "sandbox bash commands with filesystem and network isolation, reducing permission prompts while maintaining security," but adds that "the boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can" (Anthropic, 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," which is why a cell bounds what a run can execute (Liu et al., 2026).
  • GitGuardian's test of Copilot reported that "Copilot generates 2702/900 = 3.0 valid secrets for one prompt on average," a measure of how readily a model repeats a value it has read (GitGuardian, 2025).

What does a CodeCell contain, and what does it leave to other controls?

A CodeCell has four parts, and the definition is easier to hold when they are named. The harness is the agent product the team already runs, Claude Code in the example on this page. The workspace is the tree of files that harness reads and edits. The execution layer is the process boundary, a virtual machine, a container or a local sandbox that keeps the harness off the host. The fourth part sits outside: a private adapter that holds the credential and answers the harness's requests for a service.

The first three make a cell a cell. The fourth makes it a CodeCell rather than a sandbox with a token in its environment. A cell that runs the harness and mounts the repository, and then hands the process a live token, is a well-isolated agent holding the key: the isolation does its job and the custody question is unanswered.

The scope question follows from the fourth part. A CodeCell governs the process: what it can execute, which files it can mount and which hosts it can reach. It is not a browser control. A governed browser environment covers what the agent reads and does on a rendered page, and it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. The two surfaces are complements: the cell bounds the shell, and the browser control bounds the page the harness opens. In the laptop example the cell contains the working tree, the package manager and the test runner; the browser the harness drives is a separate surface with its own policy.

Tokenization applies that custody idea to a stored value: RedactSure vs Skyflow: 2026 Comparison & Alternative describes a token that carries no exploitable value on its own, with the original held apart from the operational store.

Where does the credential live when the agent works?

The term answers a location: the credential sits in a private adapter outside the cell. The harness asks the adapter for a service call, the adapter authenticates, and the value never becomes an environment variable the harness prints, a file it opens or a string it pastes into a page.

HashiCorp's Vault tutorial states that "token lifetime is reduced from days or weeks to minutes" and that the agent receives "a token that is read-only, repo-only, scoped to a single secret, and short-lived" (HashiCorp, 2026). The same tutorial's wrapper script "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent," which puts the raw token in the agent's environment; the page does not say whether the agent can read it (HashiCorp, 2026).

AWS's AssumeRole reference "returns a set of temporary security credentials that you can use to access AWS resources," with permissions that are "the intersection of the role's identity-based policy and the session policies" (AWS, 2026). The session "can range from 900 seconds (15 minutes) up to the maximum session duration set for the role," and role chaining caps it at one hour (AWS, 2026).

Microsoft's page states that "managed identities eliminate the need for developers to manage these credentials" and that "this token acquisition doesn't require any secrets," a design for Azure, not a laptop harness (Microsoft, 2026).

The volume is large: "28,649,024 new secrets exposed in public GitHub commits across 2025" (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

What do the vendors themselves say?

The vendor pages reviewed describe the execution boundary and the credential mechanism separately, and none describes a cell that joins them. That separation is the finding.

Docker's isolation layers page states that "the agent has no path to your host Docker daemon" and that "every sandbox runs inside a lightweight microVM with its own Linux kernel"; how a credential reaches a process inside that VM is not described in the pages reviewed (Docker, 2026).

For its hosted cloud sessions Anthropic's page adds that "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM" and that "the VM holds a short-lived credential scoped to that session," then closes with "no system is completely immune to all attacks" (Anthropic, 2026). The same page describes the local sandbox as bounded by a permission prompt, so the custody it documents for its own hosted sessions is not the custody a laptop run gets by default.

The Model Context Protocol's security guidance states that "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server," a rule for server implementers that says nothing about the credential a harness holds (Model Context Protocol, 2026).

Vendor page What it documents The limit that matters here
Docker, Isolation layers A microVM per sandbox with its own kernel, and no path to the host daemon Isolation of the process; the interface to a credential is not described
Anthropic, Security A Bash sandbox bounded by a permission prompt, and hosted sessions that keep GitHub credentials out of the VM The hosted custody applies to hosted sessions; an approved command keeps the account's reach
HashiCorp, Secure agent permissions with Vault A read-only, repo-only, single-credential token that lives minutes The wrapper exports the token into the agent's environment
AWS, AssumeRole Temporary credentials intersected with a session policy, from 15 minutes to the role maximum The process still holds the session credentials while it runs
Microsoft, Managed identities A token acquired without a credential Built for Azure workloads, not for a harness on a laptop
Model Context Protocol, Security Best Practices A token rule for MCP servers, and guidance on scope A server-side rule; the harness's own credential is outside it

Read together, the pages cover the two halves and leave the join undone. Isolation is documented, scoping is documented, and a credential that needs no stored value is documented. The component that holds the key outside the cell and answers the harness through an interface it cannot read is the part a buyer has to ask about, because none of these pages describes it.

What does isolation inside a CodeCell actually cover?

An execution layer is judged by four boundaries: the kernel the process shares, the filesystem it can mount, the hosts it can reach and the identity it runs as. Docker's microVM design puts the first three inside the sandbox and keeps the process off the host, which is why it is a useful reference model for a cell. The page documents those boundaries and says nothing about what the harness inside them reads.

Two routes are easy to leave open. The Model Context Protocol's guidance warns that "MCP servers run with the same privileges as the client" and that "cloud metadata endpoints often expose IAM credentials, API keys, and other secrets," two routes a cell has to close by configuration (Model Context Protocol, 2026). A cell that blocks egress but leaves the metadata endpoint reachable has closed the front door and left the side gate.

Narrowing authority is the other half. A privilege-control system for agents, Progent, "significantly reduces attack success rates while maintaining high utility" in the evaluation its authors report, which is the argument for narrowing a cell to the services one task needs (Shi et al., 2026). The abstract gives no numbers, so the direction is the claim and not its size.

What isolation does not cover is information. A cell can keep the process off the host, hold the network to an allowlist and still let the harness read every value a page renders; the model receives what the harness receives, and the execution boundary has no opinion about it. The advice in Is It Safe to Let an AI Agent Set Up Your Cloud Environment? against root access keys makes the same point about authority: it rules out the simplest durable credential without changing what the agent reads while it uses a scoped one.

That is why the definition has two halves.

What can a hijacked run still reach from inside a CodeCell?

A hijacked run rarely needs to escape. It needs the harness to do something ordinary with a value it was allowed to see. A dependency README or an issue comment can carry instructions that send the agent to a settings page and then to a request, and the cell permits both when the policy does.

The tether describes authority rather than capability, and a run goes where its supervisor could go (What Is a Tethered Agent?). If the supervisor can open the repository settings page and read the deploy key, the tether reaches it too.

The measured record is the reason to plan for a run that is hijacked successfully. Anthropic's page is candid that its protections "significantly reduce risk" while "no system is completely immune to all attacks" (Anthropic, 2026). A boundary that fails once in a thousand runs fails daily at the volume an engineering organization generates, so the question is what the run collects when it succeeds.

Part of the answer sits on rendered pages. An environmental injection attack on generalist web agents reached an attack success rate of up to 70 percent in stealing users' specific personal information, as Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity? records. Meta's own agent design uses surrogate tokens the agent does not see and a separate component that approves every network egress, the same shape as an adapter outside a cell (What Would an Enterprise Version of Meta Muse Need?).

The exposure has two parts; the definition has one boundary. The cell decides what the run can do. It does not decide what the run is shown, and a value the harness read on a rendered page is in the context whether or not the process could write it to disk.

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 chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders such as TOKEN_001, REPO_001 or ACCT_002 and never holds the values the person sees. 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 a submission that creates, changes or confirms a record is one. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this page's question the control class supplies the half a cell cannot. A cell decides what the harness may execute and which hosts it may reach; the governed environment decides which values the harness receives when it opens a page. Put together, the run works with REPO_001, the adapter holds the deploy key, and the real key is written on a named person's approval. The approval is not a review of the output after the fact; it is the condition under which the value leaves the adapter.

Its scope is the rendered page. The class governs the page and not the terminal, the IDE, the local filesystem, direct API calls or MCP, and that limit is what makes the pairing necessary rather than redundant: a token placed in a shell environment is inside the cell and outside this class, while a token displayed on a settings page is the case the class exists for.

The class is testable without naming a product. Open one page in one run, ask which values arrived as placeholders, ask the same value on a second page for the same placeholder, and ask where the real value was released and who approved the release. A design that answers those four questions has the property the definition of a CodeCell depends on.

Methodology and limitations

This page rests on two research preprints on prompt injection and privilege control, vendor documentation from Anthropic, HashiCorp, AWS, Docker and Microsoft, the Model Context Protocol's security guidance, one vendor research post from GitGuardian, and existing RedactSure research pages on render-layer tokenization and least exposure. The term is treated as a component name in developer-workspace design, and the definition is tested against the documented mechanisms rather than restated from one vendor's description. 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 figures from research posts are cited as reported, not as independently measured.

RedactSure did not test any of the named products hands-on, and no sandbox was built for this page. The phrase "not described in the pages reviewed" means the recorded facts for that page do not cover the point; it is not a finding that a vendor does not do it. Vendor features change, the page carries its date, and a release after that date should be treated as unreviewed until the definition is checked against it again. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a CodeCell on a laptop running Claude Code, and not an organization.

Determinations about whether a particular deployment 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 test of the organization's own harness inside its own cell, on a task and a service the team can describe.

What the record shows

Read together, the record supports a narrow conclusion. Docker's microVM, Anthropic's permission-prompt boundary, Vault's short-lived scoped token, AWS's session policies and Microsoft's credential-free identity each narrow what a run can do or how long a value stays useful. None of them changes what the harness is shown when it opens a settings page, and the definition of a CodeCell turns on that second question: the cell is where the agent works, the adapter is where the key stays, and the boundary between them is the one to test. The record explains the urgency: a coding-editor injection study reports command execution success as high as 84 percent, and GitGuardian counts 3.0 valid credentials per prompt. A practical check follows from this: name one agent and one task, run it in the cell, and ask of every value it touched whether the process held the value or a placeholder.

Frequently asked questions

What is a CodeCell?

A CodeCell is a sandboxed execution environment that runs an agent harness on a machine the team picks, with access narrowed to the services one task needs. The definition includes a second component: a private adapter outside the cell that holds the credential and makes the service call, so the process doing the work never holds the key. A sandbox alone is not a CodeCell, because the credential can still sit in the process environment. Locate the key first, then decide whether the isolation matters.

What runs inside a CodeCell, and what stays outside?

Inside sit the harness, the model client, the working tree, the tools the harness calls and the execution layer that keeps them off the host. Outside sit the private adapter, the credential it holds and the service that credential opens. The dividing line is the process boundary: anything the harness can print, write or paste into a page is inside and reachable by a hijacked run. An adapter is built so the harness can request an action without ever receiving the value it spends.

Is a CodeCell the same thing as a Docker container?

No. A container or a microVM is one way to build the execution layer, and it settles isolation. The CodeCell definition adds two requirements the container does not settle: access limited to the services one task needs, and the credential held outside the cell rather than injected into it. A container with a token in its environment meets the isolation requirement and not the custody one. The test is which process holds the key, not which kernel the command runs on.

Does a CodeCell keep my credentials safe on its own?

Only if the credential is actually outside it. A cell that isolates the process and then exports a token into its environment has isolated the command, not the credential, which is the pattern Vault's wrapper script shows. Scoping a token to one credential for minutes reduces what a hijacked run can do with it. Holding it in an adapter that answers requests removes it from the run's reach. Ask which of those two a design implements before treating a cell as custody.

Can I bring my own agent harness to a CodeCell?

Bringing your own harness is part of the definition: the cell runs the agent product the team already uses rather than the sandbox vendor's own agent. The practical checks are whether the harness reaches the adapter through a documented interface, whether its tool calls are logged, and whether its transcripts and caches sit on a volume destroyed with the cell. A harness that writes a token into its own logs has moved the credential back inside, whatever the isolation layer claims.

What should a team check before approving a CodeCell?

Four things. Which process holds the credential, and whether the harness can read it. Which services the cell can reach, and whether the network policy defaults to deny. What happens to the workspace and the transcript when the run ends. And what record shows, after the fact, which values the model received and which action a named person approved. A design that answers all four in writing is testable; one that answers only the isolation question is a sandbox.

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 Working Credential Outside the Agent's Reach

A cell bounds the process and the credential designs reviewed bound a value's lifetime and scope, but neither decides what the harness is shown on a settings page.

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

Before: on a repository settings page, the harness reads the deploy key into its context, and it travels with the run. Inside: the page renders REPO_001, and the real key is written to the repository on a named person's approval.

RedactSure is deploying now with enterprise and government customers. The coding-editor study reports command-injection success as high as 84 percent.

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

See it on your own workflow

A CodeCell runs the agent on a machine you choose while the real credential stays out of every page the model reads. Bring a repository task your team delegates and see, with test values, which values the model receives. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.