Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does HashiCorp Vault Keep the Raw Token Out of a Coding Agent's Hands?
No: HashiCorp's own agent tutorial has the agent read the GitHub token with a Vault read and starts that agent with a delegated VAULT_TOKEN exported into its environment, so the value arrives in the process the model runs in. The scope and the minutes bound what the token can do, not what the model holds.
Platform and application security leads at companies where a coding agent already has write access to repositories are deciding whether a vault read is the control they think it is. A coding agent that opens a pull request needs a GitHub token, and the usual way to keep it out of a repository is to have the agent fetch it from a vault at run time. HashiCorp publishes that walkthrough, and reading it closely shows what the arrangement settles and what it leaves open. The tutorial keeps the token out of the repository and the configuration file, then hands it to the agent when the task asks. Three properties carry the claim: the token expires in minutes, the policy names one path, and the value is fetched only when it is needed. None of the three decides what the model holds after the read, and the answer to the title sits in that gap. The worked record is the tutorial's own ghp_ token, a GitHub token an agent is asked to use for one repository task, followed from the wrapper script that starts the agent to the transcript the run leaves behind.
Key findings
- For the raw token to stay out of the agent's hands, the value the agent reads would have to arrive as a consistent token, with the real GitHub token released only at the approved destination (What Is Least Exposure?).
- It would also require a named person approving each read that returns a real value, and a record of what the model received beside the action (Can a Credential Vault Protect What an AI Agent Reads?).
- HashiCorp's tutorial describes the token's scope, its lifetime and the script that hands it to the agent, and it does not describe a step that keeps the value out of the agent's context after the read returns (HashiCorp, Secure, 2026).
- The tutorial states that "Token lifetime is reduced from days or weeks to minutes" and that the agent "receives a token that is read-only, repo-only, scoped to a single secret, and short-lived" (HashiCorp, Secure, 2026).
- In a study of contextual integrity, GPT-4 and ChatGPT "reveal private information in contexts that humans would not" in 39% and 57% of cases, the risk a value carries once the model can repeat it (Mireshghallah et al., 2024).
- GitHub's Actions reference advises "good security practice to set the default permission" for the GITHUB_TOKEN "to read access only for repository contents," the same narrowing the tutorial applies (GitHub, 2026).
What does the agent receive when it runs a Vault read?
A governed browser environment covers what the agent reads and does on a rendered page, including dashboards, consoles, settings pages and forms. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, and the tutorial's read happens in a command, outside that boundary. The answer turns on what the vault hands the agent.
The record is the tutorial's ghp_ token: a coding agent asked to use one repository, a GitHub token held in Vault, and a wrapper script that starts the agent with a delegated credential. The wrapper "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent" (HashiCorp, Secure, 2026), so the environment the agent inherits already carries a credential the vault will accept. When the agent runs the read, the response prints into the session that writes files and composes the next prompt, and the token is in the model's context from that point.
The review did not score Vault; its six coding agents all describe credentials in environment variables the agent can read (Can AI Coding Agents Read Your API Keys?).
Vault's own framing is about reach: the agent "receives a token that is read-only, repo-only, scoped to a single secret, and short-lived" (HashiCorp, Secure, 2026), and read from the agent's side, the same sentence describes what it holds. A policy that narrows a token to one path does not change the fact that the token is a value the model can repeat, and a repository-scoped GitHub token is a password for that repository (What Can a Hijacked Coding Agent Do With My GitHub Token?).
What changes when the token is scoped and short-lived?
Three controls appear in the tutorial, and each answers a question other than what the model holds. The lifetime is the first: Vault reduces it "from days or weeks to minutes," a real reduction in the window a leaked token is useful and none at all in what the running model has read. The policy is the second: one path, one operation, read-only, which bounds what the token can do if it is used for the wrong purpose. The delegated token is the third, issued for the agent's own use.
Follow the value after the read and the controls separate. A lease can expire; the string in the transcript does not. Revoking the token ends its use at the vault and does not reach a log line, a commit message or a summary the model already wrote.
Two OWASP entries frame the two halves. Excessive agency names "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs" and lists excessive permissions among its root causes (OWASP, LLM06, 2026), which is the remedy the tutorial applies. Sensitive information disclosure stands beside it: "Personal identifiable information (PII) may be disclosed during interactions with the LLM" (OWASP, LLM02, 2026), a warning about the interaction rather than the store. A GitHub token is not personal data, and disclosure happens where the model reads.
What do the vendors themselves say?
HashiCorp documents the handover precisely enough to answer the title. The tutorial's token "is read-only, repo-only, scoped to a single secret, and short-lived," the lifetime "is reduced from days or weeks to minutes," and the launch step is a script that "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent" (HashiCorp, Secure, 2026). Those words put the credential in the agent's environment before its first step, and a process that can read its own environment is the ordinary case.
Amazon's design shows the same division of labor from the other end: the AgentCore Identity token vault is built to "Securely store OAuth 2.0 Access and Refresh tokens, API keys, and OAuth 2.0 client secrets," and the agent retrieves them with its own workload token (Douglas, 2025). The vault holds the value, the agent receives it, and the design is custody of a store, not of a context.
GitHub's Actions reference covers the permission side: it calls it "good security practice to set the default permission" for the GITHUB_TOKEN "to read access only for repository contents" (GitHub, 2026). A read-only token an agent holds is still a token the agent can use, so the guidance narrows what it may do and says nothing about what the agent knows.
| Dimension | HashiCorp Vault, per its documentation | What a buyer should verify |
|---|---|---|
| Where the value is kept | In Vault, behind a policy that names a single path | Which paths the agent's token can read |
| How far it reaches | "read-only, repo-only, scoped to a single secret, and short-lived" | Whether one token can serve several repositories |
| What the page says about the model | Nothing about the model's context | What the record shows after the read |
None of the three describes a control over what the model reads once the value is in the process, which is the surface the title turns on.
What does the transcript record after the read?
Vault keeps a record of the read, and the record is about the request. The tutorial's token carries a policy and a lifetime, so the vault can show that a client authenticated and read one path. Its log does not show what the process did with the string. A transcript from the agent run holds that half, which is why a review that reads only the vault log has seen the fetch and not the exposure.
Telling the agent not to print the token is an instruction, and the research on web agents suggests how much that carries. In a benchmark of safety and trustworthiness for web agents, "their average CuP [Completion under Policy] is less than two-thirds of their nominal completion rate" (Levy et al., 2026), so an agent that can finish a task often fails the policy attached to it.
Detection is the next layer a team reaches for, and it runs after the value moves. GitLab's secret detection "runs as part of a project's CI/CD pipeline" (GitLab, 2026), which finds a token that reached a commit and does not prevent the read that put it in the model's view. Detection and rotation follow the exposure; neither prevents it.
The gap survives review because the control looks complete from the outside: a policy, a lifetime and a scoped token are visible in the vault, and none of them is a statement about the model's context.
What does the agent read on the page where the token is issued?
The tutorial's read is one path to the value; a rendered page is the other. A GitHub token is created on a settings page that displays the new value, and an agent asked to set up its own access reads that page with the model watching. No vault sits in that flow.
The 2026 agent platforms built their controls around that path: a placeholder the agent holds, and a real value substituted at the destination once the action is authorized (Can a Credential Vault Protect What an AI Agent Reads?). Where the substitution sits decides coverage, and a vault's unit of adoption is an integration, so coverage equals the integration list (Data Privacy Vault or Screen-Level Tokenization?).
A shorter-lived credential narrows that gap without closing it. A GitHub App installation token "will expire after 1 hour" (How Do I Give a Coding Agent Access to GitHub Without a Personal Access Token?), a smaller blast radius for a value the model still holds. Masking inside a sandbox comes closer, with a placeholder in the command's view, a proxy substituting the real value for approved hosts, and plain values for reads outside the sandbox (How Do I Keep API Keys Out of Claude Code's Context Window?).
What does a governed environment change?
A governed environment acts where the page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the run, so the agent works on GH_TOKEN_01 and the model never receives the string. Real values resolve only at the approved destination, at the moment of an approved action. A named person approves each consequential action, and 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 it moves the decision a layer earlier. A vault answers who may fetch a token and for how long; a render-layer control decides what the model sees when the token appears, whether the value arrives from a vault read or from a settings page. One is custody of a value, the other of what the model reads, and the tutorial's read is where the two meet.
The scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a vault read stays the vault's to bound, and the screen an agent reads is where this control applies. The comparison for this vendor sets out the difference row by row (RedactSure vs HashiCorp Vault: 2026 Comparison & Alternative).
What the record shows
What a model holds after a read is decided when the value is placed in its view, and the tutorial places it there on purpose: the agent is the client, the token is the answer, and the scope limits what the token can do. That improves on a token in a configuration file, and it leaves the value in a context that produces files, commits and summaries. A team can settle it with a two-part test. Ask an agent to perform the tutorial's task with a stand-in token, read the transcript for the string the vault returned, then compare that with the vault's log. The log shows one authenticated fetch; the transcript shows where the value went next.
Methodology and limitations
This page rests on HashiCorp's agent permissions tutorial, Amazon's AgentCore Identity post, GitHub's Actions reference, GitLab's secret detection documentation, two OWASP entries and two studies. Vendor pages were read between October 20, 2026 and October 21, 2026, and each Sources line carries its date. Public documentation read in full gives a sound view of where each product applies its control.
No product on this page was tested for it. "Not described in the pages reviewed" means the recorded pages for that product do not address the point, not that the product cannot; vendor features change, and the page carries its date. The example describes a record type, not an organization. RedactSure is deploying now with enterprise and government customers. Determinations belong to counsel, assessors and the organization's own security officers, and nothing replaces a pilot of one workflow.
Frequently asked questions
Does HashiCorp Vault keep the raw token out of an agent's hands?
No. The tutorial has the agent read the token with a Vault read and starts the agent with a delegated VAULT_TOKEN in its environment, so the value arrives in the process the model runs in. The scope is read-only, one path and minutes long, which limits what the token can do and does not remove it from the context. A control that keeps the raw token out has to decide what the model receives, and the tutorial describes the fetch instead.
What does the agent receive when the tutorial runs a Vault read?
The value the path holds, printed into the session the agent is working in. The delegated token authorizes the read, the policy decides which path, and the response returns the GitHub token to the process that asked. From that point the string is available to the model alongside the task, the files and the command output, and any later step can copy it into a commit, a comment or a ticket. The vault's log records the fetch; the transcript records where the value went.
Does a short lifetime keep the value out of the model's context?
No. Minutes shorten how long the token can be used and do not shorten the run. A value the model has read stays in the conversation, and a summary, a commit message or a later prompt can carry it after the lease ends. Rotation after the run limits the damage a leaked token does, and it happens after the exposure. The lifetime is a control on validity, and the context is a separate question.
What record does Vault leave of what the agent read?
A record of the request. The vault can show that a client authenticated and read one path under a policy with a lifetime; it does not show what the process did with the value. The agent's transcript holds that half. A review that wants both should keep the vault log beside the transcript and compare the timestamp of the read with the sentences that follow it. The two records together describe the fetch and the exposure, and neither one alone does.
Does the raw token appear on a page the agent reads?
Yes, on the page that shows it. A token created on a settings page is displayed there, and an agent asked to set up its own access reads the value with the model watching. No vault call sits between the render and the model. That surface belongs to a render-layer control rather than to a store, which is why the two controls fit different halves of one workflow.
Who approves a Vault read, and when?
An administrator, in advance. The policy attached to the delegated token decides which path the agent may read and for how long, and the read either matches the policy or fails. No person acts at the point of reading. A named approver deciding each consequential action is a separate control, and the tutorial does not describe one. The name behind the policy was written before the run began.
How RedactSure Keeps a Read Token Out of the Agent's Context
A vault read hands the agent a value it can repeat, and a scoped token limits what it can do rather than what the model saw. HashiCorp's tutorial reduces the lifetime "from days or weeks to minutes," which leaves the transcript untouched (HashiCorp, Secure, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent opens the repository's token settings page and the page draws the ghp_ value for the model to read. Inside the governed environment, that page shows GH_TOKEN_01, and the real value waits for a named person's approval.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A token an agent fetches stays in its context for the run. Bring one token and the task that needs it, and compare what the model read, who approved the change, and what the record kept. Book a demo