Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Know Which Credentials a Coding Agent Has Touched?

Only when each credential passes through a component that records its use, such as a gateway or proxy that swaps in the real value at request time; an agent holding credentials in its environment leaves no record of which it read. Ask where each credential lives, what logs each use, and whether the log names the agent.

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

The question usually arrives after something has gone wrong: a leaked key, a token used from an unfamiliar address, or an auditor asking for every credential an agent could have read during a run. The answer depends on where the credentials were when the agent worked. A value placed in a process environment or a working-tree file is readable by anything in that process, and nothing in the process writes down which reads happened. A value held behind a gateway or proxy that substitutes it into outbound requests is different, because the substitution is an event the component can log and attribute. This page works through the record each arrangement leaves, using one record type as its example, an incident audit request covering a single repository and a single agent run. The decision a security team faces is whether its agents' credentials sit where each use is written down, because only that arrangement lets it answer an auditor from a record rather than from inference. Two pages frame the problem: What Is an AI Control Record? asks what the model saw and who answered for it, and How Do You Let an AI Agent Manage API Keys Without Reading Them? covers the design that keeps the value out of the agent altogether.

Key findings

  • GitHub's own token guidance tells users to treat access tokens like passwords and says each fine-grained token can be limited to specific repositories, which narrows what a token reaches but does not record which reads happened (GitHub, Managing, 2026).
  • 1Password's integration with NVIDIA OpenShell shows the agent placeholders rather than real credentials, and the OpenShell Gateway replaces a placeholder with the real value only when the agent sends a request to an approved host; the post does not describe independent testing of the integration (1Password, 2026).
  • Infisical's Agent Vault states that the agent should not be trusted with direct access to any credentials and terminates TLS so the proxy sees the request it injects into; the post does not claim the design fully prevents exfiltration (Infisical, 2026).
  • GitHub's secure use reference for Actions tells teams to audit how credentials are used and to set the default GITHUB_TOKEN permission to read-only for repository contents; it gives no YAML example for the permission block (GitHub, Secure, 2026).
  • A governed environment replaces credential values with consistent tokens before any model reads the screen, so a key shown on a settings page reaches the agent as a placeholder and the substitution itself is a logged event (What Is an AI Control Record?).
  • Real values resolve only at the approved destination at the moment of an approved action, which gives the record a named person for each use rather than a shared login (What Is Supervised Delegation?).

What record does an agent with credentials in its environment leave?

The scope of this page needs stating in plain words. A governed browser environment covers what an agent reads and does on a rendered page: a dashboard, a cloud console, a repository settings page, a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. Most coding agents touch credentials through those uncovered routes, so the answer comes from the credential tooling and not from a browser control.

In the common arrangement, a developer exports a personal access token into the shell, or writes it into a .env file, and starts the agent. GitHub tells users to treat access tokens like passwords, and its fine-grained tokens can be limited to specific repositories with the minimal permissions necessary, while infinite lifetimes are allowed unless an organization sets a maximum lifetime policy (GitHub, Managing, 2026). Each control narrows what the token can do. None records whether the agent read the token, printed it or passed it to a tool, because a process does not log its own reads of memory.

The same holds for a file. A read of a .env file by the agent's file tool is an ordinary read, indistinguishable from a read of any other file in the tree, and the only trace is whatever the agent later did with the value. That is why Infisical's Agent Vault post states that the agent should not be trusted with direct access to any credentials (Infisical, 2026). The design argument is about trust; the audit argument is its mirror: a value the agent held directly is one whose use nobody can enumerate afterward.

What do the vendors themselves say?

The vendors describe a common pattern with different edges. 1Password's post on its OpenShell integration says the agent can work with real systems without holding any credentials in its context, sees placeholders inside the sandbox, including one for its model key, and that 1Password stores the values by reference rather than by value; the post does not describe independent testing or audit of the integration (1Password, 2026). NVIDIA's OpenShell architecture page states that the openshell-sandbox component shares the boundary with the untrusted agent, so it never makes policy decisions, and the page does not explain how policies are written (NVIDIA, Architecture, 2026).

Infisical says a conventional proxy leaves the tunnel opaque, simply forwarding encrypted traffic, and that Agent Vault terminates TLS to solve it; the post offers no benchmarks and no production-readiness statement (Infisical, 2026). Arcade frames authorization as the question "Can this agent, acting for this user, perform this action on this resource?" and argues that an agent should get only read access to a drive unless deletion is explicitly needed; the post does not explain token storage or refresh (Arcade, 2025).

Vendor page What it documents What it leaves unaddressed
1Password with OpenShell Placeholders in the sandbox; substitution at an approved host Independent testing; the log of a substitution
NVIDIA OpenShell The sandbox never makes policy decisions How policies are written
Infisical Agent Vault TLS termination so the proxy sees each request Exfiltration guarantees; benchmarks
Arcade Per-action authorization for a named agent and user Token storage and refresh

