AI coding agents are now part of the attack surface

Pwn2Own Berlin 2026 is a useful signal for anyone adopting AI coding tools.

This year’s event includes a dedicated Coding Agent category. The scheduled targets include OpenAI Codex, Anthropic Claude Code and Cursor. Security researchers are not only looking at operating systems, browsers and servers anymore. They are also looking directly at the tools that now read repositories, execute commands, install dependencies, call APIs and help developers ship software.

That matters.

For the last year, most business discussion around AI coding agents has focused on productivity. Can they write features faster? Can they reduce backlog? Can founders build prototypes without a full team? Can developers hand off boring implementation tasks?

Those are still important questions. But Pwn2Own points to a more mature question:

What happens when the coding agent itself becomes a high-value target?

This is not a reason to panic or ban the tools. It is a reason to treat them as serious software inside the delivery chain.

A coding agent is not just an editor feature

The simplest mental model for AI coding tools is “autocomplete, but better.”

That model is now too small.

A modern coding agent can read large parts of a repository, inspect tickets, modify files, run shell commands, install packages, create branches, write tests, open pull requests and connect to external tools. In some setups, it may also access documentation systems, issue trackers, cloud consoles, databases, logs or deployment workflows.

That is exactly why these tools are valuable. They move from suggestion to execution.

But software that can execute work inside a development environment is not just a convenience layer. It becomes part of the security boundary around the product.

If an attacker can influence what the agent reads, what it executes, which tools it calls, which credentials it sees or which files it trusts, the risk is no longer theoretical. The agent sits near source code, secrets, dependencies, build systems and sometimes production-adjacent workflows.

That is a privileged position.

Founders and product teams do not need to understand every exploit technique to make better decisions here. They only need to accept the architectural reality: coding agents belong in the threat model.

The risk is not only bad generated code

Many teams already understand one AI risk: the agent might write incorrect code.

That is real, but it is only one layer.

The deeper risk is that the agent operates inside a larger environment:

• the developer’s machine;
• the repository and its configuration;
• dependency installation;
• test and build scripts;
• local environment variables;
• connected SaaS tools;
• CI/CD tokens;
• browser sessions;
• project documentation;
• memory and context files;
• MCP servers and tool integrations.

An AI coding workflow can fail even if the generated code looks reasonable. The problem may be in how the agent was prompted, what context it trusted, which command it executed, which package it installed, which credential was exposed or which change bypassed normal review.

This is why the Pwn2Own category is strategically interesting. It frames coding agents as attackable runtime environments, not just as code generators.

For serious companies, that is the right framing.

Productivity tools become supply-chain tools

Software teams already know that the supply chain matters. Dependencies, package registries, CI systems, GitHub Actions, Docker images and build scripts all became security topics because they sit on the path between idea and production.

Coding agents are joining that path.

They can:

• suggest dependencies;
• edit lockfiles;
• change build scripts;
• modify infrastructure configuration;
• create migration code;
• generate tests;
• change authentication logic;
• summarize or rewrite security-sensitive code;
• automate repository tasks.

That does not make them bad. It makes them consequential.

A compromised or poorly controlled coding agent workflow can create the same kind of business risk as a compromised CI token or malicious dependency: the tool is trusted because it is part of how software gets built.

This is especially important for small and mid-sized teams. A large enterprise may have separate endpoint security, application security, DevOps, platform engineering and procurement processes. A founder-led SaaS team or Mittelstand product group often has a much smaller operating surface. The same person may choose the tool, connect the repository, approve the pull request and deploy the change.

In that environment, the safety model has to be simple enough to use and strong enough to matter.

What a sensible adoption model looks like

The first step is not a 40-page AI policy. The first step is deciding where the agent is allowed to operate.

Good questions include:

• Which repositories may the agent access?
• Can it read all code or only selected projects?
• Can it run arbitrary shell commands?
• Can it install dependencies?
• Can it access secrets or environment variables?
• Can it connect to production data?
• Can it modify infrastructure or deployment files?
• Can it open pull requests directly?
• Which changes always require human review?
• Which logs are kept when the agent acts?

These questions are not bureaucracy. They are the minimum operating model for software that can act inside the delivery process.

At McDougall Digital, this is the point we usually emphasize with clients: AI-supported development becomes much safer when the architecture and workflow decide the boundaries, not the mood of the person using the tool that day.

Keep production far away at first

Many problems disappear if teams start with a simple rule: coding agents should not touch production systems by default.

That means:

• no production database credentials in the agent environment;
• no live customer data in prompts or local context;
• no deployment permissions in normal coding sessions;
• no unrestricted access to cloud consoles;
• no automatic infrastructure changes;
• no irreversible commands without explicit approval.

This does not make the tools useless. Most useful coding-agent work happens before production: refactoring, test generation, documentation updates, bug investigation, internal tooling, scaffolding, code review support and pull request preparation.

A team can get real productivity gains without letting the agent sit next to production credentials.

The same principle applies to customer data. If an agent needs realistic data for testing, use synthetic or anonymized fixtures. If it needs logs, scope them carefully. If it needs access to a staging environment, keep that environment separated from production.

The goal is not to distrust AI. The goal is to make a mistake survivable.

Treat agent configuration as security-sensitive

