Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can I Prove to an Auditor That Coding Agents Never Saw Production Credentials?

Yes, when the value never entered the agent's environment by design and the record shows a reference to it; no, when the proof is a string search across transcripts and logs. Ask for the design, the grant log and the destination record, then test one agent on one production task.

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

An auditor's request is narrower than it sounds. Nobody has to show that a model never encountered a credential anywhere; the claim is about one agent, one task and one named production value, and it is settled by what the environment allowed and what the record preserves. There are two kinds of answer. One is a search: grep the transcript, the logs and the artifact store for the string, find nothing, and report that. The other is a design: the value was never in the agent's environment, the grant referred to it by name, and the record shows the reference, the destination and the person who approved the use. The first is cheap, and it is what most teams hand over. The second is what an assessor tests, because a search can show only that a string was not found, not that a value was never available. This page sets the scope for a coding agent, takes one record apart, a grant log beside a transcript, reads what vendors document about identity, placeholders and audit trails, and sets out what a transcript search misses. It ends with a test one engineer can run on one production task.

Key findings

  • Teleport's framework lists "Comprehensive audit trails and behavior analysis for agent actions across infrastructure" and marks most of the capabilities it lists in progress or not started (Teleport, 2026).
  • 1Password's write-up of its OpenShell integration states that "the agent can work with real systems without holding any credentials in its context" because "the agent sees placeholders rather than real credentials" (1Password, 2026).
  • OWASP Foundation documents an attack that "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations," which makes a recorded approval a weaker artifact than it looks (OWASP Foundation, n.d.).
  • Sonatype's review of the first quarter of 2025 found that "56% of the malware discovered in Q1 2025 was related to data exfiltration," an increase from "26% in Q4 2024" (Sonatype, 2025).
  • A governed environment replaces a production value with a consistent token before any model reads the screen, so an agent working a service's settings page holds DATABASE_001 and never the connection string (What Is Render-Layer Tokenization?).
  • Real values resolve only at the approved destination at the moment of an approved action, and every screen, action and approval is written to a record that exports to the organization's own monitoring (What Is an AI Control Record?).

What does a governed environment cover when a coding agent touches production?

A governed browser environment governs what an agent reads and does on a page that has been rendered to it. In production work that means the console screens where a service's configuration lives: the environment page that reveals a connection string on click, the settings page where a deploy key is rotated, and a CI provider's credentials page. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP.

The split matters because much of a coding agent's production access happens on the other side of it. An agent that reads an exported variable in a shell, opens an environment file from the working tree, or calls the cloud API with a key in its own environment is outside a browser control. The evidence for that path is the sandbox configuration and the secret manager's access log, and the durable credential it would need is the case AWS's own guidance rules out for the root user, as Is It Safe to Let an AI Agent Set Up Your Cloud Environment? sets out.

The record type for this page is the pair an auditor asks for: a grant log and a transcript. A coding agent is asked to find why a production service stopped responding. It opens the service's environment settings page in the console, presses Reveal on one variable, reads a connection string, and a person approves a restart. The grant log records the page, the service, the action and the approver; the transcript records what the model received. Every section after this one asks what would make those two artifacts conclusive together.

What does an auditor accept as proof that the value was never seen?

The claim is narrow: for one agent, one task and one named production value, the value was not available to the model. What supports it is evidence that would fail if the claim were false. Four artifacts do that work, and the transcript is the fifth and weakest.

The design comes first. Somewhere in configuration, reviewable before the run, the agent's environment holds no copy of the value: no variable that carries it, no file path that resolves to it, no page in its allowlist that renders it without substitution. A grant that refers to a credential by name is the artifact here, because a name can be checked against a store while a value cannot be checked against a transcript. AWS's Well-Architected Agentic AI Lens states that "audit logs attribute every action unambiguously to either an agent or a human actor," which is what makes a grant log evidence rather than a diary (AWS, 2026).

The destination record and the person follow. The record says where the real value went, at what moment and on whose approval, and it covers the half a transcript omits: a value can be delivered without passing through the model. In most enterprise agent deployments, no one can say which person is accountable for a given action, and after an incident the first audit finding is that absence (What Is Supervised Delegation?). A grant without a name answers a different question from the one asked. An agent that acts through an engineer's own login produces a log that reads as the engineer, the problem Google's Workspace guidance on super admin use describes for people, applied to a process that works nights, a case Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? sets out. The shape of the test is the same in regulated work.

What do the vendors themselves say?

The vendor pages reviewed describe identity, placeholders, session state and audit attribution. Each states what happens at the point the agent reads or the point a request leaves the process. None of them is written as the record an assessor asks for, so each is evidence of a mechanism rather than of a run.

