Can you review an app we built with an AI coding agent?

Yes. That's the AI-Built App Security Review, which covers one application and the cloud account it runs in. I check the paths in this guide: secrets, dependencies, the CI pipeline, the agent's own permissions, and authorisation on every API route. The review is €500, and the review with remediation is €3,500. It's a code and configuration review, not a penetration test.

Is AI-generated code less secure than code our developers write?

The benchmarks test a model on its own, without review or tools, so they don't answer that directly. They do show that a model's code fails a security check often enough that it can't skip review. In my view, the bigger change is volume. More code reaches the review queue than before, so the gates have to be automatic.

Can we let an agent deploy to production?

Yes, through the same pipeline as human changes, and never with its own production credentials. The agent opens a pull request, the pipeline runs the checks, and a deployment role that only CI can assume does the release. An agent that holds production keys turns any prompt injection into a production incident. I keep that path closed even for internal tools.

Do MCP servers need their own review?

Yes. An MCP server is a dependency with access to the agent's context and often to real credentials, so it gets the same review as any package. I pin each server to a version, run it with its own scoped token, and read its tool descriptions, because those descriptions are text the model follows. A server from an unknown publisher stays out of any session that can reach production.

What would you fix first?

Credentials on developer machines and in CI. That means short-lived cloud sessions instead of static keys, no secrets in any runner where an agent reads untrusted text, and every third-party action pinned to a commit. Those three close the paths behind the incidents in this guide, and they take days, not months. Which long-lived keys could an agent on your team read today?

All guides

Guide

Securing AI-generated applications in the public cloud

What changes when an agent writes the code: the new attack paths, the controls that close them on AWS, Azure, and Google Cloud, and the EU reporting clock.

Veracode has tested AI-generated code against the same set of tasks since July 2025. Its October 2026 report puts the average security pass rate at 62%, the first real improvement in the series, which still leaves 38% of samples with a known vulnerability. In the summer edition, cross-site scripting and log injection passed only about 15% and 12% of the time. The code compiles almost every time, so the flaws arrive looking finished.

The code is only half the change. The agent that wrote it ran on a laptop or a CI runner with real credentials, read untrusted text, and installed packages on its own. I'm starting to see attacks aimed at that half: malware that drives a developer's AI agent to hunt for secrets, and pull request titles that talk a review bot into posting its API key. This guide covers both halves, in the order I'd close them on a public cloud.

This is an engineer's reading of tools and threats that change from month to month. I wrote it from my own setups and the sources named in each section, checked on 9 November 2026. It isn't legal advice. Versions, prices, and defaults move fast, so I recommend checking each tool's current documentation before copying a setting.

Does it apply to you?

If one of these lines describes your team, the rest of this guide applies. If none does, the AI part of the risk is probably small, and the usual cloud security work comes first. A thirty-minute call is a quick way to see which side of that line a platform sits on.

We ship code to AWS, Azure, or Google Cloud that an AI agent wrote or changed, and a human reads only part of it.
Our developers run Claude Code, Codex, Cursor, or similar agents on machines that hold cloud credentials, SSH keys, or production tokens.
We run an AI agent inside CI for review, triage, or fixes, and it reads pull requests or issues from people outside the team.
Our product calls a language model, uses tools through MCP, or lets an agent act on customer data.
We sell an app, SDK, agent, or other software that customers in the EU install. The Cyber Resilience Act's reporting duty already applies to that.

What it asks of your platform

Generated code is an untrusted contribution

I review agent code the way I'd review a pull request from a capable stranger. It passes the same gates as human code: static analysis, dependency and secrets scanning, and tests, all as required checks that a merge can't bypass. Security-relevant paths get a named owner in CODEOWNERS, so a change to authentication, payments, or infrastructure code waits for a person. Agents write more code than people can read, so I put the human attention on those paths and let the scanners carry the rest.

