Keeping Your Keys Away From Your AI

RedactSure Developer Workspace: the agent works with a reference while credentials remain outside the sandbox.

Why coding agents create credential risk

Claude Code, Codex, Cursor, and Aider can work with local code without broad service credentials. But cloning private repositories, pushing changes, creating cloud resources, or opening documentation behind a login may require tokens, keys, or sessions. Giving an agent those credentials expands what it can do and what a compromised agent could expose.

Developers may store credentials in.env files, shell environments, or agent configuration. Broad, long-lived tokens avoid repeated setup, but they can allow far more than an individual task requires. A token with write access to every repository presents a different risk from a read-only token for one repository.

The consequence of a stolen token is not limited to the exposure of the token string. Depending on its privileges, an attacker could use it to retrieve private source code, invoke APIs, access cloud resources, or read confidential records. A reusable credential may allow repeated access until it expires or is revoked. The scope of that credential determines what else is exposed.

Agents also read material they do not control: dependency READMEs, web pages, issue reports, and server logs. That material can contain instructions designed to redirect an agent. Anthropic's security documentation says its protections "significantly reduce risk" and that "no system is completely immune to all attacks." OpenAI's discussion of browser-agent security says prompt injection "is unlikely to ever be fully 'solved'."

The risk comes from combining access to credentials with instructions embedded in untrusted material. Researchers who tested twelve published defenses reported an "attack success rate above 90% for most" in their evaluation. Separately, Wiz reported that 65% of fifty leading AI companies had leaked verified secrets on GitHub. The Wiz finding concerns exposed secrets; it does not establish that coding agents caused the leaks.

Security teams can prohibit agents, require frequent human approvals, or accept the exposure. Each approach either limits automation or leaves some credential risk. Developer Workspace instead separates the agent's work from the credential used to access a service.

Keeping credentials outside the agent sandbox

The developer's private key is the root of authority. When a secret appears in the protected browser, it is encrypted. The agent receives a reference such as [ GITHUB_TOKEN_01 ] instead of the value. A real credential is used only by an approved execution environment, within the scope and lifetime of a developer-signed grant.

This is an access boundary rather than an instruction telling the model to behave safely. If malicious content redirects the agent, it cannot disclose a credential that was never placed in its sandbox. A private adapter handles an approved operation under a signed grant. Keeping the reusable credential out of the agent also prevents it from being copied and used independently to access other resources covered by that credential.

Four components of Developer Workspace

Developer Workspace uses four components with separate responsibilities.

Protected browser. It detects credentials, personal data, and private business data as they appear on screen. The agent's view substitutes a placeholder while the real value is encrypted to the developer's P-256 public key. Only approved destinations may receive a protected value, and submitting one requires separate permission. The agent sees a reference it can use to request capture, not the underlying string.

CodeCells. A CodeCell is a sandboxed execution environment on a machine chosen by the developer: a laptop, a private server, or a cloud account. Teams can use their existing agent harnesses, CLIs, Git, and other tools. A CodeCell receives access only to the services the task needs. The private adapter handles credentials outside the agent sandbox and returns results such as repository files.

Permission planner. It converts a plain-language request such as "give my coding agent read access to this repository" into a reviewable grant. The grant specifies the service, resource, operation, destination, and lifetime. Planning uses metadata about accounts and secrets, not the secret values.

TrustGate. The developer's private key signs each grant. TrustGate verifies the authorized connections and encrypts traffic between the planner, browser, and CodeCells. Each component separately enforces its permissions. Root keys remain on the developer's client and are not available to the agent.

Figure 1. Four components, with authority rooted in the developer-held private key.

GitHub token: capture to authorized use

A GitHub token shows the process from creation to an authorized repository read.

First, the agent creates a GitHub token through the protected browser. When the token appears on the settings page, trusted browser code captures it and encrypts it to the developer's P-256 public key. The agent sees [ GITHUB_TOKEN_01 ] and continues without receiving the plaintext token.

Second, the encrypted token arrives in the developer's own client, where the matching private key opens it locally for review. If approved, the token is saved in the encrypted Vault. The Vault uses local AES-GCM encryption with a key derived from the Vault password. At this stage, no agent or CodeCell has been granted permission to use the token.

