A traditional secure software pipeline already has plenty of controls once code exists. Dependencies can be scanned. SAST can run. An SBOM can be generated. Provenance can be recorded, artifacts signed and release policy applied before anything reaches production.
Coding agents introduce another security surface before most of that begins. By the time the first commit appears, a run may already have read proprietary repositories or used credentials. A clean PR doesn’t tell you whether any of those earlier actions were appropriate.
You also need to know who initiated the work, what authority the run had, where its data travelled and which external systems handled it. If repository context was sent somewhere it shouldn’t have gone, signing the eventual artifact doesn’t undo the exposure.
Contain what the run can reach
The safest starting point is to treat a coding-agent run as its own workload rather than as an extension of the developer sitting next to it.
A task that updates tests in one repository might need branch write access and somewhere to execute those tests. It doesn’t automatically need production database credentials, cloud-admin permissions or every secret available on the machine.
For higher-autonomy runs that means an isolated environment where filesystem, network, and secret access can be limited independently of the developer’s workstation.
Issue bodies, PR descriptions, and tool output can all influence what happens next. If untrusted content can steer a process that also has broad access to secrets and privileged tools, a mistake in reasoning becomes an access-control problem.
Microsoft demonstrated that risk in a Claude Code GitHub Action workflow where repository content could influence an agent whose Read tool was also able to access /proc/self/environ. In Microsoft’s testing, that exposed the workflow’s Anthropic API key and potentially other credentials available to the runner. Anthropic later mitigated the specific issue.
MCPTox found a similar problem in live MCP servers: malicious instructions embedded in tool descriptions could successfully influence agent behaviour.
Keep in mind that MCPTox shouldn’t be read as a failure rate for every coding-agent setup and tool output shouldn’t become trusted merely because it arrived through an interface the agent knows how to call.
Credentials can be short-lived and scoped to the task while tool permissions can be granted outside the model. The API or service receiving a request should still decide whether that caller is authorized instead of treating the model’s decision as permission.
A model request has its own data path
Source code isn’t the only information that can leave the runtime in a model request. Error logs, architecture documents, issue content and tool output can all follow the same route, so where that route goes matters operationally.
A regional workload might involve:
agent runtime → model gateway → provider → inference location
↳ traces / logs
↳ fallback provider if the primary route fails
An EU-hosted primary model only covers one part of that path. If the primary request stays in an approved region but a fallback sends the same source-code context somewhere else, the application may still receive a valid model response while the data boundary has changed.
We’ve taken the same view with model traffic at Orq.ai. A coding session shouldn’t become a side channel around the controls already applied to production AI traffic. The eligible models, providers, fallbacks and routes should still come from the same governed path.
A gateway can control this part of the system by narrowing which models and providers are available to a run, applying policy before requests are sent onward to a model provider and recording which route was actually used.
Controlling model traffic doesn’t automatically control package downloads, web requests or MCP connections. Those remain separate forms of egress and need their own runtime or network controls.
Keep verification independent of the run
The normal software-security controls still matter when an agent writes the code. What you should pay more attention to is how much of that evidence the same run should be allowed to create or modify.
Imagine an agent implements a feature, adds its own tests, weakens those tests after they fail and eventually reports a green pipeline. The result can look verified even though the thing being evaluated also influenced the evidence used to approve it. Doesn’t mean every test written by an agent is untrustworthy.
A routine CI fix and a change to authentication, payments or infrastructure don’t need the same approval path.
For higher-risk work, some evidence can stay outside the run’s writable environment. Existing tests may be immutable and security checks can execute separately. A second evaluator, review agent or human can assess the result without sharing the implementation run’s exact context or incentives.
There’s also evidence that the quality of agent-written tests varies substantially. A 2026 study analysed 86,156 test-file patches from 33,596 agent-authored pull requests across 2,807 repositories and found that 80.2% contained weak or no explicit oracle signals. Stronger test oracles were associated with a higher likelihood of merge after controlling for factors including:
Agent
PR size
Repository popularity
Task type
Language
Those two jobs don’t always need to belong to the same run.
Could you explain the run six months later?
Regulated organizations rarely suffer from a complete absence of logs. The tricky part is connecting those logs back to the authority under which the work happened.
A trace might tell you:
14:06 tool_call
14:07 model_call
14:08 git_write
That proves actions occurred but it doesn’t explain why they were allowed. You still don’t know who authorized the task, which policy version applied, whether the chosen model was eligible for that workload or which conditions had to pass before the change could continue.
A useful audit record needs to connect the beginning of the work to the artifact at the end:
approved task → agent identity → policy version → execution environment → model route → tools and actions → checks → approvals → commit/build → released artifact
Knowing that Model X received a request at 14:07 doesn’t establish whether the run complied with the regional requirement. You’d also want to know which providers were eligible, which route was selected, whether a fallback happened and which policy classified the workload in the first place.
That information is much easier to preserve while the run is happening than reconstruct later.
We think auditability has to be designed into the execution path for the same reason. Once the run is over, missing identity, routing or policy context can’t reliably be recreated from a collection of disconnected logs.
If task identity and approvals weren’t captured during the run, six months later you’ll end up piecing the story together from incomplete logs and whatever configuration you think was active at the time.
How regulation applies to coding agents
A regulated company using coding agents doesn’t mean every coding-agent use case falls into the same regulatory category.
The EU AI Act matters to enterprises using coding agents, but writing production software doesn’t by itself make a coding agent a high-risk AI system.
Classification depends on the system’s intended purpose and whether its use falls into one of the Act’s regulated categories, including certain uses in areas such as critical infrastructure, employment, education, essential services, law enforcement and migration.
A coding system also doesn’t automatically inherit the classification of every product it contributes code to. Its own intended purpose and use still matter. The European Commission’s guidance makes that intended-purpose distinction central to how obligations are assessed.
There’s no blanket AI Act rule saying that coding agents or the models behind them must run in the EU. Data residency concerns where information is processed or stored yet sovereignty goes further into questions like who controls the infrastructure and whether the deployment depends on external services.
Our view is that sovereignty stops being useful if it only describes where the servers sit. You also need control over the providers, execution path and governance layer that decide where requests can go and how the system behaves.
Logging, human oversight and technical documentation are much easier to support when the run has defined permissions, model routes and checks than when it inherits broad access from a developer machine.
Before a run starts, its access, data routes and stop conditions should already be known. If somebody investigates the released artifact later, the task and approvals should still be recoverable.
If you want to see how Orq.ai brings model routing, policy, evaluation and audit evidence into the same Software Factory workflow, book a demo.
