Because authorisation to use the tool is not the same as governance over what it can see or send. A sanctioned agent can expose source code, credentials, or customer data as part of normal operation, especially when it calls hosted models or MCP-connected services to finish a task.
Why authorised employees still create exfiltration exposure with agentic coding tools
Authorisation to use an agentic coding tool does not mean the employee controls every read, transformation, or outbound call the tool makes on their behalf. These tools often work inside an existing developer context, which can include source repositories, environment files, secrets, tickets, and internal docs. If the agent can reach hosted models or connected services, it can move sensitive material outside the original trust boundary while still appearing like normal work.
What the exfiltration path actually looks like
The risk comes from delegated execution, not just delegated login. An agent can inspect code, copy snippets into prompts, send repository content to a model provider, or call MCP-connected services that are designed to fetch context and complete tasks. AI Coding Agents Security Guide covers the common failure modes in IDE, terminal, and CI/CD workflows, including secrets in context and over-scoped access.
That means a user may be fully permitted to run the tool while the tool itself still has broader visibility than the user intended for a specific task. The practical question is not “is the employee allowed to use it?” but “what data can the agent see, and where can it send that data during task completion?”
Why normal employee approval is not enough
Approval is usually a coarse access decision. Exfiltration control needs finer-grained rules about scope, destination, and action. An agent may be trusted to assist with refactoring, but not to transmit proprietary code to a hosted model, upload customer data into a third-party workflow, or use a connector that expands the blast radius beyond the local workstation.
This is where least privilege and per-action authorization matter. AI Agent Authorisation Guide is relevant because the control problem is about what the agent may do on each step, not whether the human who launched it had a valid account. In practice, the governing boundary has to include tool calls, data categories, and allowed egress paths.
Risk and Threat Considerations
Agentic coding tools raise exfiltration risk because they collapse review, retrieval, and transmission into one workflow. Sensitive material can leave the environment through prompt context, connector calls, logs, or generated output even when the user is acting legitimately and the tool is behaving as designed.
Failure mechanism: The employee is authorised, but the agent is over-scoped or insufficiently constrained, so it can read more data than needed and transmit that data to hosted models, external APIs, or MCP-connected services.
Impact: Source code, credentials, customer data, or internal logic can be exposed without a classic account compromise, which makes detection and response harder and increases the chance of silent disclosure.
Those risks are amplified when the tool chain includes remote inference, plugin ecosystems, or reused credentials. MCP Security Guide is useful here because it addresses token passthrough, local server credentials, and tool poisoning, all of which can turn a helpful integration into an unintended data path. Zero Trust for AI Agents adds the core operating principle: verify the agent, principal, and request on each action, then remove standing privilege wherever possible.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic coding tools can transmit data through delegated privileges and tool calls. |
| ASI02 — Tool Misuse | Exfiltration often occurs through unintended use of connected tools and model calls. | |
| Recommendation — Constrain each agent action to least-privilege scopes and per-action approval. Restrict tool access to approved destinations and validate each connector’s data handling. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Coding agents can expose credentials, tokens, and other secrets during normal operation. |
| NHI-05 — Overprivileged NHI | An agent with broader access than its task needs has higher exfiltration potential. | |
| Recommendation — Block secrets from agent context and rotate any exposed credentials immediately. Reduce agent permissions to the minimum needed for the current task. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege directly limits what the agent can see or send during execution. |
| IA-5 — Authenticator Management | Credential handling matters when agents can reuse or expose tokens and keys. | |
| Recommendation — Apply least privilege to agent credentials, connectors, and session scopes. Manage and rotate agent credentials to limit reuse and exposure. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Per-request verification and reduced standing access fit agent egress control. |
| Recommendation — Enforce continuous verification for every agent request and data access. | ||
Practitioner Guidance
What to verify: Confirm what data classes the agent can ingest, retain, and transmit, and test those boundaries in the exact IDE, terminal, or CI workflow that staff actually use. If a tool can reach production code or secrets, assume its output path needs the same scrutiny as any other sensitive egress channel.
Decision rule: If the task can be completed without exporting sensitive context, deny outbound transmission by default and scope the agent to the minimum inputs required. If outbound calls are necessary, constrain the destination, redact high-risk fields, and require step-level approval for higher-impact actions.
Practitioner takeaway: Authorisation to use an agentic coding tool is only the starting point, because exfiltration risk is created by data visibility plus outbound capability, not by user intent alone.
Related resources from NHI Mgmt Group
- Why do agentic coding tools increase blast-radius risk even when auto-approval is limited?
- Why do agentic coding tools increase identity risk even when the prompt is useful?
- Why do agentic coding tools increase secret exposure risk in repositories?
- Why does agentic coding increase security risk even when generated code looks correct?