Adopting Agentic Coding Tools Securely

Executive summary

The security question is no longer simply whether developers may send source code to a remote model. Agentic coding tools can read repositories, execute shell commands, install dependencies, browse external content, connect to Model Context Protocol (MCP) servers, access credentials and propose or perform changes. Their risk therefore depends on the entire agent harness—the model, context, tools, permissions, execution environment, connectors, memory and approval controls—not only on the model provider.

Organisations should reject two simplistic positions:

• Blanket prohibition drives usage into unmanaged personal accounts and prevents controlled learning.
• Blanket enablement treats code completion, repository chat and autonomous execution as though they created the same exposure.

The recommended approach is conditional, risk-tiered adoption. Classify each use case by (1) information sensitivity and (2) agent capability or blast radius. Approve tools and configurations—not brand names—and expand access only after controls and evidence mature.

For most organisations, low-risk use can begin with approved enterprise accounts, non-sensitive repositories, restricted tools, isolated execution, no production credentials and mandatory human review. Banks and government agencies need stronger supplier assurance, information-handling controls, logging, records management, sovereignty assessment and explicit restrictions for regulated or classified workloads.

1. The problem

Organisations face a real tension. Agentic coding tools can accelerate investigation, refactoring, test generation and routine maintenance, but their operation may expose proprietary code and may convert unreliable model output into real system actions.

The debate is often framed too narrowly:

“Will the vendor train its model on our private source code?”

That is a valid procurement question, but not a complete security assessment. A contractual promise not to train on customer data does not answer:

• what content leaves the endpoint;
• where and how long it is retained;
• which subprocessors and regions are involved;
• what administrators can control and audit;
• what local files, secrets and networks the agent can reach;
• whether untrusted repository or web content can manipulate the agent;
• what commands and external actions it can perform;
• how generated changes are reviewed, tested and attributed.

Australia's ASD makes the same architectural distinction. Its September 2026 guidance describes the harness as the layer that supplies context, connects tools and services, enforces permissions, executes actions and records activity. It states that many of the highest-impact risks arise from what an agent can access and do, and that prompt injection cannot be reliably solved by the model alone. ASD, Agentic AI harnesses

2. Why agentic coding changes the threat model

Traditional code completion usually returns text for a developer to accept. An agent may instead operate a loop:

1. ingest a task plus repository and external context;
2. choose tools;
3. execute commands or call services;
4. observe the results;
5. repeat until it considers the task complete.

This joins probabilistic reasoning to deterministic capabilities. A wrong suggestion becomes more consequential when the system can execute it.

2.1 The principal risk categories

Confidentiality and data-handling risk

Prompts may contain source code, architecture, logs, customer data, vulnerability details, credentials or procurement information. Agents may collect more context than the developer consciously pasted, including neighbouring files and command output. Exposure can occur through provider processing, retention, telemetry, support access, connected model providers, plugins, MCP servers or outbound network calls.

Enterprise terms matter. For example, OpenAI states that business-product inputs and outputs are not used for training by default, while individual ChatGPT and Codex services may use content unless the user opts out; it also documents separate controls for full-environment Codex tasks. OpenAI, How your data is used OpenAI separately documents business-data ownership, encryption, administrative controls and retention options. OpenAI, Enterprise privacy

The implication is important: “We use Codex” is not enough information for a risk decision. The plan, account ownership, settings, deployment path and enabled capabilities may materially change the answer. The same applies to other vendors.

Privilege and blast-radius risk

An agent inherits effective power from its execution identity. Access to a developer workstation may expose SSH keys, cloud credentials, package-manager tokens, browser sessions and internal network routes. Access to CI/CD may permit artifact publication or environment changes. Excess permissions can turn a model error or injected instruction into a material incident.

GitHub documents that Copilot CLI can modify files and execute commands locally, while its cloud agent operates in an ephemeral development environment. GitHub recommends branch rules, protected agent configuration, isolated runners, restricted secrets and minimum workflow permissions. GitHub, Responsible use of Copilot Agents GitHub, Building guardrails for the Copilot cloud agent

Claude Code similarly documents permission modes, working-directory boundaries, sandboxed command execution, network controls and trust verification for new codebases and MCP servers. Its documentation still assigns responsibility to the user for reviewing proposed code and commands. Anthropic, Claude Code security

These are useful safeguards, not proof that every configuration is safe.

Indirect prompt injection