Dimension Vendor, per its documentation What a buyer should verify
Agent identity Teleport's framework states that agents need "a verifiable, cryptographic identity tied to where they're running, not a shared API key" (Teleport, 2026). Which capabilities are shipped: the page marks most in progress or not started and gives no certificate lifetime.
Placeholders 1Password's write-up states that "OpenShell Gateway replaces a placeholder with the real value only when the agent sends a request to an approved host" (1Password, 2026). Who approves the host list, and whether the integration has been independently audited, which the page does not describe.
Session state Browserbase's authentication guidance says to "Log in once, then reuse the saved authentication state," storing "cookies, session tokens, and local storage" in a context, and it does not describe how usernames and passwords are handled in automated sessions (Browserbase, 2026). Whether a stored session can reach a production console, and what ends it.
Attribution AWS's Agentic AI Lens makes the attribution requirement explicit: an audit log has to say whether an action was the agent's or a person's (AWS, 2026). Whether the logs you hold make that split for page actions, and whether the agent can act under a shared human login.

Three of the four rows are conditions under which a per-run record becomes possible: an identity that separates the agent from the person, a placeholder at the point of reading, and a session that can be ended. The record that answers this page's question sits one level above them, because it has to state what the model was shown on the page and who approved the request that resolved a token into a value. That artifact is not described in the pages reviewed. The table still earns its place: it says which mechanism each vendor supplies and which question each page leaves open, and that separates a control that produces evidence from one that produces a claim.

What does a transcript search prove, and what does it miss?

A string search answers one question: does this exact value appear in the text we hold. It is worth running and it is cheap. It is not evidence that the value was never in the model's context, for four reasons.

First, a tokenized run contains no string to find, by construction, so a clean transcript is consistent with a governed run and with an ungoverned one whose screens were simply never quoted in a message. Second, the transcript is not the screen: a model that reads a settings page receives fields it never repeats, and the page as rendered is the artifact that speaks to this claim. Third, a browser context that stores cookies and session tokens outlives the conversation, and a session token is a credential that no transcript shows (Browserbase, 2026).

Fourth, approvals can be forged. An approval recorded by a page is only as good as the page, and OWASP Foundation documents an attack that forges the dialog itself, so an approval line has to come from outside the screen being approved (OWASP Foundation, n.d.).

The environment is also a market. A coding agent that installs a dependency runs code from the population Sonatype measured, where "a dramatic increase from 26% in Q4 2024" describes malware built to take data out (Sonatype, 2025). Verizon's 2026 report makes the matching point about where breaches begin: breaches "now start with software vulnerabilities, beating stolen passwords as the top way attackers get in," so a search aimed at a password string is aimed at the vector the report puts second (Verizon, 2026).

None of this makes a transcript search worthless. It makes it a check on the text, one artifact among five, and it makes the absence of a string a weak answer to a question about exposure.

How do you test the claim on one agent and one task?

The test is small enough to run in an afternoon and specific enough to fail. Pick one agent, one production task and one value, and put a canary in the settings page the agent reads: a connection string with a recognizable host.

The grant log should name one agent, one resource, one action, one window and one person. The transcript should hold the canary as a token, never as the host. The rendered pages should show that token where the value sat. The destination record should place the real value at one destination, on one approval taken outside the page.

Two points strengthen it. Zero trust guidance grants no implicit trust to assets or accounts "based solely on their physical or network location," so a console inside the corporate network is not a page whose reads need no record (NIST, 2020). And the evidence has to be per agent: Gartner's May 2026 release warns that "when the same controls are applied indiscriminately, organizations encounter two common failure modes" (Gartner, 2026).

Sign-up and settings forms are a measured leakage point: an environmental injection attack on generalist web agents reached an attack success rate of up to 70 percent in stealing users' specific personal information (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?). The minimum necessary standard at 45 CFR 164.502(b) asks for reasonable efforts to limit protected health information to what the purpose needs, and the same showing for a production credential is a page that renders a token, which Can Staff Use AI on Patient Records Without PHI? works through.

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 DATABASE_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, including every payment, submission and record change. 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 it changes what the evidence is. The transcript holds tokens, so the value cannot be searched for and does not need to be: the record states what was rendered and what was resolved, in that order. The claim becomes a property of the design, checkable before the run, rather than a property of a text, checkable only after it.

Three artifacts then line up, the grant, the rendered page and the destination, and a run that fails any of them appears as a gap rather than as an absence. That is the difference an assessor is trained to look for.

The limit is the one the first section set. It governs the rendered page, and a value that reaches a shell, an IDE, a local file or a direct API call is governed by the sandbox and the credential store instead, with their own record.

