Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
How Do I Secure the Credentials of a Coding Agent I Built Myself?
Give the agent a reference and keep the value in an adapter outside its process, where a developer-signed grant can scope the credential to one service, one resource and one short lifetime. Then check who approves each consequential call the adapter makes and what record of it remains.
A team that writes its own coding agent inherits a decision that packaged tools make quietly: what the agent holds when it acts. The agent is a graph of nodes, a prompt and a set of tools, and somewhere in that graph a value has to be handed over before a repository call or a deploy. The shortest path puts a token in an environment variable and lets the process read it, and from then on the model's context, the run's transcript and every file the agent writes are exits for a value meant to stay in one place.
The record on this page is a LangGraph agent that opens a pull request through an adapter: the agent composes the change, the adapter holds the repository credential, and the two meet at one call. That record is useful because the agent's own code settles three things at once, which value the process can reach, what the grant allows and who approves the call that spends it. Least privilege, the rule most teams reach for first, governs actions and credentials, and What Is Least Exposure? sets out what it covers and the part of the exposure it leaves to a control that acts on the screen.
Key findings
- For a self-built agent to hold nothing worth taking, the model works on a consistent token such as DEPLOY_REF_001, and the real credential resolves inside an adapter the model cannot read (What Is a Protected Browser for AI Agents?).
- It also takes a named person approving each consequential call and a record of what the model received, because a run without human validation is what FINRA's 2026 oversight report calls "AI agents acting autonomously without human validation and approval," a risk it lists in its own right (FINRA, 2025).
- The framework defaults do not supply that layer: a 2026 gap analysis looked across "LangGraph, CrewAI, AutoGen, and the Model Context Protocol (MCP) authorization model" and found that "three provide no built-in confinement and one only partial" (Dantuluri and Sundi, 2026).
- Arcade's guide to agent authorization puts the question as "Can this agent, acting for this user, perform this action on this resource?" and does not explain how the token behind the answer is stored (Arcade, 2025).
- AWS's AssumeRole documentation states that the call "Returns a set of temporary security credentials that you can use to access AWS resources," a credential minted per call rather than stored, though the session policy can only narrow what the role already allows (AWS, 2026).
- A scan of 400TB of web data found that "11,908 Live Secrets were detected using TruffleHog in 400TB of web data", the population a value enters once an agent prints it to a log or commits it (Truffle Security, 2025).
What does a coding agent I built myself hold, and what can it read?
Start with the scope, because the answer depends on where the agent works. A governed browser environment covers what an agent reads and does on a rendered page: the token page in a repository's settings, a cloud console's access-key page, a hosting dashboard. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, and a self-built agent spends most of its hours there.
A value can sit in three places. The first is the process: a token in an environment variable, an entry in a config file, a profile the SDK picks up by default. The agent's code reads it before any model call, and no page has to render. The second is the context, where whatever the model reads can be repeated in a summary, written to a transcript or pasted into a commit message. The third is the page itself, where a settings screen shows a token it has just created, and GitHub's guidance to treat access tokens like passwords is a warning about that screen (What Can an AI Agent See in Your GitHub Settings?).
The record here, a LangGraph agent that opens a pull request through an adapter, keeps the three apart. The agent's node composes a branch name, a title and a body, then calls the adapter. The adapter holds a token limited to one repository and one operation, the instruction behind GitHub's token page: choose the minimal permissions necessary (How Do I Give a Coding Agent Read-Only Access to One Repository?). Here the value never enters the first or the second place unless someone puts it there.
Why should the agent hold a reference instead of a credential it can read?
The agent gets a name it can call and nothing it can spend: a function such as open_pull_request, an endpoint, a grant identifier. The value sits with the adapter outside the agent's process, which checks each call against the grant before using it. Coder advises separate identities with limited scope for agents, and an adapter holding a repository-scoped token does that (How Do I Let a Coding Agent Open Pull Requests Without Giving It My Credentials?). Only 1 of the 6 coding agents describes withholding the real value, while all 4 sandboxes describe a placeholder or proxy design (Can AI Coding Agents Read Your API Keys?).
Arcade's guide puts the grant question at call time: "Can this agent, acting for this user, perform this action on this resource?" (Arcade, 2025). AWS makes the shape concrete: a session's permissions are "the intersection of the role's identity-based policy and the session policies," so a grant can only narrow what the role already holds (AWS, 2026). The same post adds that "Even if a user can delete files in Drive, their agent should only get read access unless deletion is explicitly needed" (Arcade, 2025).
The lifetime is where grants are usually left loose. AWS's page says the duration "can range from 900 seconds (15 minutes) up to the maximum session duration set for the role", and that "Role chaining limits your AWS CLI or AWS API role session to a maximum of one hour" (AWS, 2026). One pull request needs minutes; a week-long token is a standing credential. Splitting build from deploy is the same move (How Do I Let a Coding Agent Deploy Without Giving It Deployment Credentials?).
Injection is the vendor-side version. Doppler's page says to "Give every coding agent its own scoped, read-only, expiring set of credentials" and that values are "Injected at runtime instead of written to a .env, so agents can't read, log, or commit them" (Doppler, 2026). Whether the agent can read those variables itself is not on the page, which decides the layer: injection leaves the value in the process, and a separate adapter leaves it outside.
What do the vendors themselves say?
The vendor pages describe five layers of control, and the table sets what each documents beside what a builder should verify.
| Layer | What the documentation states | What to verify |
|---|---|---|
| Call authorization | "Can this agent, acting for this user, perform this action on this resource?" (Arcade, 2025) | Who answers it, and what is recorded |
| Injection | "Give every coding agent its own scoped, read-only, expiring set of credentials" (Doppler, 2026) | Whether the agent can read them itself |
| Path rule | A Read deny rule such as Read(./.env) (Anthropic, 2026) |
Whether it covers a subprocess that opens the file |
| Command approval | "By default, terminal commands need your approval" (Cursor, 2026) | What approval covers when nobody is watching |
Anthropic's Claude Code documentation is clearest about paths. To keep the file tools out of a file, "add a Read deny rule for its path, such as Read(./.env) or Read(./secrets/**)" (Anthropic, 2026). The page says a project's .claudeignore file "has no effect" and that the rules "don't apply to a command that reads files without naming them," so the rule covers the file tool and not a subprocess (Anthropic, 2026). A path rule states where the agent may look; it does not hide a value from a script that reads the file.
Cursor's page governs the other end, the action. "By default, terminal commands need your approval" and "All MCP connections need your approval" (Cursor, 2026). The same page warns that "AI can behave unexpectedly due to prompt injection, hallucinations, and other issues," and it describes run modes as "best-effort guardrails rather than a hard security boundary" (Cursor, 2026). That is an approval model stated plainly: it stops a call, and it depends on someone being present to see it.
None of the five describes what the model reads on a rendered page after the call is authorized, and the authorization decision, the temporary credential and the injected value all govern what the process may spend.
What should I ask for in writing before I ship the agent?
The memo for a self-built agent is short, because the builder answers most of it alone.
- What does the model receive from each rendered screen the agent opens, and which values are replaced before it reads them?
- Which credential does the agent's process hold at each step, and can the adapter alone use it?
- What does the grant name, including resource, operation and lifetime, and who signed it?
- Who approves a consequential call, and is the approver outside the model's control?
- What record exists of one run, screen by screen and call by call, and can it be exported to the team's own logging?
The first question is the one a builder can answer alone. Open the settings page the agent uses, list every value visible on it, and mark which ones the task needs. Anything the task does not need is exposure a render-layer control can remove, and a study of agentic coding editors that found "attack success rates can reach as high as 84% for executing malicious commands" is why the grant matters more than the model (What Does Least Privilege Look Like for Coding Agents?).
The check cannot sit with the model. Veracode's research reports that "Our research reveals GenAI models make the wrong choices nearly half the time, and it's not improving" (Veracode, 2025). FINRA's 2026 oversight report flags that agents "may act beyond the user's actual or intended scope and authority," and warns that "Complicated, multi-step agent reasoning tasks can make outcomes difficult to trace or explain, complicating auditability," which is the reconstruction problem the record has to answer (FINRA, 2025). The fourth and fifth answers are what an auditor reads later.
What does a governed environment change?
A governed environment acts on the third place, the screen, before any model reads it. Values a policy names are replaced with consistent tokens on the rendered page, so the token page shows TOKEN_001 rather than the value, and the model composes the pull request against it. The real value resolves only at the approved destination, at the moment of an approved action, so the adapter receives it and the context never does. A named person approves each consequential action, and every screen as tokens, call and approval is written to a record the organization exports to its own monitoring. The bar it is built to meet is the one a 2026 gap analysis sets: "a correct system is one in which a fully prompt-injected agent still cannot exceed the authority explicitly delegated to it" (Dantuluri and Sundi, 2026).
For this page's record the change is specific. Before, the model reads the token on the settings page and can carry it into the pull request body, a commit message or its own transcript. Inside, the page renders TOKEN_001, the request that names the token carries TOKEN_001, and the real value reaches the adapter when the person approves the call. The adapter answers what the run may spend; the render layer answers what the model ever saw.
The scope stays the rendered page: the terminal, the IDE, the local filesystem, direct API calls and MCP are outside it, which is why the adapter and the grant carry the rest of the answer. Where the two meet is the category this page has described, and the comparison with one authorization vendor sets the two side by side (RedactSure vs Arcade: 2026 Comparison & Alternative).
What the record shows
What the screen shows, what the adapter may spend and who approves the call decide whether a self-built agent's credentials survive a bad run. On this record the value can sit in the process, in the context or on the page, and the adapter and the grant answer the first two only if the value never enters them. The framework defaults do not confine the run, the vendor pages describe controls that each govern a call or a path, and none describes what the model reads on the screen where a call is drafted. The builder should test it by naming one agent and one task, running it once with a test value, and writing down which component held the value at each step, what the context contained when the call went out, and who approved it. The step where the value first appears in the context is the one to fix.
Methodology and limitations
This page rests on vendor documentation from AWS, Anthropic, Cursor, Arcade and Doppler, a preprint gap analysis of agent authorization, FINRA's 2026 annual regulatory oversight report itself, a vendor research post from Veracode and a credential scan from Truffle Security, plus two RedactSure research pages. Pages were read between October 20, 2026 and October 22, 2026, and each Sources line carries the date for its page. Documentation read in full gives a sound view of where each product applies its control.
No product on this page was tested for this page; the products are described from 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 LangGraph agent and the adapter describe a record type, not an organization. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing replaces a pilot of one workflow on the organization's screens.
Frequently asked questions
How do I secure the credentials of a coding agent I built myself?
Give the process a reference and keep the value in an adapter outside it, then limit what the adapter may spend with a grant that names one resource, one operation and a short lifetime. A named person approves each consequential call, and the run leaves a record of what the model received. The order matters: the adapter and the grant answer what the run can do, and a render-layer control answers what the model ever saw on a page.
Should my agent read a credential, or only a reference to one?
Only a reference, where the service allows it. A token in the process is readable by every line of code the agent runs, including code it generated, and the context repeats what the model read. An adapter that holds the credential and validates the call keeps the value out of both. Where a service offers no adapter, a short-lived credential scoped to one operation is the next best shape.
What should the adapter log for each credential it uses?
The grant it acted under, the resource and operation the call named, the time and the outcome. Add the identity of the person who approved the call where one was required, the reference the adapter resolved, and the record of what the model received if the call was drafted from a rendered page. A log that shows the value itself defeats the design, so record the reference and never the value.
Who approves a consequential action in an agent I built?
A named person outside the model's control, not the agent reviewing its own plan. The approval should arrive before the adapter uses the credential and should say what the call will do, to which resource and under which grant. A confirmation shown to whoever asked for the action is a safeguard for that person; a run that writes, deploys or deletes needs an approver whose decision sits outside the transcript.
Does LangGraph or CrewAI ship a credential layer?
Not one that confines the run by default, from the pages reviewed. A 2026 gap analysis looked across LangGraph, CrewAI, AutoGen and the MCP authorization model and found three with no built-in confinement and one partial. The frameworks give you the graph, the model call and the tools, and the adapter, the grant and the approver are code you write. Hardened deployments can close the gap; the defaults do not.
What does the model receive when the agent opens a settings page?
Whatever the page renders, unless something replaces values before the model reads it. A token page, a console's access-key page or a build log reaches the context as it is drawn, so a value on that page can be repeated in a summary, a commit message or the next request. The control that changes this substitutes consistent tokens at the render layer and resolves the real value only at the approved destination.
How RedactSure Keeps the Token Off the Page the Agent Reads
The grant and the adapter decide what the run may spend, and a token on a rendered settings page enters the model's context. AWS's reference states a session lasts from 15 minutes to the role's maximum.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the token page, the model reads the value, and the pull request body carries it into the transcript. Inside: the page renders TOKEN_001, the permission planner encrypts the value to the developer's P-256 key and releases it after a separate approval, and the private adapter makes the authorized request. Every screen, call and approval lands in the AI Control Record.
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
Whether the value ever reaches the model is the part a self-built agent's design decides. Bring one repository task and see, with test values, the page as the model receives it, the approval and the record. Book a demo