Coding agents are useful because they can see and manipulate the same technical environment developers use.
That creates an uncomfortable security truth:
The information that makes a coding agent effective is often the same information the enterprise most wants to protect.
Source code. Architecture. Credentials. Internal APIs. Configuration. Customer data. Deployment logic.
A secure coding-agent program therefore needs to think about data leakage as an execution problem—not only a model-provider problem.
Here are five paths every enterprise should threat-model.
1. Sensitive context sent to a model provider
The most obvious path is inference.
A coding agent reads source code, configuration, a ticket, logs, or a database schema, then includes some of that information in the model request.
This may be expected behavior. But organizations still need to know which data classes can be sent, which provider receives them, which endpoint is used, what commercial terms apply, and whether private inference is required.
The security issue is not that external inference is automatically unsafe. The issue is uncontrolled inference.
Control strategy
Create an approved provider architecture.
Public repo agent -> approved hosted model
Internal source agent -> enterprise model endpoint
Restricted data agent -> private inference
Then enforce provider access through network and identity controls.
2. Unrestricted network egress
Imagine the model never sees a secret. The agent can still read a sensitive file locally.
If it has unrestricted outbound internet access, the agent—or malicious code executed by it—may be able to transmit that file directly.
/workspace/internal-design.pdf
|
v
agent
|
v
unapproved endpoint
This is why "our model provider doesn't train on our data" is not a complete agent-security answer.
The runtime itself needs egress controls.
Control strategy
Start from default deny. Allow only destinations required for the workflow, such as GitHub, the approved model endpoint, internal Jira, and an internal package mirror.
NVIDIA OpenShell's restrictive default network policy denies outbound access unless another policy or provider rule explicitly grants it.
3. Raw credentials exposed to the agent
Credentials are data too.
A coding agent often runs in environments containing:
GITHUB_TOKEN
cloud credentials
KUBECONFIG
SSH keys
registry tokens
database passwords
If the agent can read those values, it may also be able to print, save, log, prompt, or transmit them.
Control strategy
Reduce direct secret possession.
Prefer workload identities, short-lived tokens, scoped GitHub Apps, secret brokers, and credential mediation.
OpenShell's provider model can place opaque credential placeholders into the sandbox and resolve the real credential only at approved endpoints.
The principle is broader than OpenShell:
Give the workload the ability to perform the approved request—not unrestricted possession of the reusable secret.
4. MCP and tool-mediated exfiltration
An agent does not need raw network access if it has a tool capable of sending data.
Imagine an MCP server exposing:
send_email
upload_file
send_slack_message
create_ticket
The agent can use a legitimate enterprise tool as an exfiltration channel.
This is why MCP governance needs more than server-level authentication.
Security should understand which tools can transmit data, which destinations they support, which identities they use, and which agents can invoke them.
Control strategy
Classify tools by risk and apply agent-specific policy.
read_ticket low
create_ticket medium
send_external_email high
upload_external critical
5. Supply-chain and generated-code paths
Coding agents routinely install dependencies, execute tests, run generated scripts, build containers, and update CI/CD.
That gives third-party and generated code a path into the runtime.
A malicious dependency can read whatever the runtime can read. A generated script can call whatever the runtime can call. A compromised build tool can leak environment variables.
The agent does not need to intentionally exfiltrate anything. It only needs to execute software that does.
Control strategy
Reduce ambient authority using isolated environments, filesystem restrictions, egress controls, internal package mirrors, lockfiles, dependency scanning, non-root execution, seccomp/capability restrictions, and ephemeral identities.
The common failure: ambient authority
All five paths have something in common.
The coding agent—or code it launches—has too much ambient authority.
Ambient authority looks like:
If you're in the environment,
you can probably access it.
For example: every environment variable, every mounted directory, every reachable network, every cached credential, every MCP tool.
Secure agent design replaces ambient authority with explicit capabilities.
Model data flows explicitly
For each coding-agent workflow, draw:
Developer
|
v
Agent
+-- Filesystem
+-- Model
+-- GitHub
+-- Package Registry
`-- MCP
Then annotate:
What data?
Which credential?
Which identity?
Which destination?
Read or write?
Logged?
Most security gaps become much easier to see.
Build exfiltration tests
Do not rely on design intent alone.
Test the environment.
- Create a fake credential file outside the allowed workspace and ask the agent to read it.
- Attempt HTTP access to a test unapproved domain.
- Attempt to send a fake secret through an approved SaaS tool.
- Install a test package that attempts an unapproved connection.
- Attempt to switch inference to an unapproved provider.
The expected result should be denial where the workflow does not require the capability.
Private inference solves only one leakage path
Private models can reduce the risk associated with inference traffic.
They do not automatically solve internet egress, credential theft, MCP exfiltration, malicious packages, or filesystem exposure.
A fully private model running next to an agent with unrestricted cloud credentials and open internet access is still a dangerous environment.
The goal is controlled data movement
Agents need data to be useful.
The enterprise should be able to say:
Data X
may move from
System A
to
Agent B
to
Approved Provider C
for
Purpose D
under
Policy E
Everything outside that path should require another explicit decision.
How Anpu Labs helps
Anpu Labs maps agent data flows during our Secure Agent Infrastructure Assessment. We identify what data agents can read, where that data can move, which credentials are exposed, which tools can transmit information, which model providers receive context, and where runtime isolation is weak.
We then design a target environment around least privilege, controlled egress, credential mediation, and centralized observability.
References
- NVIDIA OpenShell — Overview: https://docs.nvidia.com/openshell/latest/about/overview
- NVIDIA OpenShell — Providers: https://docs.nvidia.com/openshell/how-it-works/providers/overview
- NVIDIA OpenShell — Default Policy: https://docs.nvidia.com/openshell/latest/how-it-works/policies/default-policy
- MCP TypeScript SDK v2: https://ts.sdk.modelcontextprotocol.io/v2/