One pattern I now copy into every repository is a scan that a pull request can't edit. The scanner checks out from the main branch, and the pull request's code sits in a separate folder. Every third-party GitHub Action is pinned to a full commit SHA, not a tag. In March 2025, an attacker rewrote the version tags of tj-actions/changed-files, which ran in more than 23,000 repositories, and every workflow that trusted a tag ran the attacker's code (CVE-2025-30066).

Dependencies the model invented

Language models recommend packages that don't exist. A study at USENIX Security 2025 tested 16 code models across 576,000 samples and found that 19.7% of recommended packages were hallucinated. It also found that 43% of those names came back in every run of the same prompt. A repeatable name is a registrable name, so an attacker can publish malware under it and wait, a practice now called slopsquatting.

Typosquatting filters miss these names, because a hallucinated name often looks nothing like a real one. I route every install through a private registry proxy, such as AWS CodeArtifact, Azure Artifacts, or Google Artifact Registry, and set the package manager to refuse very new releases where it supports that, as pnpm does. Lockfiles are mandatory, and CI installs with install scripts disabled where the ecosystem allows it. An agent can't add a dependency without a human approving the lockfile change.

The agent's machine is part of the attack surface

In August 2025, malicious versions of the Nx build system ran a post-install script that called Claude Code, Gemini CLI, and Amazon Q on developers' machines. It started them with their permission prompts switched off and asked them to find wallets, tokens, and keys. GitGuardian counted 2,349 distinct secrets leaked in the first wave alone. Snyk later reported that the CI workflow behind the stolen npm publishing token was likely written by an AI coding agent.

I run agents inside a sandbox with both filesystem and network isolation, because either one alone leaves a way out. Claude Code's sandbox uses bubblewrap on Linux and Seatbelt on macOS, and Codex keeps network access off in its default workspace-write mode. Unattended runs belong in a container or a cloud development environment with no long-lived credentials in it. Cloud access comes from short-lived, scoped sessions through AWS IAM Identity Center, Microsoft Entra ID, or Google Cloud workload identity federation, never from keys in a dotfile.

AI agents in CI read text from strangers

In April 2026, researchers showed that a crafted pull request title could make Anthropic's Claude Code security review action, Google's Gemini CLI action, and GitHub's Copilot agent leak the secrets in their runners. Anthropic rated its finding 9.4 on the CVSS scale. Microsoft published a similar finding about the Claude Code GitHub Action in June 2026. The pattern is general: an agent that reads untrusted text and holds a secret is one sentence away from sending it.

I give a review agent read-only tools and no shell. I run it on the pull_request trigger, which withholds secrets from forks, instead of pull_request_target, so an outside contribution waits for a maintainer to approve a run. The workflow token gets the narrowest permissions the job needs, and the model's API key lives in a separate job from anything that can write. The bot posts comments, and a human merges.

Prompt injection and agency in the product

When the product itself calls a model, the OWASP Top 10 for Agentic Applications, published in December 2025, is the checklist I start from. Its first entry is goal hijack, where content the agent reads redirects what it does. No filter catches every injection, so I design on the assumption that one will get through. The question becomes what the agent can reach once it does.

Each agent gets its own workload identity with least privilege: an IAM role, a managed identity, or a service account scoped to the tools it actually uses. Tool calls that move money, delete data, or message customers need a human approval or a deterministic policy check outside the model. Retrieved documents and tool output are data, never instructions, and I keep them out of the system prompt. Amazon Bedrock Guardrails, Azure AI Content Safety's Prompt Shields, and Google Cloud Model Armor add a layer, but they don't replace the permission design.

Logs, evidence, and the reporting clock

Every agent action in production needs a trace: the prompt, the tool calls, the identity behind them, and the result, kept in a log the agent can't edit. CloudTrail, Azure Monitor, and Cloud Audit Logs cover the cloud side, and OpenTelemetry traces cover the model calls. Those logs are also the evidence a customer's NIS2 questionnaire or an AI Act review asks for. Without them, an incident review has nothing to stand on.

