Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Prove a Credential Was Never Exposed to an AI Agent?

Prove it with a record produced by design: the model received a reference such as GITHUB_TOKEN_01, the real value resolved only at the destination a named person approved, and transcript, call record and approval agree. Ask for the transcript, the call record and the approval, and check that the same reference appears in each.

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

A security lead asked to prove a credential was never exposed is being asked to prove a negative, and the evidence teams reach for first does not do it. A secret scan reports what it found in the places it covers. An audit log reports calls that were made. Neither says what a model received while a page was on screen, which is the question the title asks. What supports the claim is a record produced by the design that made it true: the agent held a reference such as GITHUB_TOKEN_01 on every screen, the real value resolved only at the destination a named person approved, and the transcript, the call record and the approval can be read side by side. The decision is which of those artifacts to require before anyone signs the claim. The example throughout is one record type: a transcript from an agent that opened a repository settings page, holding GITHUB_TOKEN_01 and nothing else. The distinction matters because most exposures that end in an incident are found as copies, in a commit, a log or a paste, after the reading that produced them.

Key findings

  • Cognition's Devin guide states that credential scopes include one "scoped purely to the current session and are not saved for any future sessions" and that "All secrets are encrypted at rest," while the page does not say what the model receives (Cognition, 2026).
  • AWS's AssumeRole reference states that the call "Returns a set of temporary security credentials that you can use to access AWS resources" and that a session runs "from 900 seconds (15 minutes) up to the maximum session duration set for the role," a window that bounds a leak but not a reading (AWS, 2026).
  • GitLab's documentation states that "Pipeline secret detection runs as part of a project's CI/CD pipeline" and that "You should always revoke and replace exposed secrets as soon as possible," a scan of commits that begins after a value is already somewhere (GitLab, 2026).
  • Wiz reports that "We looked at 50 leading AI companies and found that 65% had leaked verified secrets on GitHub," the copies a later scan is built to find, which are the ones that reached a repository rather than a context window (Wiz, 2025).
  • A governed environment replaces a value with a consistent reference before any model reads the screen, so the transcript holds GITHUB_TOKEN_01 and the real token never enters the context (What Is an AI Control Record?).
  • Real values resolve only at the approved destination, at the moment of an approved action, and the record names the person who approved it (What Is Supervised Delegation?).

What does a governed browser environment cover on a repository settings page?

On a rendered page, a governed browser environment covers what the agent reads and does: dashboards, consoles, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. That line decides what a nonexposure claim can cover. On the page, the claim is about what the model received from the rendered screen. In a shell, the value may be an environment variable the agent exports, and the browser control has no record of it. A team that wants one answer for the whole run needs one record for the page and another for everything outside it.

The worked record for this page is a repository settings page that shows a token field, the kind a run opens when it rotates a deploy key or checks an Actions secret. Whatever the browser shows, the model receives, so the question is whether the model receives the value or a reference to it; the page alone does not settle that, and the environment that draws the page does. A settings page is also where a durable credential tends to sit. Google's guidance for Workspace administrators says the super admin account should be used only when needed, a rule written for people that applies with more force to an agent holding a page open (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?).

The scope also sets the test. If the run used only the rendered page, one record can carry the claim. If it also used a shell command, a file in the tree or a direct API call, those routes are outside the record and outside the claim.

Surface Covered by a browser record What the record can show
Repository settings page Yes The screen the model received, the reference in the field, the approval
Terminal command No A shell history or process log, if the team keeps one
Local file read No File access logs, where the platform keeps them
Direct API call No The audit log at the destination

What does scanning for the credential prove, and what does it leave open?

A scan is a search over a surface, and its result is a statement about that surface. GitLab's documentation states that "Pipeline secret detection runs as part of a project's CI/CD pipeline" and that "You should always revoke and replace exposed secrets as soon as possible," a control that starts after the value is somewhere (GitLab, 2026).

The scale of what leaks is the argument for keeping it. Wiz adds that "Almost two-thirds of the AI companies analyzed had a verified secrets leak" (Wiz, 2025). OWASP's CI/CD guidance says "Prefer using temporary credentials over static credentials" and "Detect secrets pushed to and stored on code repositories" (OWASP, CICD-SEC-6, 2026). A repository scan can show that a copy reached a commit; it cannot show that a value never reached a screen, because a value read on a page need not be written anywhere.

A scan that finds nothing shows only that the scanner found nothing in its scope, and the scope excludes the transcript, the summary the model wrote and the message it drafted. GitGuardian's data, as reported by Help Net Security, counted "24,008 unique secrets exposed in MCP configuration files," a count of copies in files, not of values a model read (How Do You Let an AI Agent Manage API Keys Without Reading Them?).

What do the vendors themselves say?

The pages reviewed describe custody and lifetime, not a record of what the model received.

