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 Used?

Only a broker that logs each release can tell you which credential an agent used; an agent holding credentials in its own environment leaves you grepping transcripts. Ask for one grant record from a real run and check that it names the credential, the resource and the account.

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

The question arrives after the work is done, which is the worst time to answer it. A finished run leaves a diff, a transcript and a service log: the diff shows the change, the transcript shows what the model read, and the service log shows that a valid token arrived, not whose it was or which grant released it. Evidence has to come from the component that held the credential and handed it over, because every other account of the run describes the agent's own view. This page takes that problem in order. The first section sets the boundary of what a credential record can cover and where a browser-scoped record stops. The second works through one record type, a per-grant log, entry by entry. Then come the vendor pages, which describe where a credential is kept and less often where a release is written down, followed by the limits of a transcript as evidence and the question of who is named as the actor. The closing section describes the control class that produces a complete record, and the standard is simple: a reader who was not in the room should be able to reconstruct the release from the entry alone. For the broader question of which pages and records an agent reached, How Do You Know Which Pages and Records an AI Agent Accessed? covers that ground; this page stays on the credential.

Key findings

  • Vault's tutorial for giving an agent scoped access states that "the agent receives a token that is read-only, repo-only, scoped to a single secret, and short-lived" (HashiCorp, 2026).
  • 1Password's post on its OpenShell integration states that "inside the sandbox, the agent sees placeholders rather than real credentials" (1Password, Secure agent, 2026).
  • Arcade frames the authorization question as "can this agent, acting for this user, perform this action on this resource?", and those three identifiers are the minimum a grant record has to carry (Arcade, 2025).
  • AWS's Agentic AI Lens asks teams to separate agent and human permissions so that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026).
  • A governed environment replaces values with consistent tokens before any model reads the screen, so a coding agent works with GITHUB_TOKEN_01 and the credential itself never enters its context (What Is an AI Control Record?).
  • Real values resolve only at the approved destination at the moment of an approved action, and every release lands in a record that exports to the customer's own monitoring (What Is Supervised Delegation?).

Which parts of an agent's run can a credential record cover?

The record can only describe what the environment sees, so the first question is where the credential was used. A governed browser environment covers what an agent reads and does on a rendered page: a repository settings page where a deploy token is created, a cloud console where an access key is listed. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. An agent that exports a token from a shell or presents one in an HTTP call from its own runtime is outside that boundary, and its evidence is whatever the shell history or the service's log kept.

On a page, the environment draws the screen and can record what it drew and which control was pressed. In a shell it sees a process, and process output is not a page. So the answer has two halves: a per-grant record for the page, and logs the team assembles from services it already runs.

This page uses one record type, a per-grant log: an entry written at the moment a credential is released, holding fields a reader can check afterward. One agent may work through a rendered console and through an API in the same task, and the record should say which half it covers. The API path has its own treatment (How Do You Let an AI Agent Manage API Keys Without Reading Them?). The same bundling appears in access design, as How Do You Give AI Agents Access to Workflows Without Exposing Sensitive Data? sets out.

What does a per-grant log record that an environment variable cannot?

An entry is useful when it answers four questions without relying on the agent's own account: which agent acted, for which person, with which credential, against which resource, and when. Arcade's framing supplies the first three, and the fourth is the service's identity for the thing touched.

Take one entry from a repository settings page, where an agent rotates a deploy token. It records the running agent and its key fingerprint, the person who delegated the task, the credential as a stable reference rather than its value, the repository and environment, the action, the approval and the timestamp. A reader can reconstruct the release without holding the credential.

Field What it settles What an environment variable usually leaves out
Agent identity Which agent presented the credential, not only which person owns the account The variable is inherited by whatever the agent starts, so the record names a container or a login
Acting person Who delegated the task and who approved the change A shared variable carries no binding to a person
Credential reference Which credential was released, without reproducing it The variable is the credential, so any log that quotes it becomes a leak
Resource and action What the credential was used for and where The service log records the call, not the grant behind it
Time and expiry Whether the use fell inside the window the grant allowed Expiry is rarely written at the point of use

The alternative is what most teams use. Credentials are injected into the environment, and the only record of use is a transcript that may not contain the credential, because a model that follows its instructions does not print credentials. Doppler documents the pattern: values are "injected at runtime instead of written to a .env, so agents can't read, log, or commit them" (Doppler, 2026). It is an improvement over a committed file that also removes the evidence.

The Vault tutorial shows the same shape. Its wrapper script "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent" (HashiCorp, 2026). A short lifetime limits the damage a leak can do; it does not record which grant was used for which call.