Instructions can be hidden in code comments, README files, issues, pull requests, generated logs, websites, package metadata or MCP responses. The model may not reliably distinguish trusted instructions from attacker-controlled content. If the harness provides powerful tools, injected content can influence commands, data access or external communication.

ASD explicitly says there is no fully reliable technical mitigation and recommends architectural controls around access and permitted actions. A 2026 study of agentic GitHub workflows found hundreds of exploitable flows from untrusted repository-event content to agent or script actions. It is a preprint rather than a regulatory standard, but it supplies concrete empirical evidence that this is not merely theoretical. Wang et al., Demystifying and Detecting Agentic Workflow Injection Vulnerabilities in GitHub Actions

Software supply-chain risk

Agents can install packages, modify lockfiles, add actions, invoke community MCP servers and consume external documentation. Risks include dependency confusion, malicious packages, compromised tools, unsafe generated build steps and changes to security-sensitive configuration. The agent itself, its extensions and its update channel also become supply-chain dependencies.

Code integrity and vulnerability risk

Generated code may be functionally plausible but insecure, incomplete or inconsistent with organisational controls. Human approval is not a strong control when reviewers face large diffs, unfamiliar code or approval fatigue. Existing secure development controls—tests, static analysis, dependency analysis, secret scanning, peer review and protected branches—remain necessary. Agent-generated code should not receive a weaker path to production than human-generated code.

Audit, accountability and records risk

Organisations may be unable to reconstruct which model, context, tools, permissions and approvals produced a change. Logs can themselves contain sensitive data. Retaining everything creates privacy and security exposure; retaining too little prevents investigations, assurance and regulated recordkeeping.

Availability and cost risk

Runaway loops, repeated tool calls, compromised workflows, provider outages and quota exhaustion can interrupt delivery or create denial-of-wallet effects. ASD recommends monitoring consumption partly because unexpected cost can be a signal of misuse or compromise.

3. Root causes behind organisational disagreement

The difference between an organisation that encourages agents and one that prohibits them is not necessarily risk appetite alone. Common systemic causes are:

1. Category collapse. Leaders treat autocomplete, chat, local CLI agents and cloud agents as one product category.
2. Consumer and enterprise offerings are conflated. Contract, retention, training, identity and audit controls may differ.
3. Approval is vendor-based rather than configuration-based. A familiar vendor name is treated as sufficient assurance even when new agent, connector or model features are enabled.
4. Existing endpoint privileges are already excessive. Agents reveal an older problem: developers and CI jobs possess broad, long-lived credentials.
5. Security review is slow or binary. Delivery teams route around a process that provides only “approved” or “blocked,” with no safe experimentation path.
6. Productivity pressure is measured; risk is not. Adoption targets reward tool usage while security teams lack telemetry for exposure, unsafe actions and control failures.
7. Human review is used as a universal compensating control. Review effectiveness is assumed rather than tested.

The missing control is usually a repeatable mechanism that connects use-case classification to enforceable technical settings and evidence.

4. A two-axis risk model

Assess both axes. Data protection without capability control is incomplete; sandboxing without data governance is also incomplete.

Axis A: information sensitivity

Level	Typical material
A1 — Public	Open-source code, public documentation, synthetic examples
A2 — Internal	Non-public code with low business sensitivity; no personal, regulated or security-sensitive data
A3 — Sensitive	Proprietary algorithms, security architecture, vulnerability details, production-like logs, personal or regulated information
A4 — Restricted	Classified material, high-value secrets, cryptographic key material, live credentials, highly regulated datasets or code subject to strict sovereignty controls

Axis B: capability and blast radius

Level	Typical capability
B1 — Suggest	Generate text or code snippets; no repository or tool access
B2 — Read	Read an approved repository and metadata; no command execution or writes
B3 — Change in isolation	Edit and test in a disposable sandbox with restricted network and short-lived credentials; output is a reviewable patch or pull request
B4 — Act on connected systems	Access internal services, write repositories, trigger workflows, publish artifacts, change infrastructure or interact with production

Risk rises sharply when high-sensitivity data and high-impact capabilities intersect. The organisation should also increase a rating for internet-facing untrusted input, persistent memory, multi-agent delegation, external MCP integrations or unattended operation.

Recommended decision bands