The Cyber Resilience Act added a deadline that didn't wait for 2027. Since 11 September 2026, manufacturers of products with digital elements have had to report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform, with an early warning within 24 hours (Regulation (EU) 2024/2847, art. 14). Pure SaaS sits outside the Act in most readings, but an app, SDK, agent, or CLI that customers install sits inside it. My source is ENISA's announcement of the platform, checked on 9 November 2026.

How I help

The engineering behind the guide. Each one starts with a map of the platform as it runs today.

Book a call

Where to start

AI-Built App Security Review

We read the app your AI coding agent wrote the way an attacker would, from the secrets in the repository to the cloud account it runs in. The result is a ranked list of what to fix first, and the fixes too if you want them.

€500 to €3,500

See what's included

Cloud security hardening

I find the gaps in your cloud accounts, identity, network, and data, rank them by what an attacker reaches first, and close them with your team.

AI-built app security review

I review the app your AI coding agent wrote, from secrets and sign-in to the cloud account behind it, and rank what to fix first. From €500.

AI integration

I put language models to work on the problems that matter in your product and back office, and I ship them to production.

NIS2

What the NIS2 directive asks of a startup's cloud platform, how to tell whether a company is in scope or a supplier to one that is, and what to fix first.

DORA

What the Digital Operational Resilience Act asks of a fintech's cloud platform, and what its contract rules mean for suppliers to banks and insurers.

EU AI Act

How the EU AI Act sorts AI systems into risk tiers, which tier your product is likely in, when the rules apply, and what they mean for the way a team builds.

GDPR

What the GDPR asks of a startup's cloud platform in engineering terms: controller or processor, the records to keep, and the controls that prove it.

EU data residency in the cloud

How to keep customer data in EU regions on AWS, Azure, and Google Cloud, what still leaves, and the controls that prove it to a customer or auditor.

AI-assisted development

How I set up Claude Code, Codex, and similar agents for a team: instruction files, prompts, retrieval, shared memory, and multi-agent code review.

GitHub best practices (free)

A free guide to GitOps guardrails on GitHub: rulesets, independent reviewers, required pull requests and checks, Conventional Commits, and branch names.

Can you review an app we built with an AI coding agent?: Yes. That's the AI-Built App Security Review, which covers one application and the cloud account it runs in. I check the paths in this guide: secrets, dependencies, the CI pipeline, the agent's own permissions, and authorisation on every API route. The review is €500, and the review with remediation is €3,500. It's a code and configuration review, not a penetration test.
Is AI-generated code less secure than code our developers write?: The benchmarks test a model on its own, without review or tools, so they don't answer that directly. They do show that a model's code fails a security check often enough that it can't skip review. In my view, the bigger change is volume. More code reaches the review queue than before, so the gates have to be automatic.
Can we let an agent deploy to production?: Yes, through the same pipeline as human changes, and never with its own production credentials. The agent opens a pull request, the pipeline runs the checks, and a deployment role that only CI can assume does the release. An agent that holds production keys turns any prompt injection into a production incident. I keep that path closed even for internal tools.
Do MCP servers need their own review?: Yes. An MCP server is a dependency with access to the agent's context and often to real credentials, so it gets the same review as any package. I pin each server to a version, run it with its own scoped token, and read its tool descriptions, because those descriptions are text the model follows. A server from an unknown publisher stays out of any session that can reach production.
What would you fix first?: Credentials on developer machines and in CI. That means short-lived cloud sessions instead of static keys, no secrets in any runner where an agent reads untrusted text, and every third-party action pinned to a commit. Those three close the paths behind the incidents in this guide, and they take days, not months. Which long-lived keys could an agent on your team read today?

Let's talk.

A 30-minute call, no pitch. We look at your current setup, your stage, and the thing that's bothering you about it. I give a straight opinion on what to change, what to leave alone, and whether the problem is the one it looks like. What's the one thing in your stack you'd fix tomorrow?

Book a call See pricing

Prefer email or phone? hello@netninjas.eu or +31 6 45984313