Which designs produce a per-use record, and which only a per-grant record?

The useful split is between a record of grants and a record of uses. A grant record says a token with these permissions was issued on this date to this account. A use record says this agent, on this run, sent this value to this destination at this time. Only the second answers the title question.

A token in an environment produces only a grant record. GitHub's security guidance for Actions tells teams to pin actions to a commit SHA and to audit how credentials are used, and recommends setting the default GITHUB_TOKEN permission to read-only for repository contents (GitHub, Secure, 2026). The audit advice is the tell: the platform asks the team to audit because it does not see the use once the value is in the job.

A substituting gateway produces a use record by design. When the OpenShell Gateway replaces a placeholder with the real value only on a request to an approved host (1Password, 2026), the gateway is the one component that knows a real value left, and to where. A TLS-terminating proxy sees the request it injects into, which lets it associate a credential with a call, and a per-action question asked for a named agent and a named user ties each use to two identities. None of the pages reviewed describes the exact fields those components log, so the buyer's task is to ask for a sample record.

Arrangement Record it can produce Who appears in it
Token in shell or .env Grant only The person who created the token
Gateway substituting at an approved host Each substitution and its destination The agent and the policy
Per-action authorization broker Each authorized action The agent and the user

The design that keeps the value out of the agent is the one that produces the use record, the argument made in Does AWS Bedrock Keep Company Credentials Away From Agents?.

What does the public leak record say about credentials nobody knew were touched?

The leak data describes the aftermath of this gap. Wiz looked at 50 leading AI companies and found that 65% had leaked verified credentials in public repositories, almost two-thirds of the companies analyzed (Wiz, 2025). Those companies employ people who know what a credential is, and the leaks happened anyway, because a value in a working tree travels into commits without any component noting the move.

Agent-written code shortens the path. GitGuardian's test of GitHub Copilot found that over 1,200 repositories leaked at least one credential and that Copilot generated 3.0 valid credentials for one prompt on average; the post does not confirm whether the extracted credentials were still active (GitGuardian, 2025). The SecretBench dataset, built to study the problem, labels 97,479 credentials in source code of which 15,084 are true credentials, and the paper reports no tool evaluation (Basak et al., 2023). The ratio matters for the audit request: most strings that look like credentials are not, and the team needs a way to separate the real ones.

GitHub's controls catch the value on its way out, not in. Push protection scans code for hardcoded credentials at the time of the push (GitHub, Push, 2026), and the Actions secrets page instructs teams to mask sensitive values that are not GitHub secrets with ::add-mask::VALUE, and notes that secrets are not passed to the runner for a workflow triggered from a fork (GitHub, Using, 2026). Both act after the agent has already held the value. A masked log line shows the log would otherwise have carried the credential, which is evidence the job touched it, but not what the job did with it before the line was written.

How should a team answer an audit request after an incident?

Take the record type for this page, an incident audit request naming one repository, one agent and a date range, asking which credentials the agent could have read and which it used. The answer has three layers, and the team writes down which layer each credential falls in.

The first layer is inventory: every credential that was reachable from the agent's process during the run, whether in the environment, in files in the tree, in CI variables or on pages the agent opened. For a token in the shell, "reachable" is the only answer available. The second layer is use: for each credential behind a gateway, proxy or broker, the component's log of substitutions or authorized actions, with destinations and timestamps. The third layer is attribution: which identity each record names. A fine-grained token limited to specific repositories, as noted above, still names the person who created it when an agent uses it, so the attribution layer needs the agent's own identity from somewhere else.

The reason to assume the worst in layer one is the attack record. The Agent Security Bench authors report that their benchmark results reveal critical vulnerabilities in different stages of agent operation and limited effectiveness in current defenses (Zhang et al., 2025). An agent that can be steered by content it reads can be steered to read a credential, so a credential that was reachable has to be treated as touched unless a use record shows otherwise. What Can an AI Agent See in Your GitHub Settings? lists the pages where tokens are shown, and How Do You Know Which Pages and Records an AI Agent Accessed? covers the parallel question for records rather than keys. Rotate everything in layer one that has no layer two entry.

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 GITHUB_TOKEN_01 rather than the string. 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. 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, the change is that the substitution is an event. When an agent opens a repository settings page, a cloud console or a credentials dashboard where a key is displayed, the key never enters the model's context, and the record states which page was shown as tokens, which token stood for the key, whether the key was ever resolved, to which destination, and which named person approved the action that resolved it. That is the use record the environment-credential arrangement cannot produce, for the rendered-page route. How to Set Up S3 and GitHub With Cowork or Dots walks through a setup task where the console pages carry exactly those values.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so credentials reached through those routes still need the gateway, proxy or broker designs described above, and the audit request is answered by joining the two records. A team that has both can list each credential shown on a page and each credential substituted into a request; a team that has neither can list only what was reachable.