Band	Examples	Default decision
Green	A1/B1–B3; A2/B1	Pre-approved patterns with standard controls
Amber	A2/B2–B3; A3/B1–B2	Approved enterprise service, documented assessment and enhanced controls
Red	A3/B3–B4; any material production or regulated action	Specific security architecture, threat model, testing and accountable risk acceptance
Prohibited unless exceptional approval	A4 sent to an unapproved external service; autonomous production changes; unrestricted credentials or networks	Deny by policy and technical enforcement

This is a starting model, not a universal classification. Each organisation must map it to its own information scheme and obligations.

5. Sector-specific application

Ordinary private-sector organisations

The main concerns are intellectual property, customer confidentiality, contract obligations, credential exposure and software integrity. A controlled enterprise offering with SSO, administrative policy, suitable retention, repository scoping and sandboxed execution may support broad low- and medium-risk use.

Small organisations should not imitate bank-level governance ceremony, but they still need an approved-service list, clear prohibited data, endpoint and secret hygiene, protected branches, automated scanning and a route for exceptions.

Banks and other APRA-regulated entities

Agentic coding tools should enter the existing information-security and third-party risk system, not a separate experimental lane. APRA CPS 234 requires regulated entities to maintain information-security capability commensurate with threats, classify information assets, implement controls and assess the capability of related or third parties that manage information assets. APRA, CPS 234 Information Security

Practical consequences include:

• determining whether prompts, repository context, logs and agent memory are information assets;
• mapping vendor, model-provider and subprocessor responsibilities;
• assessing materiality, concentration and exit risk;
• maintaining evidence that controls operate, not merely that contract clauses exist;
• restricting agents from customer data and production systems unless specifically designed and assured;
• integrating agent activity into incident detection, investigation and notification processes.

An enterprise “no training” commitment helps, but does not by itself satisfy information-security obligations.

Government

Government adds classification, sovereignty, public trust, procurement confidentiality, records and whole-of-government policy requirements. Public generative AI tools should not be treated as interchangeable with an agency-approved enterprise environment.

The Australian Government's AI technical standard covers governance across design, data, evaluation, integration, deployment, monitoring and decommissioning. Its June 2026 agentic AI addendum is directly relevant to agents. DTA, AI technical standard DTA, Agentic AI addendum

The current government staff guidance also emphasises protecting personal, security-classified and commercially sensitive information when using public tools. DTA, Staff guidance on public generative AI

For Victorian or other state-government organisations, Commonwealth material is useful guidance but should not be misrepresented as automatically binding. Applicable state policies, protective markings, privacy law, contractual obligations and agency directions must be mapped separately.

6. Recommended control architecture

6.1 Govern use cases, not only products

Maintain an inventory containing:

• business owner and technical owner;
• tool, plan, model providers and deployment path;
• approved repositories and data classes;
• available tools, connectors and MCP servers;
• execution identity and maximum privileges;
• network destinations;
• retention, logging and residency settings;
• permitted autonomy and mandatory approvals;
• validation controls and review date.

Reassessment should be triggered by a material model, vendor, retention, connector, permission or deployment change. Agent products evolve too quickly for annual-only review.

6.2 Use organisation-managed identities and contracts

• Prohibit personal accounts for organisational code.
• Enforce SSO, MFA, managed licences and joiner–mover–leaver processes.
• Confirm in contract and current product documentation whether inputs and outputs are used for training.
• Record retention, deletion, human-access, subprocessor, region, breach-notification, audit and exit arrangements.
• Prevent silent use of user-supplied API keys or unapproved model providers where central controls would be bypassed.

6.3 Minimise context and prevent secret exposure

• Remove credentials from repositories and developer environments; rotate exposed secrets.
• Use secret managers and short-lived, task-scoped tokens.
• Exclude sensitive directories as a secondary safeguard, not the only boundary.
• Apply DLP or egress inspection where proportionate, while recognising that encrypted or transformed exfiltration may evade simple pattern matching.
• Do not place production datasets or real personal information in agent sandboxes when synthetic or masked data is sufficient.

6.4 Isolate execution

• Prefer disposable containers or ephemeral virtual machines for autonomous work.
• Mount only required repositories and directories.
• Default to no network or an allowlisted egress proxy; separate package retrieval from unrestricted browsing.
• Deny access to workstation credential stores, SSH agents, cloud profiles and unrelated local files.
• Use a distinct non-human identity per agent or workload, with short expiry and revocation.
• Do not use persistent self-hosted runners for untrusted agent tasks unless isolation between runs is demonstrably effective.

6.5 Constrain tools and actions