Cognition's Devin guide states that "In the browser, Devin types the value directly" and that "For shell commands, it binds secrets as environment variables whenever needed," two routes in which the agent's own process handles the plaintext (Cognition, 2026). It also describes a session scope "scoped purely to the current session and are not saved for any future sessions" and says "All secrets are encrypted at rest," which governs where the value persists, not what the model receives.

AWS's AssumeRole reference describes a temporary credential whose permissions are "the intersection of the role's identity-based policy and the session policies" and whose session can run "from 900 seconds (15 minutes) up to the maximum session duration set for the role," with role chaining capped at one hour (AWS, 2026). That limits how long a leaked credential is useful. It does not record what a model saw. OpenAI's Codex cloud page, marked Legacy, states that credentials "are only available to setup scripts" and "are removed before the agent phase starts," a design that keeps the value out of the agent's reach, and the same page warns that "Environment variables are set for the full duration of the chat (including setup scripts and the agent phase)" (OpenAI, 2026).

For the browser path, the model-facing record is not described in the pages reviewed. The vendors document where the value is stored, how long a credential lasts and which process holds it.

Vendor page What it documents What it leaves open
Cognition, Devin secrets Session scope, browser typing, shell variables, encryption at rest What the model receives on the browser path
AWS, AssumeRole Temporary credentials, policy intersection, 15 minutes to the role maximum, one-hour role chaining What the agent read before the credential was issued
OpenAI, Codex cloud (Legacy) Credentials removed before the agent phase, variables set for the full chat Whether a variable carries a value the agent can print

What has to be in the record for a nonexposure claim to hold?

A claim that a value was never exposed names its surface and its evidence. The surface is the rendered page; the evidence is four artifacts produced during the run, not reconstructed afterward: the policy that says which fields are references, the transcript the model received, the resolution to the real value, and the approval.

The transcript is the first artifact and the easiest to read. It should contain the reference, such as GITHUB_TOKEN_01, wherever the value would have appeared, on every screen of the run. A transcript that contains the reference on the settings page and the value in a later summary has failed. The resolution record is the second: the destination the real value traveled to, the time, the action it was used for and the reference it was resolved from. It should not contain the value itself, because a record that holds the value is another copy.

The approval is the third, and it is where most deployments are weakest. Most enterprise agent deployments cannot name the person accountable for a given agent action, and after an incident that absence becomes the first audit finding (What Is Supervised Delegation?). A policy approval is not a person; the record should name someone who saw the action and the destination. The policy is the fourth: without the rule it applied, a record cannot show that the reference was the intended treatment of that field.

Read together, the four answer the question: what the model received, what the environment did with the value, and who answered for it. A record that answers all three is checkable; one that answers two is a log.

Artifact Question it answers What a clean example shows
Policy Which fields are references The token field is mapped to a reference for this task
Transcript What the model received GITHUB_TOKEN_01 on every screen, and no value
Resolution record Where the real value went api.github.com, at the approved minute, for the rotation
Approval Who answered for it A named engineer, the action and the destination

How do you test a nonexposure claim on one run?

Name one agent, one task and one credential, and run it against a settings page that renders the value. Then read four things: the transcript, the resolution record, the approval and the policy. Search the transcript for the value and the reference on every page of the run, including pages that echo the token.

Compare the resolution record to the approval. The destination should be the one the approver saw, the time inside the approval, and the action described. A resolution to a host nobody approved is a failed test even if the transcript is clean. If the run also used a shell, a file or a direct API call, the browser record cannot answer for those. Check the credential before the run: AWS's guidance strongly recommends not creating access keys for the root user (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?).

GitGuardian's 2026 report, as summarized by CIO Dive, counted about 29 million credentials leaked on public GitHub in 2025, and its CEO said that "AI agents need local credentials to connect across systems" (GitGuardian, 2026). A tool that redacts sensitive data and blocks leakage in real time, as the SentinelOne page describes Prompt Security, changes what leaves the tool and does not record what the model received before the block (RedactSure vs SentinelOne Prompt Security: 2026 Comparison & Alternative).

What does a governed environment change?

It changes what has to be true before the claim can be made. A governed environment replaces the values a policy names with consistent references before any model reads the screen. Real values resolve only at an 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 own monitoring.

The effect on evidence is structural. The transcript cannot contain the value on the covered surface, because the value was never rendered to the model. The resolution record comes from the layer that resolved the value, not from logs assembled afterward, and the approval is attached to the action when it happens.

OWASP's LLM02 entry states that disclosure "can result in unauthorized data access, privacy violations, and intellectual property breaches" (OWASP, LLM02:2025, 2025). Greshake and colleagues showed that indirect prompt injection lets adversaries "remotely (without a direct interface) exploit LLM-integrated applications," so what a model holds is what an attacker can reach (Greshake et al., 2023).

