Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Devin's Isolated Machine Keep Your Credentials Away From the Model?
No; a session-scoped credential stays out of the next session and out of the other client's work, and the value still lands on the page the model reads once Devin types it into a field. Ask what the model is shown on a rendered screen, not only what the session can reach.
A consultancy that runs one Devin session per client has a defensible answer for a client's security questionnaire: the work does not mix, and a credential added for one session is "scoped purely to the current session and are not saved for any future sessions" (Cognition, 2026). What that answer leaves open is the screen. A session that rotates a deployment key opens a hosting dashboard, and "In the browser, Devin types the value directly," so the page it draws is the page the model works from for the rest of the task (Cognition, 2026). Isolation describes the run, while exposure depends on the page. A scope can be written into a settings page and audited later, and a screen the model read cannot, which is why the second question needs a different control, a different record and a different review. The record here is two sessions with different clients, each rotating one deployment key on a hosting dashboard, and a client's reviewer will ask what each session's model was shown, because that is the part a scope does not cover and a transcript keeps in full.
Key findings
- For Devin to keep one client's deployment key away from the model, the values on the rendered page would have to be replaced with consistent tokens before the model reads it, so the session works with DEPLOY_KEY_01 and the real key resolves only at the approved destination; a least-privilege grant over the credential does not touch the screen (What Is Least Exposure?).
- It would also require a named person approving each release of a real value, and a record of every screen the model read with that person's name on it, because a tether describes authority over the run and not what the run was shown (What Is a Tethered Agent?).
- Devin's secrets page documents where a value is kept and how it is delivered, and whether the model sees the value after delivery is not described in the pages reviewed (Cognition, 2026).
- Cognition's page states that "In the browser, Devin types the value directly," which puts the value on the page the session works from and in front of the model that reads it (Cognition, 2026).
- For shell commands it "binds secrets as environment variables whenever needed," which puts the value in the process that runs the command, inside the session the model works in (Cognition, 2026).
- Coder's documentation makes the boundary argument in its own words: "LLMs and agents can be dangerous if not run with proper boundaries," and it advises separate identities with limited scope (Coder, 2026).
What does a Devin session read when it opens a page that holds a deployment key?
A governed browser environment covers the rendered page an agent reads and acts on: dashboards, consoles, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. Devin's browser work sits in the first group: a session that rotates a hosting key opens the provider's dashboard, and the key is one field among the account name and the deploy history.
The secrets page describes delivery, not rendering. "In the browser, Devin types the value directly," which places the value in the form the session is working in, and the page describes no substitute in its place (Cognition, 2026). A browser agent acts on what the page renders, so the value it typed is on the screen it reads on the next step.
Placeholders cover a different step. Browser Use's sensitive data documentation states that "the LLM only sees placeholders (x_user, x_pass)" and that "real values are injected directly into form fields after the LLM call," which covers values the agent types and not values a page displays (Can a Browser Agent Read an API Key It Just Generated?). A filled field is not the same control as a rendered page, and nothing here takes the value off the screen before the model reads it.
The review of six coding agents finds 1 that documents keeping the real value from the model, and Devin is one of the other five (Can AI Coding Agents Read Your API Keys?).
What do two sessions with different clients share, and what stays apart?
The record for this page is two sessions with different clients, each rotating one deployment key on a hosting dashboard. Cognition's secrets page lists four scopes, organization, personal, repository and session, and a session credential is "scoped purely to the current session and are not saved for any future sessions" (Cognition, 2026). As an isolation control, the session scope is a real boundary around reuse and not around what the model reads: a value added for client A's session does not persist into the next session.
What the boundary does not decide is the screen. Both sessions read a rendered dashboard, and the value each needs is on that dashboard by design; isolation keeps runs from inheriting each other's values and does not keep either model from reading the value its own page carries.
Cognition lists an organization scope alongside the session scope, so what separates two clients' sessions depends on the scope chosen for each value rather than on the session boundary alone (Cognition, 2026). A team that wants one client's key kept from the other's session has to choose the session scope for it.
The sandbox pages describe a similar boundary: Docker's documentation states that in its sandbox "credential values are never stored inside the VM" (Can I Bring My Own Agent Harness to a Secure Sandbox?), which says nothing about what a page shows the model.
What do the vendors themselves say?
The secrets page describes one store and two deliveries. "In the browser, Devin types the value directly"; for shell commands it "binds secrets as environment variables whenever needed"; and "All secrets are encrypted at rest" (Cognition, 2026). What the model receives after either delivery is not described on the page (Cognition, 2026).
The design answers where the value lives, who can scope it and how the run gets it, and it stops at delivery. A typed value is on a page and a bound variable is in a process; neither sentence says what the model is shown once the value arrives.
Coder's documentation makes the boundary argument in its own words: "LLMs and agents can be dangerous if not run with proper boundaries," and it advises separate identities with limited scope for autonomous work (Coder, 2026). The advice governs identity and permission, the same layer the scopes govern, and it does not describe what a rendered page shows a model.
| Dimension | Cognition, per its documentation | What a buyer should verify |
|---|---|---|
| Where a value lives | Organization, personal, repository and session scopes | Which scope each client's value uses |
| Browser delivery | "Devin types the value directly" | What the model reads after the typing |
| Shell delivery | Values bound as environment variables | Which commands can print them |
| Protection in the store | Encrypted at rest | Who can read the store |
| What the model sees | Not described on the page | The screen as the model saw it |
What does the research record say about a value the model already holds?
A value that reaches the model is not contained by the boundary that kept it out of another session. The information-flow paper describes the failure isolation does not reach: "poisoned data retrieved from one component can change the model's behavior and compromise the entire system, including coercing the model to spread confidential data to untrusted components" (Siddiqui et al., 2025).
A firewall at the agent-tool interface, a "simple, modular, and model-agnostic defense," "achieves perfect security with high utility across all four public benchmarks: AgentDojo, Agent Security Bench, InjecAgent and tau-Bench" (Bhagwatkar et al., 2026), though the paper also warns that "existing agentic security benchmarks are easily saturated by a simple approach," so a clean score is not a clean run (Bhagwatkar et al., 2026).
A visual redaction model reports "more than doubling text-extraction baseline accuracy (0.753 vs 0.357 mAP@50)" on rendered web pages, which makes the render layer the place to act (Zhao, 2026), since a detector reading the same pixels is a second reader.
MIT Technology Review puts the limit on guardrails plainly: "because the mechanisms of refusal are probabilistic, they're never likely to be all that reliable" (MIT Technology Review, 2026). The Columbia lab adds that "trustworthy agent automation cannot be solved at a single layer of the stack" (DAPLab, 2026), and isolation is one layer while the screen is another (Does Keeping Credentials Outside the Sandbox Slow Down a Coding Agent?).
What should a security team ask for in writing?
Ask which value a session's model receives on a rendered screen before asking about the machine. A vendor can answer that only by describing the rendered page: what value is drawn in the field, whether a substitute is used, and what the model receives when the page is captured. A statement that the session is isolated, that the value is encrypted at rest, or that a separate identity owns the run does not answer it (Enterprise Browser or Render-Layer Tokenization?). An enterprise browser governs what a person copies or downloads on a managed device, not what a model reading the page receives.
HHS describes "two methods that can be used to satisfy the Privacy Rule's de-identification standard," Expert Determination and Safe Harbor (HHS, 2012), and neither is a step a rendered screen passes through on its way to a model, so a client's staging dashboard needs its values governed at the page.
CISA's Zero Trust Maturity Model frames maturity as a matter of reach and access, the half of the problem a session boundary governs (CISA, 2023). The other half is five written questions: which scope holds each client's value and who can change it; what the model receives on the screen where the value appears; who approves the release of a real value; what record shows the screen as the model saw it; and what happens to a value in a transcript.
What does a governed environment change?
A governed environment acts where a page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works with DEPLOY_KEY_01 rather than the key. Real values resolve only at the approved destination, at the moment of an approved action. A named person approves each release, and every screen, action and approval is written to a record exported to the organization's own monitoring.
For this question it changes both halves. The isolation half gets stronger, because a token belongs to the run that issued it: the label session A sees resolves to nothing in session B, and the value never sits in a context a later run inherits. The visibility half is what the secrets page leaves open: the page renders DEPLOY_KEY_01 in place of the key before the model reads it, so an injection collects a label rather than a key.
Its scope is the rendered page: the deployment dashboard, the settings page, the sign-up form. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so the shell delivery stays with the sandbox.
The category comparison is set out in RedactSure vs Devin: 2026 Comparison & Alternative, where the store and the screen sit side by side on one record.
What the record shows
A reviewer can check three things here: what the model received on the rendered page, who approved the release of a real value, and what record the run left. The session boundary answers the first part in the negative. The secrets page documents four scopes, an encrypted store and two deliveries, and no substitute in the page; the browser delivery types the value into the page the session reads. Isolation limits what a leaked value can reach across sessions, not what the model holds while the run continues. A team can check its own two sessions: open one client's hosting dashboard, rotate a test key, capture the screen the model saw and the transcript, then search both for the key. If the value appears in either, the control sits in the store and not on the page.
Methodology and limitations
This page rests on Cognition's secrets page for Devin, Coder's best-practices page, three research preprints, HHS guidance, CISA's Zero Trust Maturity Model, MIT Technology Review and the Columbia DAPLab page, with existing RedactSure research pages. Vendor pages were read between October 16, 2026 and October 21, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where each product applies its control.
No product named here was tested for this page, and "not described in the pages reviewed" means the pages reviewed. Whether each session runs on its own isolated machine is outside those pages, so the isolation stated here is the session scope that ends with the run. Vendor features change; the page carries its date. RedactSure is deploying now with enterprise and government customers. The example is a record type, two sessions with different clients rotating a deployment key, not an organization. Determinations about whether a workflow meets a regulatory standard belong to counsel, assessors and the organization's compliance officers. Nothing here replaces a pilot on the organization's own screens.
Frequently asked questions
Does Devin's isolated machine keep credentials away from the model?
No. The isolation Devin documents is a scope on the credential: a session value is not saved for later sessions, and the store keeps values encrypted. In the browser, Devin types the value directly, so the value is drawn on the page the session reads and the model receives that page. A boundary around the session narrows what a leaked value can reach. It does not change what the model is shown while the session works.
Does the session scope keep one client's credential out of the other client's session?
For a session-scoped value, yes: it ends with the run and is not saved for a future session. For an organization-scoped value, no: the page lists an organization scope beside the session scope, so a value added there is not confined to one client's session. The separation between two clients is therefore the scope an operator chooses, not a property of the isolated machine. Check which scope each value uses before relying on it.
What does the model receive when Devin types a value into a page?
The page as rendered, including the value it typed. A browser agent acts on what its page shows, so the field it filled is part of the screen it reads on the next step. The secrets page does not describe a substitute value in the field, and it does not describe what the model sees after delivery. That makes the rendered page the thing to ask about, not the store.
Who approves the release of a real value on a session?
No one, on the pages reviewed. A person chooses a scope when the credential is added, and the session then uses the value as needed, typing it into a page or binding it to a command. That is a decision about which value the run may use, not an approval of the action that releases it. An approval is per action and carries a name, which is what a reviewer reads when the transcript cannot say who allowed the release.
What record shows what a session's model read?
The secrets page describes the store and the scope, not the screen. A value's scope tells you which session could use it; it does not tell you what the model saw on the page where the value appeared. A record that answers the question captures each screen as the model saw it, with the actions and approvals beside it, and exports to the customer's own monitoring.
Would running each session on a separate machine change the answer?
No, not for the screen. A separate machine changes what a compromised session can reach: another client's files, another client's network, another client's live session. It does not change the fact that the session's own model reads the page the session's browser opened. The value the session needs is on that page, whichever machine draws it, so the control that changes the answer sits at the render layer.
How RedactSure Keeps a Client's Key Off the Page Its Sessions Read
Two clients on two sessions share one model that reads whatever each session's pages render, and the scopes above govern the store rather than the screen. Cognition's page states that "In the browser, Devin types the value directly," which is why the screen is the place to act (Cognition, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: session A's dashboard renders the key and the model reads it while filling the deploy form. Inside the governed environment: the page renders DEPLOY_KEY_01, the real key resolves at the deploy destination on a named person's approval, and session B's label means nothing in session A.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A key that renders once on a dashboard stays in the model's context for the rest of the session. Bring one deploy task and see, with test values, what the model reads and where the real value lands. Book a demo