What do the vendors themselves say?

Teleport's Agentic Identity Framework states that agents need "a verifiable, cryptographic identity tied to where they're running, not a shared API key," and lists "comprehensive audit trails and behavior analysis for agent actions across infrastructure," though most listed capabilities are marked "In-progress" or "Not started" (Teleport, 2026).

1Password's OpenShell integration shows the agent placeholders, and a gateway swaps in the real value only for an approved host, with no per-use record described (1Password, Secure agent, 2026). Its Browserbase release says "Secure Agentic Autofill allows AI agents to authenticate with web services without ever exposing credentials," and that credentials are "not shared with the LLM or exposed in Browserbase logs and repos," a statement about where a credential does not appear, not what a use leaves behind (1Password and Browserbase, 2025).

Arcade's example is a Drive agent that "should only get read access unless deletion is explicitly needed" even when the person can delete files, so the scope limit has to exist before a log can show it was applied (Arcade, 2025). The distinction is set out in RedactSure vs Arcade: 2026 Comparison & Alternative.

Composio notes that a user can hold several connected accounts "even for the same toolkit (e.g. work and personal Gmail)," so a log that names the user cannot say which account was used (Composio, 2026). Doppler does not say whether the agent can read the variables injected into its own process, which is not described in the pages reviewed.

Dimension What the vendor documents What a buyer should verify
Teleport Cryptographic agent identity; audit trails listed, most capabilities in progress Whether the audit entry names the credential and the grant, not only the workload
1Password Placeholders in the sandbox; a gateway releases a real value only to an approved host; stored by reference Whether each release is written with the agent, the host and the time
Arcade Per-user, per-resource authorization; scope limits such as read-only Drive access Whether an export names the acting person and the resource
Composio Several connected accounts per toolkit; automatic token refresh Which account a tool call used when more than one is connected
Doppler Per-agent scoped, expiring credentials injected at runtime Whether the agent can read the injected values, and where the use is written

Why is the agent's own transcript the weakest evidence?

A transcript is a record of what the model read and wrote, produced by the system under examination. It is incomplete by design, because a model that never prints a credential leaves no trace of it. It is easy to misread, because a token name in the text is not a token presented to a service. Grepping it answers a different question: did the string appear, not which grant released it.

The approval side has the same weakness. An OWASP community page on HITL dialog forging describes an attack that "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations" (OWASP Foundation, n.d.). An approval record produced by the interface that was manipulated is not independent evidence of what the person saw.

Shared identities show the scale of the alternative. Datadog reports that "37 percent of customers who send CloudTrail logs to Datadog are using IAM users in their GitHub Actions," a shared identity that makes the log name the account rather than the run (Datadog, 2025). One IAM user is one identity for every workflow, so the log can say a key was used, not which run used it.

The transcript is also what an attacker reads. A measured environmental injection attack on generalist web agents reached an attack success rate of up to 70 percent in stealing users' specific personal information, as Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity? sets out.

Who is named when an agent uses a credential?

Attribution has two names, and most logs carry one. The first is the agent: not the model, but the running instance with an identity of its own, which is what Teleport's framework asks for when it says agents need "a verifiable, cryptographic identity tied to where they're running, not a shared API key" (Teleport, 2026).

The second is the person who delegated the task and approved the release. That person is named only if the delegation is recorded: the task, the applications, the values that may be tokenized, the actions that need approval. Otherwise the name in the log is whoever owns the account.

AWS's guidance makes the separation explicit. Its Agentic AI Lens asks teams to separate agent and human permissions so that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026).

Naming the person is not enough if the person holds more than one account for the same service. The entry has to name the connected account. An agent given a durable cloud key acts as the key's owner in every log the provider keeps, as Is It Safe to Let an AI Agent Set Up Your Cloud Environment? sets out.

What does a governed environment change?

A governed environment changes where the record is written. Instead of reconstructing a run from a transcript afterward, the environment that renders the screen writes the entry at the moment of the release. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the model works with GITHUB_TOKEN_01 and the real value never enters its context. Real values resolve only at the approved destination, at the moment a named person approves the action. Every screen as tokens, every action and every approval goes into a record that exports to the organization's own monitoring.

Three properties follow. The record is contemporaneous, written when the release happens. It is complete for the page, because the environment drew the screen and knows which field held which token. And it is checkable, because the destination is recorded alongside the approval, so a reviewer can compare it with the service's own log.

