Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Devin Keep an Audit Trail of Credential Use?
No: Devin's guide describes four credential scopes, direct typing in the browser and environment variables in the shell, and describes no audit log of which credential a session used. Ask for a per-session record of the credential, the screen and the approving person, and test what it contains.
Compliance teams running Devin get the audit request weeks after the work: name every credential the Devin session used, the day it spent each one, and the page that received the value. The person who ran the session remembers part of it. A transcript holds the conversation and the tool calls, and the credential appears as a name. Which credential was spent at 2:14 on a Tuesday is the part nothing points at.
Devin works from a chat, a command line and a browser. Its guide to credentials covers four scopes, explains how a value reaches the browser and the shell, and states that values are encrypted at rest (Cognition, 2026). Those sentences answer where a credential is kept and how it arrives. They do not answer what a record of its use would contain.
The difference between a credential stored well and one used accountably shows up on the page where the agent acts, in whether the model receives the value or a label that resolves somewhere else. What Is an AI Control Record? sets out what a record of agent work has to hold, and that standard applies to Devin's pages and to its transcript.
Key findings
- For the record to answer which credential a session used, the value on each page would have to be replaced with a consistent token before the model reads it, so the trail shows KEY_01 without the key (What Is Render-Layer Tokenization?).
- It would also require a named person approving each rotation, payment and record change, and every screen, action and approval written to a record the organization can export (What Is an AI Control Record?).
- Devin's guide documents four scopes, direct typing in the browser and environment variables in the shell, and names no audit log of credential use, so the session transcript is the record it leaves (Cognition, 2026).
- AWS's agent guidance states the requirement that a transcript cannot meet: "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026).
- FINRA's 2026 oversight report flags that agents "may act beyond the user's actual or intended scope and authority," which is the failure a credential-use record is meant to make visible (FINRA, 2025).
- Coder's best-practice page tells operators to "use separate identities with limited scope whenever interacting autonomously," which changes who an action belongs to and not what the record shows (Coder, 2026).
What does Devin's guide record about a credential?
The guide organizes credentials by scope: organization, personal, repository and session. The session scope is the one nearest a single run, and the page defines it tightly: a session credential is "scoped purely to the current session and are not saved for any future sessions" (Cognition, 2026). That answers how long the value lives inside Devin, not what the session did with it.
"In the browser, Devin types the value directly," the guide says, so on a sign-in form or a console page the field receives the real value (Cognition, 2026). For shell commands, it "binds secrets as environment variables whenever needed," which places the value in the process the agent runs, and "All secrets are encrypted at rest," a statement about storage rather than use (Cognition, 2026).
Read together, those statements describe custody: where a credential sits, how long it lasts, and how it arrives at the browser or the shell. An auditor asking which credential was used when needs a different object, a row per use with a time, an actor, a destination and an approval. Whether the model sees the value is not described on the page that defines the four scopes (Cognition, 2026).
| What the guide covers | What it states | What the audit request needs |
|---|---|---|
| Scope | Organization, personal, repository and session | Which scope a given run drew on |
| Browser delivery | Devin types the value directly | Which page received the value, and what the model read |
| Shell delivery | Environment variables whenever needed | Which command read the variable, and when |
| Storage | Encrypted at rest | Whether the record can name the credential without holding it |
Each left-hand row is a statement about storage or delivery; each right-hand row is a field an auditor will ask for.
What does an auditor get from a session transcript?
A transcript is the record most teams have. It shows the request, the agent's messages, the tool calls and their output, readable by the person who ran the work.
It does not answer which credential was spent. A command that reads an environment variable records the command, and the value it read is not in the transcript. A browser step records that a form was filled, and the field it filled is not identified by credential. The session scope ends with the session, so the window in which the credential could have been used is bounded, and the uses inside that window are not enumerated (Cognition, 2026).
Devin is one of five coding agents whose documentation describes short-lived session credentials, and it does not fully document a per-action audit record (Can AI Coding Agents Read Your API Keys?).
AWS's agent guidance states the requirement: "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026). A transcript attributes actions to a session; the actor behind it is the person who started it, and the credential behind the action is a name in a list. FINRA's 2026 oversight report adds the second half of the problem, that "complicated, multi-step agent reasoning tasks can make outcomes difficult to trace or explain, complicating auditability" (FINRA, 2025).
How Do You Audit What an AI Agent Saw and Did? explains why a complete log of what a model read becomes a second repository of sensitive records, one reason teams keep a transcript.
What do the vendors themselves say?
The vendor whose product this page is about documents custody in four sentences. A second vendor documents the operating pattern that makes custody matter. Both belong in a procurement review, and only one of them produces a row an auditor can read.
Cognition's guide names the four scopes, says a session credential is "scoped purely to the current session and are not saved for any future sessions," says that "In the browser, Devin types the value directly," says that for shell commands it "binds secrets as environment variables whenever needed," and says that "All secrets are encrypted at rest" (Cognition, 2026). Those are facts about storage and delivery. None is a fact about a record of use.
Coder's best-practices page describes agents that "run independently without user interaction for extended periods of time," the working pattern that leaves nobody watching a credential being spent, and advises operators to "Be sure not to give agents full permissions on behalf of a user, and instead use separate identities with limited scope whenever interacting autonomously" (Coder, 2026). A separate identity improves attribution at the platform and does not record which credential the agent read on a page, because the identity is not the credential.
| Dimension | Devin, per its documentation | What a buyer should verify |
|---|---|---|
| Scope | Organization, personal, repository and session | Which scope a task may draw on, and who can change it |
| Browser | "In the browser, Devin types the value directly" | What the model receives on that page |
| Shell | Binds as environment variables whenever needed | Which commands read the variable, and whether that is logged |
| Storage | Encrypted at rest | Whether the record can name the credential without the value |
| Record of use | Not described | A row per use: time, credential, page, actor, approval |
Three rows describe what the vendor documents and one states what the pages reviewed do not.
What would a credential-use record have to contain?
Five fields carry the answer: the credential's name, never its value; the time and the run; the page or command that received it; the person who approved the action; and where the record is exported. A record missing any one leaves the auditor to interview someone.
AWS's guidance requires audit logs that attribute every action to an agent or a human actor (AWS, 2026). Harvard's guidance tells teams to "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible" and to "Maintain the ability to promptly revoke access, disable the connector, or stop the system when it behaves unexpectedly" (Harvard University Information Security and Data Privacy, 2026). FINRA's 2026 oversight report names the pattern: "AI agents acting autonomously without human validation and approval" (FINRA, 2025).
Such a record does two jobs at once. It answers the audit question with rows rather than recollection, and it gives the approver something concrete: a named action on a named page, not a general permission. What Is Supervised Delegation? covers the accountability half, and How to Maintain Audit Trails for AI Agent Activity covers the retention half.
Where does the record fail when the agent reads a real screen?
On a rendered page the values arrive before any policy can name them. A cloud console's API keys page draws the key, the project and the account in one view, and a model reading it receives all of it unless something sits between the render and the read.
The research record explains why this is the failure point. A study of autonomous web agents found they "are prone to inadvertent use of unnecessary sensitive information" (Zharmagambetov et al., 2025), so the page a task needs is often not the page whose values it reads. Injection turns the same property into an attack: EchoLeak documented a zero-click injection in Microsoft 365 Copilot whose client "automatically fetches the external image URL included by the attacker" (Reddy and Gujral, 2025), and adaptive attacks against 12 published defenses reached an "attack success rate above 90% for most" (Nasr et al., 2025).
For a record, the implication is direct: if the session read the real value, the log either holds the value, making it a second copy of the credential, or holds nothing that identifies what was read. Does Cursor Keep an Audit Log of What the Agent Did? documents the same limit in a coding agent's history, where approvals cover commands and the record stops at the transcript.
What does a governed environment change?
A governed environment changes what there is to record. On each rendered page, the values a policy names are replaced with consistent tokens before any model reads the screen, so the model works on KEY_01 and the real key resolves only at the approved destination. A named person approves each consequential action, and every screen, action and approval is written to a record the organization can export to its own monitoring.
The consequence for an audit trail is that the record can name the credential without holding it. A row that says KEY_01 was read on the API keys page at 2:14, that the task was a key rotation, and that a named person approved it answers the auditor's question and stays safe to keep. The record becomes evidence rather than a second copy of the asset.
The same record answers the question a security review asks about the model's context. If the screen showed a label, the context holds the label, and a successful injection collects labels rather than credentials. A transcript cannot do that, because it holds what the model said rather than what the page showed.
That is the control class this page's question turns on, and it is the subject of RedactSure vs Devin: 2026 Comparison & Alternative, which sets the two designs side by side.
What the record shows
Auditability begins with what the model received on the page, because that determines whether a log can name a credential without holding it. Devin's guide covers scopes, browser typing, shell variables and encryption, and describes no credential-use record, so the transcript is what an auditor is handed, and it attributes work to a session, not a credential (Cognition, 2026). Storage is sound; the gap is the absence of a row. A team can check this on its own system: take one session that touched a key, list its tool calls, and try to connect each call to the credential it spent and the approver. That is the test, and where the chain breaks is the field the record needs.
Methodology and limitations
This page rests on Devin's guide to credentials, Coder's best-practices page, AWS's agent guidance, FINRA's 2026 oversight report, Harvard's guidance and three papers. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 16, 2026 and October 21, 2026, and each Sources line carries the date for its page.
No product on this page was tested. "Not described" means the pages reviewed; vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers; the console page described here is a record type, not an organization. Determinations belong to the organization's counsel, assessors and compliance officers, and only a pilot of one workflow substitutes.
Frequently asked questions
Does Devin keep an audit trail of credential use?
No. The guide documents four credential scopes, direct typing in the browser, environment variables in the shell and encryption at rest, and describes no log of which credential a session used. The transcript records the conversation and tool calls, not the value spent. A team that needs the trail should ask for a per-session record naming the credential, the page and the approver.
What does a Devin session transcript show?
It shows the request, the agent's messages, the tool calls and their output, which is enough to follow the work and not enough to attribute a credential. A command that reads an environment variable appears as the command; the value it read does not appear. A browser step appears as a filled form; the field is not identified by credential. The transcript is a readable account of a session, not an audit trail.
Does Devin's browser path show the model the credential?
Not from the pages reviewed. The guide says that "In the browser, Devin types the value directly," which places the real value on the page, and it states that whether the model sees the value is not described. Delivery is documented, model visibility is not. A buyer should treat the value as visible to the model until the vendor documents otherwise, and ask for that in writing.
Can encryption at rest substitute for a credential-use record?
No. Encryption at rest protects a stored value, and the audit question is about a use that happened on a page. A credential in a browser field or a process environment is plaintext at the moment it is spent, and the record of that moment is separate from the store. The guide's statement that "All secrets are encrypted at rest" is a storage fact. It says nothing about which page received the value or who approved the action.
Who should approve a credential an agent uses?
A named person, on the specific action rather than the credential in general. Harvard's guidance asks for human approval of high-impact, sensitive, irreversible or externally visible actions whenever feasible, and AWS's guidance wants the resulting action attributed to an agent or a human actor without ambiguity. Approval at that level gives the record an actor, which is what an auditor asks for first.
What should a team ask for instead of a transcript?
Ask for a record with a row per credential use: the credential's name, the run, the page or command, the person who approved it, and where the record is exported. Ask whether the values on a rendered page are replaced before the model reads them, because that determines whether the record can name a credential without holding it. Ask to see one exported row from a pilot on your own workflow. A vendor that can produce it has answered the audit question.
How RedactSure Keeps Credential Use Auditable
A credential that reaches a real screen cannot be reconstructed from a transcript afterwards, and encryption at rest does not change what the screen held. The vendor's own guide states that the browser receives the value directly, and the session keeps no row for it.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the session opens the API keys page, the model reads the live key, and nothing records which page received it. Inside the governed environment the same page renders KEY_01, the model works on the label, and the key resolves at the approved destination after a named person approves the rotation.
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
An auditor's credential question is answerable only if the record holds what the model read. Bring one session of your own and see, with test values, what the page renders, who approves the rotation and what the record keeps. Book a demo