Methodology and limitations

This page rests on GitHub's documentation for personal access tokens, Actions secrets, secure use and push protection, vendor posts and documentation from 1Password, NVIDIA, Infisical and Arcade, two research preprints, two vendor research reports on leaked credentials and existing RedactSure research pages. Sources were read as of October 20, 2026. Quoted facts are cited to the page that states them, and the leak figures are cited as the publishing vendors reported them, not as independently measured. The two preprints are cited for the dataset and the benchmark result only.

RedactSure did not test any of the tools named here hands-on. The exact fields that a gateway, proxy or broker writes for each substitution or authorized action are not described in the pages reviewed, so the record each design can produce is inferred from the mechanism the vendor documents, and a buyer should ask each vendor for a sample. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, an incident audit request covering one repository and one agent run, and not an organization.

Determinations about whether a given record satisfies a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a rehearsal of the audit request on the organization's own setup: name one agent, one repository and one run, and produce the list of credentials reachable, used and attributed, since the gaps found in rehearsal are the gaps an incident finds later.

What the record shows

The documentation reviewed supports a plain answer. A credential placed in an agent's environment or working tree leaves a grant record and no use record, and the platform guidance that tells teams to audit how credentials are used confirms that the platform does not do it for them. A gateway that substitutes a placeholder at an approved host, a proxy that terminates TLS to see the request, or a broker that authorizes each action for a named agent and user can each produce a use record, though none of the pages reviewed shows the fields. The leak data shows what happens in the gap. To run this test, name one agent and one run, list every credential it could have reached, and count how many of those have a dated entry showing a use and a destination.

Frequently asked questions

Can I tell which credentials a coding agent read from its environment?

Not from the environment itself. A value exported into a shell or written into a .env file is readable by anything in the process, and nothing records the read. The only evidence is downstream: a commit, a log line, a tool call or a request that carried the value. After an incident, treat every credential that was reachable from the process as touched, rotate it, and move it behind a component that records each use before the agent runs again.

Does a fine-grained GitHub token solve the problem?

It narrows the blast radius, not the record. GitHub documents that a fine-grained token can be limited to specific repositories with the minimal permissions necessary, and that classic tokens are less secure. The token still sits wherever it is stored, its use in GitHub's own logs is attributed to the person who created it, and nothing on the agent's side records a read. Scope the token, set a lifetime, and then ask separately who logs its use and under which identity.

What does a credential gateway or proxy add?

A point of observation. When the agent sees a placeholder and a gateway swaps in the real value only on a request to an approved host, the swap is an event with a destination and a time, which a token in memory never produces. Infisical's post describes terminating TLS so the proxy can see the request it injects into. Ask each vendor for a sample of the log those events write, since the pages reviewed do not show the fields.

Why does masking credentials in CI logs not answer the question?

Because masking happens after the job has already held the value. GitHub's Actions guidance tells teams to mask sensitive values that are not GitHub secrets with ::add-mask::VALUE, which keeps the string out of the log. A masked line is evidence the job touched the value, and it says nothing about what the job did with the value before the log line was written. Masking protects the reader of the log and not the team answering the audit.

How should I treat a credential that was reachable but has no use record?

As touched. Benchmark research on agent security reports critical vulnerabilities across stages of agent operation and limited effectiveness in current defenses, so an agent that could be steered to read a credential may have been. Without a use record there is no way to show the opposite. Rotate the credential, note the date and the run in the incident file, and put the replacement behind a design that records each use so the next request has an answer.

What record does a governed browser environment keep for credentials on a page?

For a key displayed on a settings page or console, it records that the page was shown to the model as tokens, which token stood for the key, whether the key was resolved to a real value, to which destination, and which named person approved the action. That covers rendered pages only; credentials reached through a shell, a file, an API call or MCP still rely on the gateway or proxy record, and the audit joins the two.

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 Turns Every Credential an Agent Sees Into a Logged Event

A token in a shell or a .env file leaves a grant record and no use record, and the gateways reviewed miss keys shown on pages.

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

Before: the audit request names one agent and a date range, and the answer for a key the agent saw on a settings page is "reachable," so it is rotated. Inside the governed environment: the record shows the page as the model saw it, GITHUB_TOKEN_01 where the key sat, whether it was resolved, and the named person who approved it.

RedactSure is deploying now with enterprise and government customers. Wiz found that 65 percent of 50 AI companies had leaked verified credentials in public repositories.

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

See it on your own workflow

Knowing which credentials an agent saw is the first question after any incident. Bring a task your agent runs and see, with test values, the record that shows each page as the model saw it. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.