Methodology and limitations

This page rests on vendor documentation from Teleport, 1Password, Browserbase and AWS, the OWASP Foundation's attack page, NIST's zero trust guidance, industry research from Sonatype and Verizon, Gartner's May 2026 release, and existing RedactSure research pages. 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 industry reports are cited as reported and not as independently measured. Where a vendor page marks a capability in progress or not started, the page treats it as a stated plan rather than a shipped feature.

RedactSure did not test any of the named products hands-on. "Not described" means not described in the pages reviewed. The grant log and the transcript are described as a record type a team can assemble, not as fields that any named product produces, and the artifacts that record should hold are set out as a design requirement rather than as an observation of a vendor. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. Vendor features change, and the page carries its date; treat a release after that date as unreviewed until the test above is repeated. The example describes a record type, a coding agent that reads one production settings page, and not an organization; the rendered page and the shell were not compared in a live run.

Determinations about whether an evidence practice meets a contractual, audit or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent against a canary value on a test service, repeated after each release, with the five artifacts kept together.

What the record shows

The record answers the title in two parts. A design that keeps the value out of the agent's environment makes the claim true, and a per-run record of what was rendered, what was resolved and who approved makes it provable. A transcript search supplies neither, because a missing string is consistent with a governed run and with a run whose values were simply never quoted. The vendor pages reviewed supply conditions rather than the record: identity that separates the agent from the person, placeholders at the point of reading, and sessions that outlive the run. RedactSure's environment is built on the layer that produces the record. Before the audit, run one test: name one agent and one task, put a canary in the production settings page it reads, and compare what the transcript holds with what the rendered page held, then confirm where the real value went and which person approved it going there.

Frequently asked questions

Can I prove to an auditor that coding agents never saw production credentials?

Yes, if the claim is stated narrowly and the evidence is architectural. For one agent and one named value, show that the value was not in the agent's environment, that the grant referred to it by name, that no page in the allowlist rendered it unsubstituted, and that the record places the real value at one approved destination under one person's approval. A transcript search can sit beside that record but cannot replace it, because a value that was never rendered leaves no string to find.

Does a clean transcript search count as evidence?

It counts as one check, and a weak one. A search proves that a string is absent from the text you hold; it does not prove the value was unavailable, because a model can read a screen and never quote it, and a tokenized run has no string to find in the first place. Offer the search beside the design and the grant log, state which text was searched and over what period, and keep the result beside that statement rather than in place of it.

What should a grant log contain?

One agent, one resource, one action, one window and one named approver, with the credential referred to by name rather than by value. It should let a reader tell the agent's action from a person's, because a log that cannot make that split cannot support a claim about what the agent did. A grant that names a shared login or a whole account answers a different question. Ask for the tool version and run date beside it, because the fields a tool writes change.

What about credentials an agent reads in the terminal or a local file?

That path is outside a browser control and needs its own evidence: the sandbox configuration, the secret manager's access log and the permissions the agent ran under. The claim can still be supported, but with those artifacts rather than a page record. Mixing the two paths in one answer is how a review ends up with a transcript search standing in for a design. The two rarely appear in the same review, which is itself the finding.

Who should approve the use of a production credential?

A named person with authority over the service, not the agent and not a shared role. The approval should name the action, the destination and the moment, and it should be taken outside the page the agent was reading, since a dialog the agent's page draws is a dialog the page can forge. A shared role leaves the record pointing at nobody in particular, and that is the first question an assessor asks. The approver's name belongs in the same record as the token that was rendered.

What should I hand an auditor for one agent run?

Five artifacts: the grant, the transcript, the pages as rendered, the destination record, and the approval with a name and a time. Add the read date of every vendor page you relied on, because a capability marked in progress today may ship next quarter. An auditor who can see all five can test the claim; one who receives only a transcript is being asked to accept an absence. Keep the set in one folder with the run date on each, so it can be retested.

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 Makes One Agent's Run Provable Without the Production Value

A claim about exposure is only as good as its record, and the identity frameworks, placeholder gateways and transcripts reviewed above do not record what the model read.

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

Before, the agent pressed Reveal on the production settings page, read the connection string, and carried it into its context and summary. Inside the governed environment, the model sees DATABASE_001 there, and the real value reaches the database only on a named engineer's approval.

RedactSure is deploying now with enterprise and government customers. Sonatype found 56% of first-quarter 2025 malware related to data exfiltration.

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

See it on your own workflow

An auditor will ask about specific runs, not about the tool in general. Bring a task that touches a production settings page and see, with test values, the record of what the model read and who approved the change. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.