Your source code is now training data unless you decide otherwise
Every time a developer points a hosted AI coding assistant at a private repository, the contents of that repository cross a boundary. The prompt, the surrounding files the agent pulls in for context, the environment variables it happens to read, the diff it generates: all of it travels to a third-party model endpoint. For a team building a marketing site, that trade is usually fine. For a bank, a telecom operator, or an operator of critical national infrastructure, it is a data-transfer event that a regulator will eventually ask about.
The engineering newsletters have spent the last few months on a different framing of the same shift. The story they tell is about speed and cost: route tasks across specialised models, drop the cheap grunt work onto a small local model, keep the frontier model for the hard reasoning, and watch your token bill fall. DeepLearning.ai now runs a course specifically on moving AI coding workflows "from cloud to local," and open-weight models like Llama, GLM and DeepSeek have made a genuinely capable local option realistic on a single workstation with a decent GPU. That is real, and it is worth doing. But when we sit with clients in regulated sectors, the conversation starts somewhere else. It starts with where the code goes.
This article is about running AI coding agents on infrastructure you control, and doing it in a way that survives an audit. We have implemented this pattern for banking and telecom clients, and the mistakes are consistent enough to be worth writing down.
What running locally actually gives you
Keeping the model inside your own network changes three things at once, and it helps to separate them because they carry different weight for different organisations.
The first is data residency. If your model runs on a server in a UAE data centre, your source code and prompts never leave that jurisdiction. For firms reporting to local regulators, or handling data that carries residency obligations, this is often the single deciding factor. A hosted API in another region turns every code-completion request into a cross-border transfer that has to be documented, justified, and covered by a contract.
The second is confidentiality of intellectual property. Source code is not just a functional artefact. It encodes business logic, security controls, and frequently a trail of credentials and internal hostnames that developers left in place. Handing that to an external service means trusting that service's retention policy, its access controls, and its incident response, none of which you operate. Running the model yourself collapses that trust boundary back to your own perimeter.
The third is cost and latency, which is where the newsletters focus. A local 7B or 20B model handling autocomplete and boilerplate, with a larger model reserved for architecture-level work, is measurably cheaper and often faster than round-tripping every keystroke to a hosted endpoint. That is a legitimate benefit. It is also the one that matters least when a compliance officer is in the room.
A caution worth stating plainly: local does not mean secure by default. Moving the model onto your own hardware removes the third-party data-transfer risk and replaces it with the ordinary work of securing a service that has a lot of privilege. More on that below, because it is where most teams underinvest.
The compliance framing your auditor already uses
If you hold, or are working toward, ISO/IEC 27001, the relevant question is how AI-assisted development fits your Statement of Applicability. Annex A controls around cryptography, access control, secure development (A.8.25 through A.8.28 in the 2022 revision), and supplier relationships all touch this. An external coding assistant is, in control terms, a supplier processing your information assets. A self-hosted model is a system you operate and must include in scope.
For teams handling cardholder data, PCI-DSS 4.0 is blunt about where that data may go and who may touch systems in scope. An AI agent with filesystem and shell access on a developer machine that also touches the cardholder data environment is a control question you want to have answered before an assessor raises it. NIST's Cybersecurity Framework gives you the vocabulary to structure the whole thing under Identify, Protect, Detect, Respond and Recover, and the newer NIST AI Risk Management Framework and ISO/IEC 42001 give you a management-system spine specifically for AI. You do not need all of these. You need to know which ones your customers and regulators will hold you to, and to map the AI toolchain against them deliberately rather than discovering the gap during certification.
Three deployment patterns, and how to choose
In practice the choice is not "cloud or local" as a binary. There is a spectrum, and most organisations land on one of three points along it depending on how strict their data-handling obligations are.
PatternWhere the model runsData exposureBest fit
Hosted API with contract
Vendor cloud, enterprise tier
Code leaves your perimeter; governed by a DPA and a no-training clause
Lower-sensitivity code; teams that need frontier capability and accept a contractual control
Private cloud endpoint
Your cloud tenancy or a dedicated VPC instance
Stays inside your cloud boundary and region; no shared multi-tenant inference
Regulated firms already operating in a compliant cloud region
Self-hosted / air-gapped
Your own servers, no outbound internet
Code never leaves the network; model weights and inference are fully local
Banking, defence, CNI, anything with hard residency or air-gap requirements
The middle option is underused and often the right answer. A dedicated inference endpoint inside your own cloud tenancy, in your own region, with logging you control, gives you most of the confidentiality benefit of self-hosting without the operational burden of running GPU infrastructure. Serving stacks like vLLM, Ollama and llama.cpp make the fully self-hosted route practical when you genuinely need the air gap, but do not reach for the hardest option out of reflex. Match the pattern to the obligation.
The part everyone skips: securing the agent, not just the model
Here is the shift that catches teams off guard. A traditional code assistant suggested text and you decided what to do with it. A modern coding agent acts. It reads files, writes files, runs shell commands, installs packages, and sometimes opens network connections, all inside a loop it drives itself. The model is only one component. The agent wrapped around it is a piece of software with broad access to a developer's machine and, through that machine, to your internal network.
That changes the threat model. You are no longer only asking "where does my code go." You are asking "what can this thing do if it is manipulated, and what is the blast radius when it goes wrong." OWASP now maintains a Top 10 specifically for LLM applications, and the top entries map directly onto coding agents.
Prompt injection through the repository itself
An agent reads context from the codebase to do its job. It reads README files, configuration, comments, issue text, and increasingly a project instruction file such as AGENTS.md. Any of those can contain instructions the agent will treat as authoritative. We have seen proof-of-concept payloads sitting in a dependency's documentation that, when pulled into an agent's context, tell it to exfiltrate environment variables or add a malicious step to a build script. The agent is not being clever or malicious. It is doing exactly what a language model does, which is follow the most recent instruction that looks like one.
The defences are unglamorous and effective. Treat repository content and third-party context as untrusted input, the same way you already treat user input to a web application. Constrain what the agent is allowed to execute without human confirmation. Require a person to approve any shell command, any file write outside a working directory, and any network call. Review the AGENTS.md and equivalent instruction files under the same change-control you apply to code, because they are now part of your attack surface.
Secrets and the blast radius of tool access
The most common real-world failure has nothing to do with the model's cleverness. It is a developer running an agent with full shell access on a machine that has cloud credentials, a production database connection string, and an SSH key sitting in the environment. The agent reads a file, the secret is now in the context window, and if that context is going to any external endpoint, the secret has left the building. Even fully local, an agent that can run arbitrary commands can do arbitrary damage if it is manipulated or simply makes a bad call.
Contain it deliberately. Run agents inside a sandboxed environment, a container or a dedicated VM, not on the engineer's primary machine with production access. Pull secrets from a managed store such as HashiCorp Vault at the moment of use rather than leaving them in environment variables the agent can read. Control outbound network access with an egress allowlist so that even a compromised agent cannot phone home. Log what the agent runs, and keep those logs, because when something does go wrong you will want the sequence of tool calls, not a guess.
Supply chain, because the agent installs things
Coding agents install packages and pull in "skills" or plugins with a single command. That is a software supply-chain decision made at machine speed, often without a human reading what was installed. Apply the same discipline you would to any dependency: pin versions, generate and check a software bill of materials, and vet the source of any agent extension before it runs in an environment with real access. The CIS Benchmarks give you a hardening baseline for the underlying hosts, and they apply just as much to a GPU inference server as to any other production system.
A rollout checklist we use with clients
- Classify your code and data first. Decide which repositories can tolerate a hosted API under contract and which must never leave your perimeter. The deployment pattern follows from that classification, not the other way around.
- Pick the least-privileged deployment pattern that meets the obligation. Default to a private endpoint in your own region unless a hard air-gap requirement pushes you to fully self-hosted.
- Sandbox the agent. Containers or dedicated VMs, never the developer's machine with production credentials attached.
- Gate destructive actions behind human approval. Shell execution, out-of-tree file writes, and network calls all require a person to confirm.
- Move secrets into a managed vault and out of the agent's readable environment.
- Put an egress allowlist in front of every agent host so exfiltration has nowhere to go.
- Bring AGENTS.md and other instruction files under change control and code review.
- Log tool calls centrally and retain them. Feed those logs into your existing SOC or SIEM so agent activity is visible alongside everything else.
- Map the whole toolchain against your framework of record, whether that is ISO 27001, PCI-DSS, NIST CSF, or ISO 42001, and record it in your Statement of Applicability before your assessor does it for you.
- Review quarterly. The models and the tools change monthly, and a control set written against last quarter's agent is already partly out of date.
How Aydahwa Enterprise can help
We help organisations adopt AI-assisted development without giving up control of their code or their compliance posture. That work usually starts with an honest assessment of where sensitive data currently flows and which of the three deployment patterns fits each part of your estate, then moves into the practical build: a private or air-gapped inference setup, sandboxing and egress controls for the agents, secrets management, and the logging that feeds your existing detection stack.
Our team brings 25 years of hands-on infrastructure and security work across banking, telecom and critical national infrastructure, backed by certifications including Microsoft Cybersecurity Architect Expert and delivery experience against ISO 27001, PCI-DSS, SOC 2, NIST CSF and CIS Benchmarks. If you want a grounded view of your current exposure before committing to a design, our cybersecurity self-assessment and readiness checklist are a fast way to start. For the build and the ongoing operation, see our cybersecurity and cloud security and migration services, or reach us directly through the contact page. If your developers are already using AI tools and you are not yet certain where the code is going, that is exactly the conversation worth having now, before it becomes an audit finding.
