When security leaders discuss the AI wave in software development, the conversation typically centers on speed: AI assistants generating boilerplate code, scaffolding APIs, writing tests, and even wiring up complex authentication flows in minutes.

What often gets missed is that we’ve seen this movie before. Long before generative AI:

• A single duplicated line in Apple’s TLS stack broke certificate validation (“goto fail”).
• A small logic change in Facebook’s video feature opened the door to access token theft.
• A seemingly harmless debug configuration at Uber inadvertently leaked AWS credentials, which attackers later used to exfiltrate sensitive data.

None of these failures were exotic zero-days. They were subtle code or configuration changes in trusted systems, which are precisely the kind of things AI is now helping teams change faster than any human can review.

Here is the core problem:

The riskiest classes of vulnerabilities today are design and change-driven, not just “bad functions” and known CVEs

Rule-based SAST tools weren’t built to understand why a change is risky in the context of your architecture and data flows. That’s why we built Endor Labs’ AI Security Code Review. It is explicitly designed to fill that gap: a multi-agent AI system that reviews each pull request like an experienced AppSec engineer, and flags the kinds of changes that have turned past incidents into front-page news.

High-profile incidents caused by subtle flaws

Before we unpack the details, here are some of the real-world breaches your teams are already familiar with. These are the kinds of findings AI Security Code Review would have surfaced during development, before they became headlines:

Each of these incidents started as a seemingly ordinary change. Let’s take a look at a few examples of how those same patterns show up in modern, AI-assisted development and how AI Security Code Review would have caught them before they shipped:

1. Facebook Access Token Breach (2018)

In 2018, Facebook disclosed that a code change to a video-related feature unintentionally allowed attackers to obtain access tokens for other users. A seemingly routine update in a complex feature path created a logic flaw: a specific sequence of requests could trick the system into issuing tokens that effectively granted account takeover.

This flaw wasn’t a classic SQL injection or a dangerous API call. It was a broken authorization and token issuance flow buried in an existing feature.

Why traditional tools struggled

A conventional SAST engine would see:

• Familiar frameworks and libraries that are still in use.
• No obviously unsafe function calls were introduced.
• No new “sink” for user input that looks like injection.

From the tool’s perspective, the change appears to be “more application logic,” rather than a newly exposed trust boundary or a weakened control. The real problem was that authorization behavior changed, and nothing told security teams, “this PR quietly altered how tokens are issued and who they can be issued for.”

2. Hard-coded secrets that became headlines at Uber and Toyota

Two incidents tell a very similar story:

• Uber AWS Credentials Leak (2016): A developer accidentally committed hard-coded AWS keys to a GitHub repo, which attackers later found and used to access Uber’s infrastructure.
• Toyota T-Connect API Key Leak (2022): API keys embedded in source code exposed customer email addresses and data for an extended period, forcing public disclosure and key rotation.

In both cases, the root cause was plaintext secrets living in code where they didn’t belong.

Why traditional tools struggled

Some static tools do support “secret scanning,” but in practice:

• Coverage depends on specific patterns and integration hygiene.
• Alerts are often noisy and result in false positives on sample keys, test data, or redacted strings.
• They don’t reason about how the application should handle credentials (e.g., via environment variables or a secret manager) versus what has just changed.

It’s common for organizations to either disable or deprioritize secret-scanning alerts because they’re noisy and lack context.

3. Configuration changes opened floodgates at Capital One & MOVEit

Two other incidents highlight how small changes in configuration and query logic can drive massive impact:

• Capital One Cloud Misconfig SSRF (2019): A misconfigured open-source WAF and overly permissive IAM roles allowed an attacker to leverage SSRF to access AWS instance metadata and, from there, sensitive S3 buckets.
• MOVEit Transfer SQL Injection (2023): A vulnerable file transfer product had SQL injection flaws that enabled attackers to exfiltrate highly sensitive data from countless organizations.

In both cases, the vulnerability was a combination of how a component was configured and how it handled untrusted input.

Why traditional tools struggled

• SAST tools can sometimes flag obvious string-concatenated SQL queries, but they don’t understand the history of a route or query and whether input validation or parameterization just got weaker.
• Many tools don’t see or model security configuration changes in code (WAF rules, IAM policy templates, route protections) as first-class risk signals.
• Cloud misconfigurations are often left to separate tools that don’t see the code context that produced them.

4. T-Mobile’s exposed API becomes a data extraction engine

Attackers abused a poorly protected API to pull customer account data at scale over an extended period. The issue wasn’t a novel exploit chain. It was an API that:

• Was exposed to the internet
• Returned rich customer data sets
• Lacked sufficiently strong authentication, authorization, and abuse controls

From a developer’s perspective, this might have appeared to be a straightforward “self-service” endpoint: accept a customer identifier and return account details. From an attacker’s perspective, it was a data extraction engine.

Why traditional tools struggled

To a conventional SAST tool, this change doesn’t look obviously dangerous:

• It uses standard HTTP frameworks and JSON serialization.
• There are no classic injection sinks or dangerous low-level APIs.
• No new third-party dependencies with critical CVEs appear in the diff.

The core problem is again what’s missing:

• No authentication or weak authentication on an endpoint that returns sensitive data.
• No meaningful authorization checks binding the caller to the requested data.
• No clear rate limiting or abuse protections applied to the route.

Traditional tools don’t have the context to say, “this route is internet-facing, returns high-value customer data, and is not enforcing the same controls as other sensitive APIs.” They see a handler function, not a new public attack surface.

From isolated incidents to a systematic review of your security posture

Looking across these incidents, the pattern is clear:

• The initial change was often small and well-intentioned.
• The impact was huge because that change touched a trust boundary: who can authenticate, what data an API returns, which systems a service account can reach, and where secrets are stored.
• Traditional tools focused on patterns and CWEs, not meaningful changes in security-relevant behavior.

AI Security Code Review is designed to operationalize the lessons from these breaches:

• It categorizes changes (auth logic, secret handling, data exposure, query/validation, config/permissions).
• It employs a multi-agent approach to understand what has changed, why it matters, and how risky it is, rather than simply pattern-matching lines of code.
• It delivers this analysis where it actually moves the needle: as clear, prioritized, human-readable feedback in the pull request.

Conclusion

The public incidents can help guide us on what to watch for in the AI era:

• Tiny authorization tweaks that change who can act as whom.
• Seemingly harmless refactors that weaken validation or widen query scopes.
• Shortcuts that move secrets or sensitive data into places they were never meant to live.

In a world where AI is helping developers generate more of these changes, faster than ever, organizations need an equally capable partner on the security side. One that can recognize these patterns as they emerge, not months later in an incident report.

That’s what Endor Labs’ AI Security Code Review is built to do: connect the dots between the kind of changes your teams ship every day and the types of breaches everyone reads about later.

If you want to dig deeper into these rule categories and see how they apply to your own codebase, read the full AI Security Code Review whitepaper or contact us to arrange a walk-through of PRs from your environment.