Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Vault Audit Show What an AI Agent Did With a Credential?
No, because Vault's audit records the fetch and not the use: it names the token, the path and the time, and the delegated token ties that read to the agent. Check what happened to the value on the hosts that received it, because the record ends at the read.
An agent that needs a deploy credential can fetch it from Vault, use it for a few minutes, and never touch a configuration file. The review that follows asks a narrower question than whether the fetch was allowed: which systems the value opened after it arrived, and who can prove it. A Vault record answers the first part well, because the read is an event the server sees, with a token, a path and a lease attached. The run itself happens where Vault has no vantage point, in the agent's process, in the commands it builds and on the hosts the credential unlocks. One credential, fetched once and used on three hosts, shows the shape of that gap.
For a security team, the practical question is what a reviewer can reconstruct from the Vault log after an agent has held a production value, and whether the answer would hold up in an incident review. Vault logs reads, so the fetch itself is covered by the server's record. The gap is everything that follows it: the systems that see the value and the systems that do not, what the vendor pages describe, and the record a buyer should ask for when the use has to be provable.
Key findings
- For a Vault audit record to show what an agent did with a credential, the value would have to reach the model as a consistent token rather than itself, released only at the approved destination (What Is an AI Control Record?).
- It would also require a named person approving each release and a record that joins the read to the destination the value reached (What Is Supervised Delegation?).
- Vault's pages record the fetch and do not describe a record of the client's use of the value afterward; the audit ends at the vault door (HashiCorp, Secure, 2026).
- HashiCorp's tutorial hands the agent a token that is "read-only, repo-only, scoped to a single secret, and short-lived," and the wrapper script "exports it as VAULT_TOKEN, and launches the agent" (HashiCorp, Secure, 2026).
- The lease is the part HashiCorp documents in most detail: "All dynamic secrets in Vault are required to have a lease," and revocation "invalidates that secret immediately and prevents any further renewals" (HashiCorp, Lease, 2026).
- AWS's Well-Architected guidance asks audit logs to "attribute every action unambiguously to either an agent or a human actor," a standard the vault record meets for the fetch and for nothing after it (AWS, 2026).
What does a Vault audit entry capture when an agent fetches a credential?
The fetch is the part of the run Vault sees. A client presents a token, asks for a path, and the server answers with a value and a lease. HashiCorp's tutorial is built so that the client is the agent rather than the engineer: a wrapper script "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent" (HashiCorp, Secure, 2026). The token is issued to the agent, scoped to a single path and valid for minutes, which is what makes the read attributable at the vault (HashiCorp, Secure, 2026). A reviewer can tell an agent's fetch from the engineer's own because the requests carry different tokens, which is more attribution than most credential stores offer.
What the entry contains is a request: the path, the identity behind the token, the time, and the lease. The tutorial states that "Token lifetime is reduced from days or weeks to minutes," which bounds the window without changing where the value goes (HashiCorp, Secure, 2026). Validity is the subject, and use is not.
The edge of the log is the edge of the server: Vault sees a request it answered and cannot see a command it never received. A record of what the model saw is a different artifact, described in What Is an AI Control Record?, and it has to be produced where the reading happens.
Where does the record stop when the fetched token is used on three hosts?
Take one record type: an agent asked to rotate a release credential, which fetches the value and uses it on three hosts, a build runner, a web host and a batch worker. Vault records one read. Each host authenticates the credential against its own service and logs the request in its own format.
The Vault entry can show that the agent read the path at 14:02, and when the lease expired. It cannot show that the value was copied into a deploy script, sent to the second host over SSH, or pasted into a ticket. Those events are visible, if at all, in three separate logs with no shared identifier.
A model that holds a value can reproduce it where a person would not: GPT-4 and ChatGPT "reveal private information in contexts that humans would not" in 39% and 57% of cases (Mireshghallah et al., 2024). Work on information flow states the risk structurally, that "poisoned data retrieved from one component can change the model's behavior and compromise the entire system, including coercing the model to spread confidential data to untrusted components" (Siddiqui et al., 2025). A record of the retrieval is not a record of the flow.
The three hosts are where a reviewer's question lands, and How Do I Know Which Credentials a Coding Agent Has Touched? walks the same reconstruction for a repository token.
What do the vendors themselves say?
HashiCorp's tutorial is specific about the token the agent holds and quiet about the use that follows: it reduces the token's life "from days or weeks to minutes" and scopes it to a single path (HashiCorp, Secure, 2026). The page states what the agent may read and how long the credential lives, and nothing about where the value goes once the response returns.
The lease page is equally specific within its subject: revocation "invalidates that secret immediately and prevents any further renewals" (HashiCorp, Lease, 2026). The measurement is of time, and the destination is not in it.
AWS describes the same shape from the other side of the market: its security blog says the token vault is built to "Securely store OAuth 2.0 Access and Refresh tokens, API keys, and OAuth 2.0 client secrets," and that the agent retrieves them with its own workload token (AWS, 2025). A store that hands the agent a usable token has done its job at retrieval, and what follows belongs to the agent's run.
| Dimension | HashiCorp, per its documentation | What a buyer should verify |
|---|---|---|
| What the token reaches | "read-only, repo-only, scoped to a single secret, and short-lived" | Whether that scope covers every host the task touches |
| Who holds the value | The agent process, with the delegated token exported | Whether anything between the response and the use keeps the value out of context |
| What the record covers | The request: path, token, time and lease | Whether that entry is joined to a host log |
Which record answers the reviewer's question?
Two records are in play, and they answer different questions. The vault record answers who read what and when, which is attribution. An incident review asks what the credential did, which is consequence.
Does Cursor Keep an Audit Log of What the Agent Did? shows how far a tool's own log goes and where it stops, and the shape holds here: a log written by the system that issued a value cannot describe the systems that accepted it. The audit entry names the token and the path, the host log names the request, and the two share no identifier unless one was built.
A per-action record is not what most of the tooling an agent runs in documents: of the ten coding agents and sandboxes in the October 2026 review, 3 document a per-action audit record, and Vault is not one of the ten (Can AI Coding Agents Read Your API Keys?).
Harvard's guidance treats the surrounding material as part of the record: "Treat prompts, outputs, logs, and retained context as organizational data" (Harvard, 2026). That framing puts the agent's transcript inside the evidence set: a transcript shows what the model was shown, a host log shows what the credential opened, and neither is the record a reviewer needs unless something joins them.
Does HashiCorp Vault Keep Credentials Away From a Coding Agent? takes the question from the agent's side: the vault decides who may fetch a value and for how long, and the agent is the client that fetches it.
What would an approval add that the audit cannot?
An approval is a decision recorded before the use, by a person who can be named. The audit entry is written after the read, by the system that answered it. The first can stop a use; the second can only describe a fetch.
Harvard's guidance asks for the control directly: "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible" (Harvard, 2026). A credential released to an agent and then used on three hosts is such an action, and the approval that matters covers the use rather than the scope of the token.
Approval also has to sit outside the agent. Work on adaptive attacks found that stronger attacks bypassed 12 published defenses, with an "attack success rate above 90% for most" (Nasr et al., 2025). OWASP describes excessive agency as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM" (OWASP, 2025). A gate inside the model inherits those failures; a named person's approval does not.
Why Should Submitting a Credential Require Its Own Permission? makes the case for asking about the specific action, and the custody question is separate: encryption decides who can read a stored value, not who approved its use.
What does a governed environment change?
A governed environment moves the control to the place where the value would otherwise be read as itself: the page an agent renders. Values chosen by policy leave the render layer as consistent tokens, so a model working a hosting dashboard sees DEPLOY_TOKEN_01 where the credential sat. The real value resolves at the approved destination at the moment of an approved action, and a named person approves that action first. Every screen the agent read, every action and every approval lands in one record.
For the fetch in this page's record, that changes what the audit can be compared with. The vault still records the read. The governed environment records what the model received, which destination received the value and who approved it, so a reviewer can answer the three-host question without reconstructing three retention windows. Its scope is the rendered page, not the terminal, the IDE, the local filesystem, direct API calls or MCP.
The division makes the two controls complementary. The comparison for this vendor sets out where each one acts (RedactSure vs HashiCorp Vault: 2026 Comparison & Alternative). A vault governs custody and a governed environment governs exposure, and the record that answers the title question needs both.
What the record shows
An audit that ends at the vault door records custody: it can name the token, the path and the time, and it cannot name the host that received the value. The control that closes the gap sits where the value would otherwise be read: values on a rendered page replaced with consistent tokens before a model reads them, real values released only at an approved destination, a named person approving each release, and a record that joins the screen, the action and the approval. Vault's pages describe the first half of that chain precisely, and they describe it for the fetch alone. The difference shows up the moment a credential is used somewhere Vault cannot see. A team can run one test on its own system: pick one credential an agent fetches, list every host that authenticates it, then compare the Vault entry's timestamp with each host's log for the same hour. Where those logs cannot be joined, the audit stops at the vault door.
Methodology and limitations
This page rests on vendor documentation from HashiCorp and AWS, guidance from OWASP and Harvard University, and peer-reviewed and preprint research on information flow and model disclosure. The pages were read in full, and public documentation read in full gives a sound view of where each product applies its control. They 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 for it. The products are described from their public documentation, and "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 example describes a record type, not an organization. Compliance determinations belong to the organization's counsel and its own security officers, and nothing here replaces a pilot of one workflow.
Frequently asked questions
Does Vault audit show what an AI agent did with a credential?
No. It shows the read: the token, the path, the time and the lease, which is enough to attribute the fetch to the agent when the agent has a token of its own. What happened after the response returned is not in that record. The value was used somewhere, and the evidence lives in the logs of whichever host accepted it, if it was logged at all. A reviewer who needs the use has to look outside the vault.
Can a Vault audit tell an agent's read from an employee's read?
Only where the agent has a token of its own. HashiCorp's tutorial gives the agent a delegated token, exported as VAULT_TOKEN, so the requests carry an identity distinct from the engineer's. Without that separation, the read looks like the person's. The distinction is real and worth configuring, and it still describes only the fetch. The use that follows is not in the vault's record at all.
Does a short lease close the gap?
No. A lease bounds how long the value stays valid, and revocation ends that validity immediately. Neither says where the value went while it was valid. A credential used on three hosts inside its lease window is exactly the case a lease does not describe, because the window and the use are different facts. A short lease lowers the time an exposed value can be replayed, and it does not tell a reviewer which host received it.
What record would show what the agent did with the value?
One written where the value is used: what the model received on each screen, which destination received the real value, and who approved the release. Joined to the vault's read, that record lets a reviewer follow one credential from the fetch to the host. Without the join, the reviewer holds two records and no way to connect them. The join is a design decision, not a query a team can write after an incident.
Who should approve a credential release to an agent?
A named person, before the release, with the destination in front of them. The alternative is a policy written days earlier that the agent's request either matches or fails. Approval is a decision about this action; a policy is a decision about a class of actions. Both belong in the design, and only one of them leaves a name against the use. For a credential that opens three hosts, the person approving should know which host the run is about to touch.
Is Vault's audit enough for a compliance review?
Not on its own, for work that touches production credentials. It is strong evidence that the fetch was authorized and attributable, and it is silent on the use. A reviewer asking what an agent did with a credential will want the vault record beside a record of the screens and the approved destinations, and will want to know which of them the organization can produce. The gap is in the evidence, not the vault's diligence.
How RedactSure Records What a Credential Did After the Fetch
A Vault entry proves the fetch and says nothing about the three hosts the value reached, so the reviewer holds a read with no consequence.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent fetches the value and carries it while the consoles on those hosts render real records. Inside the governed environment, the hosting dashboard renders DEPLOY_TOKEN_01 where the credential sat, a named person approves the write on the second host, the value resolves there, and the record holds the screen, the approval and the destination.
RedactSure is deploying now with enterprise and government customers. HashiCorp's tutorial reduces the token's life "from days or weeks to minutes," the whole window a record of use would have to cover (HashiCorp, Secure, 2026).
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A fetched credential leaves one Vault entry and three unexplained uses on the hosts it reached. Bring one agent task and see, with test values, what the page renders, which action a person approves, and what the record joins. Book a demo