Third, the developer approves one CodeCell to read a specific repository for the current run. After that separate approval, the client re-encrypts the credential for the enrolled CodeCell's TrustGate public key. The planner produces a grant covering the service, resource, operation, destination, and lifetime; the developer reviews and signs it. The developer's private root keys remain in the local client.

Fourth, the approved CodeCell receives and decrypts that delivery. A private adapter outside the agent's sandbox uses the token for the authorized, read-only GitHub request. The agent receives repository files, not the token itself. The grant is limited to the authorized run.

Figure 2. One token moves through capture, safekeeping, a signed scoped grant, and private-adapter use.

Saving a token does not itself give an agent access to it.

What happens during prompt injection

A repository README can carry an instruction telling the agent to post its GitHub token to an external URL. If the agent follows it, the value available to it is [ GITHUB_TOKEN_01 ], not the underlying token. The real credential remains outside the agent sandbox and is used separately by the approved CodeCell adapter.

Figure 3. An injected instruction requesting the GitHub token reaches a placeholder rather than the underlying credential.

This control does not depend on the model recognizing the malicious instruction. It prevents that instruction from extracting the underlying reusable credential through the agent's context. A stolen credential could provide direct access to private source code, cloud services, and other API-accessible data beyond the one approved task.

With the read-only grant in this example, the agent can retrieve repository files and inspect the code. Opening a pull request or making changes would require separately approved permissions. The developer does not have to enter the secret into the agent environment; the signed grant provides a reviewable record of the repository, destination, operation, and lifetime authorized.

Who it is for

Developer Workspace is intended for engineering teams using agents to open pull requests, run tests, browse authenticated documentation, and create cloud resources. It is particularly relevant when security policies prohibit putting GitHub tokens, cloud keys, passwords, or customer data directly into agent environments.

The research behind it is on the RedactSure site. Start with What Is a CodeCell?, What Is a Permission Slip for an AI Agent? and Why Should the Developer's Private Key Be the Root of Authority for Agents?. For the problem itself, read How Does Prompt Injection Get Into a Coding Agent? and Can a README Hijack My Coding Agent?. For the walkthrough of the token above, What Happens When an AI Agent Creates a GitHub Token in the Browser? and How Do I Keep Credentials Outside the Sandbox Where the Agent Runs?.

Pilot availability

RedactSure is onboarding a limited number of technical teams as early design partners. Deployments remain in pilot, with supported harnesses and services prioritized based on partner feedback. Teams evaluating the workspace can sign up, install a CodeCell, and connect an existing agent.

RedactSure controls what sensitive information an agent can see and which credential-backed operations it can perform under a signed grant.

Read: What If the Agent Never Had Your Data?

See the workflow

A demonstration can use an existing agent and a repository whose credentials the team does not want to expose. Book a demo

Sources

1. Anthropic, "Security," Claude Code Docs. https://code.claude.com/docs/en/security. The sandbox and permission-prompt model, and the statement that "no system is completely immune to all attacks."
2. OpenAI, "Continuously hardening ChatGPT Atlas against prompt injection attacks," December 22, 2025. https://openai.com/index/hardening-atlas-against-prompt-injection. Prompt injection "is unlikely to ever be fully 'solved'."
3. Nasr, Carlini, Sitawarin, Schulhoff et al., "The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks and Prompt Injections," arXiv:2510.09023, October 2025. https://arxiv.org/abs/2510.09023. Twelve published defenses bypassed with "attack success rate above 90% for most."
4. Wiz, "Exposure Report: 65% of Leading AI Companies Found with Verified Secret Leaks," November 10, 2025. https://wiz.io/blog/forbes-ai-50-leaking-secrets.
5. RedactSure, Charles Curt's Developer Workspace HTML design preview, October 2026. Component descriptions, P-256 capture, local Vault encryption, TrustGate grants, and the read-only GitHub walkthrough.

About the author

Charles Curt is the founder and CEO of RedactSure. He developed the company's render-layer protection and interface-level encryption architecture, which lets AI agents work with protected references instead of exposing sensitive values directly to models. His background includes user-interface encryption and secure AI deployment in healthcare, insurance, finance, and the public sector. His work on Developer Workspace extends that approach to developer credentials, signed permission grants, and sandboxed agent execution. RedactSure team biography.