Give a coding agent credentials without handing over production

Give the agent an identity for the task, with access to named resources and a limited lifetime. Keep production credentials out of its execution environment. A secret hidden from a chat transcript can still be usable by the shell, an installed dependency or an MCP server. Credential handling therefore has two jobs: limit disclosure and limit what an authenticated operation can do.

Consider a hypothetical warehouse-service change. The agent needs to read one repository, run migrations against disposable stock records and open a pull request. It does not need the production database, permission to fulfil orders, or the developer's personal GitHub token. That distinction should survive even if a repository file tells the agent to “repair” its environment by fetching another credential.

Factory's September 2026 guidance makes the useful starting point explicit: scope files, commands, networks and credentials to the task rather than inheriting the launching developer's access. The rest of this article turns that principle into a proposed access record and rehearsal. It is not a report of a system NO FEED has tested. ^[1]

Write the permission before choosing the secret store

“Needs GitHub” is too broad to review. “Can read warehouse-service and create a patch branch there” is closer to an operation an administrator can authorize.

For the hypothetical migration, our proposed access record looks like this:

This table is a design proposal, not a promise that any named assistant enforces it automatically. A credential's scope must be checked at the service that accepts it. A tool named read_database cannot make an administrator credential read-only.

GitHub Apps provide a concrete narrowing mechanism. An installation access token can be restricted to selected repositories and a subset of the app's permissions; it cannot exceed the installation's access. The token expires after one hour. Omitting those restrictions gives the token the installation's full repository or permission scope, so the returned scope belongs in the record. ^[2]

For our example, this supports a dedicated repository identity. It does not establish whether that identity can merge, publish or bypass rules in the actual repository. Those are separate permissions to inspect.

Short-lived access still needs a narrow trust policy

GitHub Actions can exchange an OIDC identity token for temporary cloud credentials after a configured cloud provider validates the workflow's claims. This avoids keeping a duplicate long-lived cloud secret in GitHub. The cloud role remains responsible for deciding which resources the resulting credential can access. ^[3]

Expiry limits time; the role limits authority. A temporary credential that can alter production remains production access during its validity. For the warehouse task, the role should name the disposable environment and required operations, not the whole account.

The OIDC trust decision also needs the intended caller. GitHub documents claims identifying repository and execution context, including the subject. Granting id-token: write allows a job to request an OIDC token; it does not itself grant access to cloud resources. The cloud provider's trust conditions and role policy complete the decision. ^[4]

Our proposed record therefore includes the issuer, accepted audience and subject conditions, cloud role, allowed resources and expiry. Record identifiers and policy, never the token value. If a reviewer cannot explain which other workflows satisfy those conditions, the trust relationship is not yet precise enough to approve.

Check the process that actually receives the credential

On 9 October, Reddit user Stunning-Sherbet1853 reported that tests in a copy of their local agent's repository inherited a live database path; they also found a control token reaching child processes. They reported no data loss. In later replies, the author moved beyond a variable-prefix blocklist: application settings were removed from the ambient environment, and tests rejected database paths outside their temporary directory before opening them. The author explicitly said that the equivalent rejection was still missing from the real installation. This is a self-report, not a reproduced security result. ^[5]

An environment variable is a delivery mechanism, not an access boundary. Claude Code's current Bash-sandbox documentation says shell commands inherit its environment by default, including secrets. The default read boundary also includes most of the machine, including credential files. Its credential restrictions apply only to sandboxed commands. ^[6]

The same documentation distinguishes shell isolation from built-in file tools, hooks and MCP servers, which run outside that sandbox. To constrain the whole process tree, Anthropic points to an outer container, virtual machine or sandbox runtime. This describes documented boundaries, not proof that a particular container configuration is secure. ^[6]

For the migration task, begin with a clean runtime containing the repository and disposable fixtures. List the credential names passed to each child process, mounted credential locations, helper processes and permitted destinations. Do not diagnose this by printing the environment: that turns the review into another disclosure path.

Some systems mediate authenticated requests so the tool receives a placeholder while a trusted component supplies the credential. Claude Code documents such masking through its sandbox proxy, with destination restrictions and TLS requirements. That can reduce direct exposure; it does not make every permitted request appropriate. Its shell-only scope still applies. ^[6]

Test a refusal with disposable identities

Our proposed rehearsal uses a test account and synthetic data. First, run the intended migration and verify the fixture result through the application. Then attempt a harmless operation against a separate disposable resource that the identity must not reach. The expected result is a service-side refusal, not an explanation from the model saying it chose to abstain.

Repeat after the task ends or the credential expires. Check whether the launcher can silently obtain another credential and under what authority. If refresh is intended, the refresh path belongs in the same review; if it is not, the task should stop with an actionable authentication error.

Use service audit records to associate the observed operation with the task's identity and resource. Keep redacted error output alongside the result. GitHub warns that automatic log redaction is not guaranteed, particularly when secret values are transformed, and recommends reviewing both successful and failed runs. ^[7]

The warehouse agent can now finish its patch without a production identity. The release owner receives a reviewed revision through a separate path. Before the next run, remove one inherited credential that the task does not need—and verify that the intended work still succeeds without it.