• Maintain an allowlist of tools and approved MCP servers.
• Treat MCP servers, skills, hooks, plugins and repository instruction files as executable supply-chain components.
• Require approval for network access, package installation, destructive file operations, changes to security controls, external messages, artifact publishing and environment changes.
• Block direct pushes and merges to protected branches.
• Protect agent configuration, workflow and instruction files with code ownership.
• Never grant an agent production access merely because the human operator already has it.

Approval prompts are useful only if actions are understandable and infrequent enough to review. Repeated low-value prompts create habituation; separate safe, narrowly defined actions from high-impact ones instead of asking users to approve everything.

6.6 Treat all consumed content as potentially hostile

• Separate trusted policy and task instructions from untrusted repository, issue, web and tool content where the platform allows it.
• Do not allow an agent that reads untrusted public content to simultaneously possess sensitive context and unrestricted egress or execution.
• Sanitize and validate tool parameters and outputs.
• Use deterministic policy enforcement outside the model.
• Threat-model cross-tool chains: a read-only connector can still supply injected instructions to another tool that has write authority.

6.7 Preserve the software delivery control plane

Every agent change should be attributable and reviewable through normal version control. Require controls based on risk:

• build and unit, integration and security tests;
• SAST, dependency and secret scanning;
• infrastructure-policy checks;
• peer review by a person competent in the changed area;
• small, bounded changes rather than opaque bulk generation;
• provenance showing agent involvement, tool/model version where available, and human acceptance;
• environment promotion and segregation of duties for high-risk systems.

Human review is not a substitute for automated evidence. Automated checks are not a substitute for accountable review. Both are needed.

6.8 Log for detection and accountability

Capture, where proportionate:

• identity, session and repository;
• model and harness configuration;
• tool calls, commands, approvals and denials;
• external connections;
• changed artifacts and commit or pull-request links;
• policy violations and security events;
• token or cost anomalies.

Protect these logs because they can reproduce source code, prompts or secrets. Define access, retention and redaction according to incident-response, privacy and records requirements.

7. A practical adoption pathway

Phase 0 — Establish the minimum control plane

Before a pilot, name an accountable owner, define prohibited uses, choose managed enterprise accounts, configure identity and logging, establish the risk classification and prepare an isolated environment. Provide a fast process for teams to disclose existing shadow use without punitive treatment.

Phase 1 — Low-risk pilot

Use public or low-sensitivity code. Permit suggestion and repository-read modes, then isolated patch generation. Disable arbitrary MCP servers, production access and unrestricted egress. Select representative work such as tests, documentation, dependency updates and bounded refactoring.

Measure both value and risk:

• task lead time and developer rework;
• acceptance rate of changes, not suggestion volume;
• escaped defects and security findings;
• unsafe action attempts and approval overrides;
• secret or policy violations;
• review time and reviewer comprehension;
• cost per accepted change.

Phase 2 — Controlled internal code

Expand only after verifying isolation, access revocation, audit completeness and incident handling. Introduce approved internal repositories with task-scoped identities, restricted network access, protected configuration and mandatory pull requests.

Phase 3 — Higher-risk use cases

Require a threat model, privacy and supplier assessment, security testing, recovery plan and explicit risk acceptance. Red-team indirect prompt injection and cross-tool chains. Validate what happens when the agent is compromised, not only when it behaves normally.

Stop or rollback conditions

Pause or narrow deployment when:

• sensitive data leaves an approved boundary;
• a tool or model changes material data terms or subprocessors without assessment;
• agents obtain credentials or systems outside their approved scope;
• required activity cannot be audited;
• prompt injection or configuration bypass produces unacceptable actions;
• review quality, defect leakage or security findings deteriorate materially;
• incident response cannot promptly disable access and revoke agent identities.

8. Tool-assessment questions

Do not score a tool solely from marketing claims or certifications. Obtain evidence for the deployed configuration.

1. Exactly what repository, prompt, terminal, log and telemetry data is transmitted?
2. Is organisational content used for training, evaluation or abuse monitoring, and is opt-in possible?
3. What are default and configurable retention periods, including backups and logs?
4. Which model providers, subprocessors and regions receive data?
5. Can administrators enforce SSO, feature policies, model choice, MCP allowlists and data controls?
6. Can the agent be restricted by filesystem, network, repository and command?
7. Are execution environments ephemeral, and can they reach customer-managed runners or internal networks?
8. How are secrets supplied, scoped, redacted, rotated and revoked?
9. Which actions always require human approval, and can users weaken that policy?
10. Can untrusted issues, pull requests, web pages or tool output enter context?
11. Are tool calls, approvals, configuration changes and outputs available to organisational audit systems?
12. Can the organisation immediately disable the service and export or delete its data?
13. How are models, extensions, MCP servers and agent updates assured and versioned?
14. What testing supports claims about prompt injection, data isolation and sandbox escape resistance?
15. What contractual remedies, notification obligations and audit rights apply after an incident?

