Palo Alto Networks' Unit 42 recently published an investigation that deserves more attention from anyone shipping AI-built software. A single attacker used frontier AI agents to breach an enterprise network autonomously. They compressed roughly two weeks of coordinated red-team hacking into under 10 hours. The agents mapped the victim's network, raided their code repositories, seized root credentials, hijacked CI/CD pipelines, and turned the victim's own cloud AI infrastructure into a platform for further exploits.
What makes the case worth reading carefully is what was not involved. There was no zero-day. No elite, novel tradecraft. The attacker pointed AI agents at the routine gaps that exist in most environments and let automation go to work with speed and coordination.
As we read the attack chain at Unit 42, we were struck by how clearly each stage mapped onto a finding we document in routine audits of AI-built applications. The same exposures, at smaller scale, in the apps people are shipping right now.
Here is each stage of the attack, how common the underlying exposure is in the AI-built apps we review, and the straightforward practice that closes it.
Stage 1: Infiltration through a public-facing service
The attacker breached a publicly accessible web service and tunneled into the network, then deployed an automated recon agent to map internal microservices.
This is the entry point, and it's the entry point because public-facing services in AI-built apps are frequently under-protected. We routinely find endpoints that accept unvalidated input, CORS policies set to allow any origin, no rate limiting on any route, and admin or debug endpoints left reachable in production. The application works, and from the outside it looks complete, but the boundary between "the internet" and "the internal system" is thinner than it appears.
How to fix: validate input on every server-side endpoint, enforce authentication and authorization on each request (not just in the UI), restrict CORS to your actual frontend domain, add rate limiting, and strip development and debug routes from production builds. None of that is exotic: it's as simple as a checklist, and it's the difference between a public service that invites recon and one that doesn't.
Stage 2: Secrets harvested from code repositories
Once inside, sub-agents combed the victim's code repositories, extracting hard-coded tokens and service passwords.
This is the single most common finding across every AI-built application we audit. When you ask an AI tool to connect your app to Stripe, or OpenAI, or a database, it needs credentials, and the simplest way to make the app work is to put the credentials in the source. Sometimes as a constant at the top of a file. Sometimes as a default fallback alongside a process.env reference, which looks responsible while still exposing the live key. The application runs, the demo passes, and the secret is committed to the repository.
In the Unit 42 case, repository access gave the attacker every credential the codebase contained. The same is true for any AI-built app with secrets in source. If the repo is public, or becomes public, or is accessed by anyone who shouldn't have it, every connected service is compromised at once.
How to fix: move every credential to environment variables or a secrets manager, add .env to .gitignore, and rotate any key that has already been committed. Deleting a secret from the current file does not remove it from git history. Add secret scanning to CI so a committed key fails the build before it ships. This is remediation we perform on virtually every engagement, and it is among the highest-impact, lowest-effort changes available.
Stage 3: Privilege takeover through exposed tokens
Using the tokens harvested from repositories, the attacker infiltrated the organization's secrets management system and obtained master administrative credentials, seizing control of root system access.
The escalation worked because the tokens were highly-privileged and the access they granted was broad. We see the same issue in AI-built apps, just closer to the application layer. Session tokens that never expire. Tokens stored in localStorage and accessible to any JavaScript on the page. Flat authorization, where one authenticated user can request another user's records by changing an identifier in the URL. Admin panels hidden behind a client-side role check while every admin API endpoint responds to any authenticated user who knows the route.
So, the UI says you can't access it? Oops! The server says you can.
How to fix: tokens should expire and be rotatable. Sessions belong in HTTP-only cookies, not client-accessible storage. Authorization must be enforced server-side on every request, independently of what the frontend decided to show. Service tokens should carry the narrowest scope that does the job.
Stage 4: CI/CD pipeline exploitation
The attacker hijacked an enterprise code application through custom workflows to exfiltrate cloud access keys, and attempted to plant backdoors in Terraform configurations.
This is the stage where the attack failed, and it failed for a specific reason: hard branch-protection controls stopped the Terraform backdoor from landing. One control, correctly configured, blocked an entire class of move.
Most AI-built apps have no equivalent control. We frequently find infrastructure-as-code repositories that are writable by anyone with repository access, no required reviews, no protected branches, and no separation between development and production environments. A change to a Terraform file, a docker-compose file, or a deployment config can reach production with no gate. When the build pipeline and the production environment share credentials and configuration, a single compromise cascades.
How to fix: enforce mandatory, multi-party code review and immutable branch protection on every repository. Separate CI/CD credentials and configuration per environment so a development pipeline cannot touch production resources. The Unit 42 case is the clearest possible argument for this: this control is the one that broke the attack chain.
Stage 5: AI infrastructure hijacking
Using stolen cloud keys, the attacker turned the victim's AI endpoints into post-compromise infrastructure, using the company's own compute power to support further moves and hiding orchestration traffic inside expected usage.
This is the newest stage, and it's the one most directly relevant to AI-built applications. As more apps integrate LLM APIs, the keys to those APIs become high-value targets. When those keys are committed to source, over-privileged, or unmonitored, a leak doesn't just cost money on a fraudulent bill. It hands an attacker free compute and a place to hide. Traffic to a compromised OpenAI or Anthropic key looks like normal application usage, which makes detection harder.
How to fix: treat every AI endpoint and key as core infrastructure. Inventory them. Apply least-privilege scopes, strict rate limits, and rotation. Monitor for usage anomalies, bursty requests, and calls from unexpected identities. The same governance discipline you'd apply to any production credential now applies to your model API keys, and most AI-built apps haven't applied it yet.
What the attack actually proves
The Unit 42 investigation is being read as a story about how fast AI agents can move. That's part of it. But the more useful reading, for anyone building or receiving AI-built software, is about what the agents were pointed at.
They were pointed at:
- Routine gaps
- Hardcoded secrets
- Over-privileged tokens
- Unprotected pipelines
- Unmonitored AI endpoints
- A public service with no meaningful boundary
None of these required a zero-day. None required elite tradecraft. They required an environment where the ordinary production controls were never implemented, and an attacker who knew that.
That describes most AI-built applications. The initial build optimizes for the feature request. The controls that sit around the feature, the ones that determine whether the app survives contact with a real threat, are usually never part of the prompt. They're the same controls we find missing in audit after audit, regardless of which tool built the app.
The difference is a short list
The difference between an application that gets walked in 10 hours (courtesy of the new agentic attackers) and one that doesn't is a short list of ordinary controls:
- Validate input and enforce authorization on every server-side endpoint.
- Keep secrets out of source, and scan for them in CI.
- Make tokens expire, scope them narrowly, and enforce authorization server-side.
- Protect your infrastructure-as-code branches and separate your environments.
- Inventory and govern your AI API keys the way you govern any other credential.
Each item is straightforward to implement once someone deliberately looks for it. The reason these gaps persist is that they're hard to remember to look for, because they were never part of the original build.
That's the work we do. We walk the same surface the attacker walked, before they get there, and hand you the list. The Unit 42 case shows what happens when someone walks it first from the outside. A production-readiness review is the same walk, taken on your behalf, while there's still time to act on what it finds.