A regulated analogue makes the same point. The minimum necessary standard at 45 CFR 164.502(b) requires reasonable efforts to limit protected health information to what the purpose needs, and as Can Staff Use AI on Patient Records Without PHI? describes, a full patient screen makes that showing hard while tokens make it direct.

Methodology and limitations

This page rests on vendor documentation from Cognition, AWS, OpenAI and GitLab, two OWASP entries, a CI/CD risk list, industry research from Wiz and GitGuardian, and a 2023 preprint on indirect prompt injection, together with existing pages on the control record and on approval. Vendor and standards 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. The GitGuardian figures are the ones its press release states, as carried by CIO Dive and cited as reported rather than as independently measured. The Wiz figure covers the 50 companies it examined and is not a rate for the industry.

RedactSure did not test any of the named products hands-on. Where a page does not describe behavior, this page says so and does not infer the behavior; "not described in the pages reviewed" refers to the recorded facts for that page. Vendor features change, and the page carries its date, so a release after that date should be treated as unreviewed until the test above is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a transcript from an agent that opened a repository settings page, and not an organization.

Determinations about whether a run, a control or a record satisfies a contractual, regulatory or audit 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 test token on a test settings page, repeated after each release.

What the record shows

A scan cannot prove a negative about a model's context: it searches surfaces, and the context is not one of them. The answer that holds is that a design can make the negative true on a stated surface and produce the record that shows it. On a repository settings page, the value is either rendered to the model or replaced by a reference, and the artifacts that follow, the transcript, the resolution record, the approval and the policy, either agree on the reference or they do not. RedactSure's environment is built to produce the second case, on the rendered page and not outside it. Whoever signs off on the claim should test it by running one agent through one task against a settings page that holds a real token and ask for the transcript, the resolution record and the approval; if the value appears once, or the destination was not the approved one, the claim fails, and a clean repository scan will not save it.

Frequently asked questions

Can I prove a credential was never exposed to an AI agent?

Yes, if the claim names its surface and comes with a record from the run. The record shows the model receiving a reference such as GITHUB_TOKEN_01, the real value resolving only at an approved destination, and a named person approving the action. A negative claim about a context window is only as good as the design that kept the value out. A scan afterward cannot make that claim, because it searches files and logs rather than the context the model held. Ask for those three and read them together.

Does a clean secret scan count as evidence?

It is evidence about the surfaces the scanner covers. Pipeline detection reads commits and build output, so a clean result says those contain no matching credential. It says nothing about a transcript, a summary or a page the model read, and it cannot show that a value was never rendered. Nor can it tell a value that was blocked from one that was never in the context. Treat it as one line in the record, with its scope stated, and do not let it stand in for what the model received.

What should the transcript show?

References, on every screen where the value would appear. The token field should read GITHUB_TOKEN_01, and a later page that echoes the token should read the same reference. A single occurrence of the real value anywhere in the transcript, including in a summary the model wrote or a commit message it drafted, defeats the claim. A summary is part of the record even when no page displays it. Read the pages after the settings page as well as the one where the value was used.

What does the approval add that the transcript does not?

The transcript shows what the model received. The approval shows who answered for the action that used the real value, and when. It should name a person, the action and the destination the person saw, not a policy or a role. Most deployments cannot name that person, which is why the approval is usually the artifact that fails first when a team runs the test. It also ties the resolution to a time, which a policy cannot do.

Does a short-lived credential make the proof unnecessary?

No. A short session limits how long a leaked credential works, and AWS's AssumeRole documentation puts the range at 15 minutes to the role's maximum, with role chaining capped at an hour. It does not change what a model read while the credential was live, and it does not produce a record. A shorter window narrows the claim; it does not evidence it. Expiry lowers the cost of an exposure; it does not show that none happened.

What if the agent also used a shell or a direct API call?

Then the browser record answers only for the rendered pages, and the rest of the run needs its own evidence, such as shell history, process logs or the audit log at the API destination. State the split in the claim before a reviewer asks for it, and keep the two records together. A record that covers the settings page and not the terminal is useful; a claim that implies it covers both is not, and a reviewer will find the gap.

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 a Nonexposure Claim Checkable

Most controls can show that a credential was used but not whether the model read it, and proving that takes a record of each page.

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

Before: the agent opens the repository settings page, the token field renders the value, and the transcript can carry it into a summary. Inside: the same page renders GITHUB_TOKEN_01, the real value resolves at api.github.com when a named person approves the rotation, and the transcript carries the reference. The approval names the person, the action and the destination.

RedactSure is deploying now with enterprise and government customers. Wiz found verified credentials leaked by 65% of the 50 leading AI companies it examined.

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

See it on your own workflow

Proving a credential was never exposed takes a record of what the model received. Bring a rotation task and see, with test values, the record that names the person, the action and the destination. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.