Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Should I Look For in a Secure Workspace for AI Coding Agents?
Six things decide it: the agent never holds the credential, what the agent creates is captured, each grant names a service, resource, operation and lifetime, the developer's key signs it, the browser and the terminal are both covered, and the record shows references. Score a vendor on all six before it touches a repository.
An engineering team gives a coding agent a repository, a ticket and a week of work. By Wednesday it has opened a console, created a service account, copied a deploy key into a settings page and pushed a branch. Each step asks the same question in a different place: what does the workspace let this agent hold, what can that credential reach, how long does the reach last, and who can see afterward what the agent did.
None of those answers comes from the model or the prompt. They come from the workspace around the agent: the sandbox it runs in, the browser it reads through, the grant that authorizes one call, and the record that survives the run. A team that cannot answer them for one agent cannot answer them for forty, and the failure is quiet, because a credential read on a rendered page looks like ordinary work until it appears somewhere else.
The four questions an agent review has to ask, what the AI saw, where it could go, what it did and what an attacker gets, map onto the same rows. Put them on a six-row scorecard: what the agent holds, what it creates, what the grant covers, who signed it, which surfaces it governs and what the record keeps. A vendor that answers five rows has told a buyer where the sixth stands.
Key findings
- A secure workspace replaces the values a rendered page shows with consistent tokens before any model reads them, so the agent works with KEY_001 and ACCT_001 and the real credential resolves only at the approved destination (What Is Render-Layer Tokenization?).
- It also needs a named person approving each consequential action and a record that shows the token the model received, the pair to ask a vendor to demonstrate rather than describe (What Is a Permission Slip for an AI Agent?).
- The pages reviewed stop at custody: Cognition's guide says Devin "types the value directly" in the browser and does not describe what the model reads once the page renders (Cognition, 2026).
- AWS's AssumeRole documentation states that the permissions of a session are "the intersection of the role's identity-based policy and the session policies," so a role narrows what the agent can do and not what it can read (AWS, 2026).
- GitLab's documentation says a masked variable is replaced with
[MASKED]in the job log, and that masking is "not a guaranteed way to prevent malicious users from accessing variable values" (GitLab, 2026). - FINRA's 2026 oversight report flags that "Agents may act beyond the user's actual or intended scope and authority" (FINRA, 2025).
What should a secure workspace cover on a rendered page?
The scope comes first because the surfaces leak differently. A governed browser environment covers what an agent reads and does on a rendered page: dashboards, consoles, settings pages and sign-up forms, where the values a service displays are the values the model receives. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A workspace that governs only the terminal leaves every screen open, and one that governs only the browser leaves the shell open. Both surfaces need a control, and they are different controls. The review's control means put the gaps in order: scoping a credential to a task averages 0.85, keeping credentials from the agent by default 0.6, and approval before a credential or network 0.4, all read from documentation rather than enforcement (Can AI Coding Agents Read Your API Keys?).
The six rows below are the parts of a workspace that decide what an agent can reach and what a buyer can prove afterward.
| Row | What to score | The question to put to the vendor | What a passing answer describes |
|---|---|---|---|
| 1 | What the agent holds | Does any credential enter the agent's process? | A credential the agent never holds, used only by an approved execution environment |
| 2 | What the agent creates | What happens to a key or token the agent generates on a page? | A capture step that stores it outside the model and shows the agent a reference |
| 3 | What the grant covers | Which service, resource, operation and lifetime does one grant authorize? | One grant per task, naming all four, with an expiry the approver sets |
| 4 | Who holds the key | Whose key signs the grant, and can the vendor use it without you? | A key the developer holds, and a vendor that verifies a grant it cannot mint |
| 5 | Which surfaces are covered | Does the control cover the rendered page and the terminal? | A browser control for the page and a sandbox for the shell, each stated |
| 6 | What the record keeps | Does the record show the value or the reference? | The token the model received, the action, the approver and the destination |
What does the agent hold while it reads a page?
The first row is custody, and a workspace fails it when a long-lived API key sits in the agent's environment. AWS's AssumeRole documentation states that the call "Returns a set of temporary security credentials that you can use to access AWS resources," which keeps a durable key out of the agent's process but leaves the temporary credential in it (AWS, 2026).
The second row is the credential the agent creates. A coding agent asked to set up a deployment creates a token, and the page that shows it shows the value once. OpenAI's Codex Cloud page, marked Legacy, states that secrets "are only available to setup scripts" and that "secrets are removed before the agent phase starts," custody that stops at the boundary of the second phase (OpenAI, 2026). The agent phase is where a created token would be read.
Cognition's Devin guide gives the lifetime of a session credential, "scoped purely to the current session and are not saved for any future sessions," which is the right shape until a task runs longer than the session (Cognition, 2026). Doppler's page for coding agents says to "Give every coding agent its own scoped, read-only, expiring set of credentials," which still leaves open whether the agent can read the variables injected into its own process (How Do I Roll Out Coding Agents to a Team Without Sharing Credentials?).
What do the vendors themselves say?
The vendor pages reviewed describe where a credential is stored, not what the model reads on the page that displays it.
Browserbase's authentication guidance says to "Log in once, then reuse the saved authentication state," which removes repeated logins and leaves a session an agent can use (Browserbase, Authentication, 2026). The same guide recommends Contexts to "Store cookies, session tokens, and local storage to prevent repeated logins," a storage design that says nothing about what the model sees on the page (Browserbase, Authentication, 2026). Its Contexts page adds that "Contexts are uniquely encrypted at rest to ensure security" and that a Context "persists until you explicitly delete it or it becomes invalidated," so a login can outlive the run (Browserbase, Contexts, 2026).
OpenAI's Codex Cloud page is specific on one point and silent on another: "Environment variables are set for the full duration of the chat (including setup scripts and the agent phase)," so a value placed in a variable stays in reach for the whole task (OpenAI, 2026). Cognition's guide adds that for shell commands Devin "binds secrets as environment variables whenever needed," which puts the value in the agent's process rather than beside it (Cognition, 2026). A buyer still has to ask what the model receives when the page displays the value.
What belongs in a grant, and who approves it?
Rows three and four are the grant. A grant that names a service but not an operation covers every endpoint the service offers; without a lifetime it covers them indefinitely. A permission slip is the reviewable form: service, resource, operation, destination, lifetime and approver on one page, with no credential in the text (What Is a Permission Slip for an AI Agent?). OWASP's LLM06 entry lists "excessive functionality, excessive permissions and excessive autonomy" as the root causes of excessive agency (OWASP, 2025).
AWS sets the minimum session at "900 seconds (15 minutes)" and warns that "Role chaining limits your AWS CLI or AWS API role session to a maximum of one hour," which is the wrong shape for a run that lasts all afternoon (AWS, 2026).
The fourth row asks whose key signs the grant. A real credential is used only by an approved execution environment, within the scope and lifetime of a grant the developer's key signs (Keeping Your Keys Away From Your AI). The row has a measured reason: in a study of agentic coding editors, "attack success rates can reach as high as 84% for executing malicious commands," so the grant a run holds matters more than the model that proposes the command (What Does Least Privilege Look Like for Coding Agents?).
What record should the workspace keep?
The last row is the record, and its test is simple: the record should show the reference the model received, not the value. A record that stores the value has recreated the exposure it was meant to document.
Log-level redaction is the nearest familiar control, and its own documentation states the limit. GitLab's page says that "Masking a CI/CD variable is not a guaranteed way to prevent malicious users from accessing variable values," a line that applies to any record built on pattern matching (GitLab, 2026).
A stronger design puts a placeholder in front of the model and keeps the value at the destination. 1Password's blog for its OpenShell integration states that "the agent sees placeholders rather than real credentials" inside the sandbox, a design for the agent's own API calls that the page does not describe as independently tested (Which SOC 2 Controls Apply to Coding Agents That Hold Credentials?).
FINRA's 2026 oversight report notes that "Complicated, multi-step agent reasoning tasks can make outcomes difficult to trace or explain, complicating auditability," which is why the record has to be exported as it runs (FINRA, 2025). Ask for one artifact: the record of a page where a key was displayed. If it shows the key, the row failed; if it shows the token and the approver, it passed.
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, and real values resolve only at the approved destination, at the moment of an approved action. A named person confirms the policy and approves each consequential action, and every screen, action and approval is written to a record that exports to the organization's monitoring.
For the scorecard, that changes two rows from promises into properties: the credential is not in the model's context if it was never rendered there, and the record shows the token rather than a claim about what the model saw, so the sixth row becomes a document rather than a description. Both are properties a buyer can check in a demonstration, and the record is the artifact that proves them.
Its scope is the rendered page. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so the terminal half of the fifth row stays with the sandbox a team configures for its coding agent. The browser half is where the two designs differ: (RedactSure vs Browserbase: 2026 Comparison & Alternative) sets the session-storage design against the render-layer design.
What the record shows
For the buyer who answers for the agent, the six rows come down to one property: what the model receives on a rendered screen is a fact about the run, which no vendor policy settles in advance. The pages reviewed document custody on the other five rows, from temporary role sessions to a login stored in a Context, and each stops where the screen begins. The buyer should put the scorecard to one agent and one settings page: create a test key, watch what the model receives while the page renders, and compare that with the record the workspace exports. That comparison takes an afternoon and settles more than a questionnaire does.
Methodology and limitations
This page rests on vendor documentation from AWS, Cognition, Browserbase, OpenAI and GitLab, OWASP's LLM06 entry, FINRA's 2026 oversight report, and existing RedactSure research pages. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries the date for its page.
None of the products on the page was tested for this page, and "not described" refers to the pages reviewed rather than to a product's behavior. Vendor features change, and the page carries its date; statements about RedactSure describe what it does, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a six-row scorecard, and not an organization. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
What should I look for in a secure workspace for AI coding agents?
Six things, in this order: a credential the agent never holds, a capture step for credentials the agent creates, a grant that names a service, resource, operation and lifetime, a key the developer controls, coverage of both the rendered page and the terminal, and a record that shows references. Ask for each in the demonstration rather than the datasheet, and treat a deferred answer as an open row. A vendor that answers five and defers the sixth has told you exactly where the gap sits.
Does the workspace have to control what the agent reads on a screen?
Yes, if the agent works in a browser. The model receives whatever the rendered page displays, so a value on that page is in the context from the moment it renders. A sandbox that governs the shell does not reach the screen, and a page-level control does not reach the shell. The question to ask is which component held the value when the model read it, and the answer should be a component, not a policy.
Who should approve the credentials an agent creates?
A named person, on the record, for anything consequential. A created key is a new asset, and the page that displays it is the last point where a person can decide whether the agent needed it. An approval the model triggers itself is not a control, because the model decides whether to ask. Ask to see the approver's name beside the key in the record and not only in a workflow diagram.
What should the audit record show?
The reference, not the value. A useful record names the token the model received, the action it took, the destination, the approver and the time, and it exports to the team's own monitoring. A record that stores the rendered value has recreated the exposure it was meant to document. Test it with one run: ask for the record of a page where a key was displayed, then check which form appears and whether the approver is named.
Does a sandbox cover what the agent reads in a browser?
No. A sandbox governs the process it contains, and the browser is usually outside it. Devin's guide, for example, says the browser types the value directly, so the value is on the page rather than in the sandbox. The two controls answer different rows of the scorecard, and a workspace that offers one should be asked about the other before a repository is connected.
Is a short-lived token enough?
Only where the lifetime is shorter than the exposure. A token that expires in fifteen minutes limits what a leaked credential can do later, and does nothing about a value the model read while the token was live. Lifetime is one field of one row. Pair it with a scope that names the operation and a record that shows what the model received, or the expiry only shortens the window without closing it.
How RedactSure Keeps a Created Key Out of the Agent's Reach
A coding agent that creates a key and then reads the page displaying it has put the value in the one place the record cannot protect.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent creates a deploy key on a repository settings page and reads the value the page renders, so the key sits in the transcript and the sixth row fails. Inside the governed environment: the page renders KEY_001, the agent copies the token into the workflow, and the value resolves only when a named person approves the deployment.
RedactSure is deploying now with enterprise and government customers. Cognition's guide says the browser types the value directly, which is the exposure the workspace has to remove.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
Five rows can be answered from a datasheet; the sixth shows up in the transcript. Bring one task that creates a key and see, with test values, what the model reads and what the record keeps. Book a demo