AI coding assistants can help developers understand code, investigate errors, and make changes faster. Some can also read files, run commands, access connected tools, and work through tasks with limited supervision.
That raises a practical security question: What can the assistant reach from the workspace where it runs?
A developer may need access to an API key to test an application. That does not automatically mean every process, extension, or assistant in the same workspace should have the same access. Before rolling out an AI-assisted workflow, I want to understand where credentials live, which processes can use them, and what happens if an assistant reads untrusted content.
Map the workspace before choosing a control
I start by identifying the boundaries around the development environment:
Where does the assistant run: a local machine, remote workspace, container, or vendor-managed environment?
Which files and directories can it read?
Can it run shell commands or install dependencies?
Which environment variables are available to its process?
Which external tools and services are connected?
Can it reach the internet or internal services?
Does it act with the developer’s identity, a shared identity, or a separate service identity?
What activity is logged, and who reviews it?
The answers depend on the product and its configuration. A chat feature that receives selected code has a different access profile from an agent that can execute commands in a development container.
I also want to know whether a workspace is persistent. A credential that is convenient to put in a file today may remain there after a project ends, a workspace is shared, or a backup is created.
Treat environment variables as accessible process data
Environment variables can be useful for passing configuration to an application. They are not, by themselves, a boundary between an application and every other process in a workspace.
If a coding assistant can run commands in the same context, it may be able to access variables available to those commands. Similarly, moving a key from a source file into a local environment file keeps it out of the code but does not necessarily prevent another process with file access from reading it.
I would look for a design that gives the application the access it needs while reducing what the assistant and its tools can reach. Depending on the platform, that may involve separate identities, isolated execution environments, an approved secrets manager, short-lived credentials, or a broker that performs a narrowly scoped action without handing out a reusable secret.
A secrets manager helps with storage and lifecycle management, but the access policy still matters. If the assistant’s identity can retrieve every secret, the secret has not been isolated from the assistant.
Use the smallest practical credential
When a development workflow requires a credential, I prefer to define:
Purpose: Which application or task needs it?
Scope: Which resources and actions does it permit?
Lifetime: Can it expire automatically?
Environment: Is it restricted to development or another appropriate environment?
Owner: Who can rotate or revoke it?
Monitoring: Can the team detect unexpected use?
Recovery: How will the application continue if the credential is revoked?
Short-lived, narrowly scoped credentials reduce the potential impact of exposure. They do not eliminate the need to protect the workspace or investigate suspicious activity.
I would also avoid using a personal administrator token for an automated workflow when a dedicated identity with limited permissions is available. That makes the access easier to understand, audit, and revoke.
Check product guardrails—and their limits
Some AI coding products support content exclusions, tool restrictions, or approval settings. These are useful controls, but their coverage can differ by product, client, mode, and version.
For example, GitHub’s Copilot documentation describes content exclusions and cautions that an excluded file is not necessarily protected from all indirect access. Its documentation also describes differences in support across surfaces. I would verify the current behavior for the exact client and mode in use rather than assume a repository setting applies everywhere. GitHub Docs
I would combine product settings with operating-system or container permissions, separate identities, network controls, and review of connected tools. An exclusion rule can be one layer; it should not be the only layer protecting a sensitive credential.
Test with a harmless marker
A security review should establish what happens in the actual workflow. I would coordinate a test with the workspace owner and use a synthetic marker that cannot authenticate to anything.
For example, an approved test could place a value such as WORKSPACE_TEST_MARKER_7Q4N in a designated test file or test environment variable. The team can then:
Record which assistant, client, mode, workspace, and settings are being tested.
Ask the assistant to perform a task that should not require the test location.
Inspect the assistant’s tool calls, output, and available logs for the marker.
Perform a separate, explicitly authorized access test to check whether the relevant boundary blocks access.
Repeat after a configuration change and record both successful blocks and unexpected access.
Do not use a real API key as the marker. Do not paste a real secret into a prompt to see what happens.
A single test does not prove that every indirect path is blocked. It does give the team evidence about a specific configuration and helps identify what needs further review.
Plan for untrusted instructions
Coding assistants may encounter content from repositories, issue descriptions, documentation, dependencies, or other external sources. Those materials can contain instructions intended to redirect an agent.
GitHub documents prompt injection as a risk for its cloud coding agent, including instructions embedded in issue content. The broader lesson is to treat retrieved content as data and limit what the assistant can do if it encounters malicious instructions. GitHub Docs
I would review whether the assistant can:
Read credentials or sensitive files.
Send information to external destinations.
Change repository settings.
Create or modify automation.
Approve or merge its own changes.
Act in production.
Restrict the available tools and permissions to the task. Require an authorized person to review consequential changes, and make the agent’s actions visible in logs or change history.
Have a response path before a secret is exposed
If a credential may have been exposed, removing it from a file is only one part of the response. The owner should assess whether the credential needs to be revoked or rotated, review relevant usage and access logs, identify affected systems, and replace the credential through an approved process.
The team should also investigate how the credential became accessible and whether the same pattern exists in other workspaces. A one-time cleanup is less useful if the default workspace template recreates the issue.
Make the secure path repeatable
I would finish the review by documenting an approved pattern developers can use without having to design the controls from scratch:
A standard workspace configuration.
An approved way to request and use scoped credentials.
Clear rules for assistant tools and connected services.
A test procedure using synthetic data.
An owner for exceptions and periodic review.
A straightforward way to report a suspected exposure.
Zero Trust starts with verifying the access a workflow actually needs. Defense in depth means assuming that one setting can fail or be misunderstood and placing additional controls around the credential, workspace, network, and resulting actions.
The goal is to support developers with a workflow they can repeat—and give security teams evidence that its boundaries work as intended.