Many coding-agent setups now include project instructions, memory files, tool definitions, local scripts, MCP server configuration, custom commands and environment-specific rules.

Those files are easy to treat as harmless documentation.

They are not always harmless.

If an agent reads a repository instruction file before acting, that file can influence behavior. If a local tool definition tells the agent how to call a service, that definition can expose assumptions. If a memory file stores previous project context, it can shape future decisions. If MCP or plugin configuration connects external systems, it becomes part of the trust boundary.

Teams should review these files with the same seriousness they apply to CI configuration:

• Who can edit them?
• Are changes reviewed?
• Do they contain secrets?
• Do they encourage unsafe commands?
• Do they reference trusted systems clearly?
• Are prototype instructions separated from production workflows?

This is a new habit for many teams. It will become normal quickly.

Pull requests are still the control surface

The most practical boundary remains the pull request.

A coding agent can prepare work. It can write tests. It can suggest migrations. It can explain a change. It can even run local checks. But product changes should still enter the system through reviewable, testable, reversible pull requests.

That means:

• small changes;
• clear acceptance criteria;
• separate refactoring from feature work;
• automated tests before review;
• dependency and secret scanning;
• human approval for risky areas;
• a rollback path for production changes.

The reason is simple: humans can only take responsibility for what they can see.

If an agent produces a giant diff across application code, configuration, dependencies and infrastructure, review becomes theatre. If it creates a focused pull request with tests and a clear explanation, the team can make a real decision.

This is also where AI can help safely. A good agent can be asked to improve the pull request: reduce scope, add tests, explain assumptions, identify risky files, prepare migration notes and highlight areas that require human attention.

That is very different from letting the agent merge its own work.

Vendor choice is now a security decision

Teams often choose coding tools based on developer preference, model quality or price.

Those still matter. But for production software, vendor security posture also matters.

Useful questions include:

• How does the tool isolate projects?
• What data is sent to remote services?
• What is retained?
• How are local commands approved?
• How are extensions and plugins controlled?
• How quickly are vulnerabilities patched?
• Is there enterprise logging?
• Can the tool be configured differently for different repositories?
• Does it support least-privilege workflows?
• What happens when an employee leaves?

This does not mean every team needs an enterprise procurement process before trying a tool. It means the decision changes when the tool moves from personal experiment to part of the company’s delivery system.

For a founder building a prototype, speed may be the priority. For a B2B SaaS product with customers, contracts and production data, the bar is higher. For regulated or security-sensitive work, the bar is higher again.

The mistake is using the same setup for all three.

The German market will care about this

German clients are often pragmatic about software risk. They do not necessarily need the newest tool first. They need systems that behave reliably, protect data and can be maintained over time.

That does not conflict with AI-supported development. In fact, it creates an opportunity.

If a company can say, “We use AI coding agents, but we run them with scoped access, reviewable pull requests, no production secrets, controlled tool integrations and clear logs,” that is a much stronger position than pretending AI is not involved.

Transparency and discipline can become part of the value proposition.

This matters for founders selling into the Mittelstand, for product owners modernizing internal tools, and for CTOs trying to increase delivery speed without weakening trust. AI adoption will be judged less by the demo and more by the operating model around it.

A practical readiness checklist

Before making coding agents a normal part of delivery, teams should be able to answer a few concrete questions:

1. Which tools are approved for which kinds of work?
2. Which repositories and data sources can each tool access?
3. Which commands require approval?
4. Where are secrets excluded from agent context?
5. How are project instructions, memory and tool definitions reviewed?
6. Which changes must go through pull requests?
7. Which tests and scans run before human review?
8. Who owns an agent-assisted change after it is merged?
9. How would the team investigate a suspicious agent action?
10. How are tools updated or removed when risk changes?

If those answers are unclear, the company does not need to stop using AI. It needs to narrow the initial use cases and improve the operating model.

Start with low-risk, high-value workflows:

• test generation for existing behavior;
• documentation updates;
• internal scripts;
• refactoring inside well-tested modules;
• static analysis support;
• pull request summaries;
• backlog investigation;
• migration planning without automatic execution.

Then expand as confidence grows.

The right lesson from Pwn2Own

The wrong lesson is: “AI coding agents are dangerous, so avoid them.”

The better lesson is: “AI coding agents are powerful enough to deserve the same engineering discipline as the rest of the delivery chain.”

That is a healthy sign. Tools become important enough to attack when they become important enough to matter.

For serious products, the goal is not to use less AI. The goal is to use AI in a way that is bounded, observable and aligned with the product’s risk profile.

This is where architecture matters. Not architecture as abstract diagrams, but architecture as the set of decisions that make software understandable and controllable: boundaries, permissions, tests, deployment paths, ownership and recovery.

AI can accelerate implementation. It cannot replace those decisions.

How McDougall Digital can help

McDougall Digital helps teams adopt AI-supported software development without turning delivery into a trust exercise.

That can start with a coding-agent readiness review: which tools are in use, where they run, what they can access, which repositories and credentials are exposed, how changes move into production, and where the current workflow relies too much on informal judgement.

From there, the work becomes practical: scoped agent workflows, safer repository setup, CI and secret scanning, clearer pull request rules, test improvements, tool integration boundaries, documentation and production-readiness work.

The aim is not to slow the team down. The aim is to make the speed usable for serious products.