The boundary is the same one stated earlier. The record covers the rendered page and the actions taken on it; it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A team reading a per-grant log should ask which of its agent's steps fall inside that boundary, because the log will be silent on the rest. Silence is not absence, and a record that does not say what it excludes invites the reader to assume more than it shows.

Methodology and limitations

This page rests on vendor documentation from Teleport, 1Password, Arcade, Doppler, Composio and HashiCorp, one OWASP community attacks page, AWS Well-Architected guidance, one vendor research report from Datadog, 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 reproduced in the wording of the page that states them, and where a page marks a capability as in progress, the page says so rather than treating it as shipped.

RedactSure did not test any of the named products hands-on. The vendor pages describe where a credential is kept and how it is presented; whether a release is written down, and what the entry contains, is not described in the pages reviewed, which is the gap this page is about and not a finding about any one product. Vendor features change and the page carries its date; a release after that date should be treated as unreviewed until the test below 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 per-grant log for a deploy-token rotation on a repository settings page, and not an organization.

Determinations about whether 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 review of the organization's own agent, its credential store and the logs it already keeps, repeated after each change to the agent's permissions or to the services it can reach.

What the record shows

The pages reviewed converge on one point. A credential kept away from an agent is not the same as a credential whose use is recorded: placeholders, proxies, short-lived tokens and per-agent scopes all reduce what a leak costs, and most of them leave the evidence to the service's own log. The record that answers the title question is written at the release point, names the agent and the person, and states the resource and the action. RedactSure's environment is built to write that entry from the rendered page. One agent and one credential are enough for the test: run a task that uses the credential on a page the agent renders, then ask for the entry that names the credential, the destination and the approver. If the answer is a transcript, the organization is reconstructing evidence rather than keeping it.

Frequently asked questions

How do I find out which credentials a coding agent used?

Start with the component that held the credential, not with the agent. A broker, vault or gateway that released the value should be able to show a per-use entry naming the credential, the agent, the person it acted for and the destination. If no component released it because the credential was already in the agent's environment, the service's own log is the only witness, and it will show a valid key rather than the run that used it. The destination matters as much as the credential.

Is grepping the agent's transcript enough?

No, for two reasons. A model that follows its instructions does not print credentials, so the absence of a string proves nothing, and a model that does print one leaves a copy wherever the transcript is stored, which turns the search into a new exposure. The transcript records what the model read, not what a service accepted. Use it to see what the run was asked to do, and use the release log to see what it presented. Keep the transcript for intent, not for proof.

Does a short-lived token solve the problem?

It reduces the window, and that is worth having. A token that expires in minutes cannot be replayed tomorrow, and a read-only scope limits what a stolen one can reach. Neither property records which grant was used for which call. The Vault tutorial's scoped token still arrives in the agent's environment, so the evidence question remains the service log's, which names the key and not the run. Ask the vault what it wrote about the lease.

What should one entry in a per-grant log contain?

Five things at a minimum: an identifier for the running agent, the person who delegated the task, a stable reference for the credential rather than its value, the resource and action it was released for, and the time with the grant's expiry. A sixth field, the person who approved a consequential action, is what makes the entry usable in a review. An entry missing the credential reference cannot distinguish two credentials used in the same session. Agree the field list before the first run begins.

Who counts as the actor when an agent presents a credential?

Two parties, and a usable record names both. The agent is the party that presented the credential, which requires an identity of its own rather than the person's login. The person is the party who delegated the task and approved the release, and that approval belongs to the action rather than to the session. AWS's guidance puts the split in design terms: separate permissions so the log can attribute each action to one actor. The two names are not interchangeable in a review.

Does a credential vault already answer this?

Partly. A vault holds the credential and can issue a short-lived credential on request, which keeps the long-lived value out of the agent's reach, and its own log records that a lease was issued. What the vault usually cannot see is the destination: the agent takes the leased credential and presents it wherever it likes. The question is whether the vault's log and the service's log can be joined on one identifier. Join them on the grant identifier, not on the person.

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 a Credential Release Into a Record

The credential is released before any component that keeps a record sees it, whether a gateway swaps a placeholder or a scoped token is handed to a process.

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

Before: the agent opens a repository's deploy settings and reads the token on the page. Inside: the page renders GITHUB_TOKEN_01, and the real value reaches the repository only when a named person approves the rotation.

RedactSure is deploying now with enterprise and government customers. Datadog found 37 percent of sampled customers running GitHub Actions on IAM users, one identity across many runs with no way to tell them apart.

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

See it on your own workflow

When an incident review asks which credentials an agent used, a record answers faster than a log search. Bring a rotation task and see, with test values, the approval the record keeps. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.