9. Quality Engineering implications

Quality Engineering should not own enterprise AI risk, but it has an important assurance role. Coding-agent adoption crosses product quality, secure development, testability, observability and release controls.

QE can help define executable acceptance criteria for the harness:

• an agent cannot read excluded directories;
• outbound traffic is denied except to approved endpoints;
• short-lived credentials cannot access production;
• destructive and security-sensitive operations require approval;
• agent-created pull requests cannot bypass required checks;
• all tool calls and approvals are traceable to a session and identity;
• injected instructions in repository artifacts cannot produce an unacceptable action;
• disabling a user or agent identity removes access within the required time;
• model or harness upgrades trigger a regression suite before broad rollout.

This reframes assurance from “review the AI-generated code” to test the socio-technical control system that generates and promotes the change.

10. Risks and trade-offs

Self-hosted models are not automatically safer

Local inference can reduce third-party data exposure and sovereignty concerns. It also transfers responsibility for model provenance, infrastructure security, patching, monitoring and capacity to the organisation. More importantly, it does not resolve prompt injection or excessive local privileges.

Strong isolation reduces utility

Agents become more useful when connected to package registries, issue trackers, documentation and internal services. Each connection adds attack paths and trust relationships. The right response is task-specific connectivity, not unrestricted access and not permanent isolation from everything.

Full logging conflicts with data minimisation

Detailed logs support audit and incident response but may duplicate source code, personal information and secrets. Retention and redaction require deliberate design.

Human approval can become theatre

Approvals provide little protection if the reviewer cannot understand the proposed command or diff, or if prompts occur so often that users reflexively accept them. High-impact boundaries should be technically enforced, while human approval is reserved for decisions a person can realistically assess.

Product controls change quickly

Vendor comparisons age faster than the governing principles. A point-in-time feature matrix should inform procurement, but the durable control model should remain provider-neutral and trigger reassessment when capabilities change.

11. Key takeaways

1. Remote-code exposure is real, but it is only one part of the risk.
2. The agent harness—context, tools, identities, sandbox, network, memory and approvals—determines much of the practical blast radius.
3. Approve a specific service plan, deployment path, configuration and use case; do not approve a brand name in the abstract.
4. Separate information sensitivity from agent capability, then combine them to set the required controls.
5. Enterprise “no training” terms reduce one risk; they do not replace retention, sovereignty, supplier, access and operational assessment.
6. Prompt injection is an architectural security problem. Do not rely on model instructions or user vigilance as the primary defence.
7. Preserve established secure-development and release controls. Agent-generated code should not receive a privileged route to production.
8. Begin with low-risk, bounded work and expand only when control effectiveness—not adoption enthusiasm—supports it.

References

• Australian Signals Directorate, Agentic AI harnesses: The layer above the model, 11 September 2026.
• Australian Government Digital Transformation Agency, Agentic AI addendum to the AI technical standard, updated 4 June 2026.
• Australian Government Digital Transformation Agency, Technical standard for government's use of artificial intelligence, updated 22 August 2025.
• Australian Government Digital Transformation Agency, Staff guidance on public generative AI.
• Australian Prudential Regulation Authority, CPS 234 Information Security.
• National AI Centre, Guidance for AI adoption: implementation guidance, 5 May 2026.
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1), July 2024.
• OpenAI, Enterprise privacy, updated 8 January 2026.
• OpenAI, How your data is used to improve model performance.
• Anthropic, Claude Code security.
• Anthropic, Claude Code data usage.
• GitHub, GitHub Copilot policies for enterprises and organizations.
• GitHub, Building guardrails for GitHub Copilot cloud agent.
• GitHub, Responsible use of GitHub Copilot Agents.
• Shenao Wang et al., Demystifying and Detecting Agentic Workflow Injection Vulnerabilities in GitHub Actions, preprint, May 2026.

---

Research cut-off: 15 September 2026. Product capabilities and contractual terms change rapidly; verify them against the proposed subscription and deployment before approval.