McKinsey's 200 Exposed APIs: A Teardown

What Happened

McKinsey's internal AI platform exposed over 200 documented endpoints to the internet without authentication. External researchers found these APIs, which provided direct access to internal systems. This wasn't due to an AI vulnerability or a complex attack. It was simply a case of deploying endpoints that responded to anyone who knew where to look.

McDonald's faced a similar issue with their AI-powered hiring system, which had exposed administrative access with weak authentication controls. Two high-profile organizations, same root cause.

Timeline

The exact discovery timeline isn't public, but the pattern is familiar:

1. Organization deploys AI platform with supporting infrastructure.
2. Development teams create APIs to connect AI models to data sources.
3. APIs are deployed to production without authentication requirements.
4. Endpoints remain accessible externally.
5. External researchers discover the exposure.
6. Incident response begins.

The gap between deployment and discovery? Unknown. Unauthenticated endpoints don't log access until credentials are required.

Which Controls Failed

API inventory and discovery. You can't secure what you don't know exists. McKinsey documented 200 endpoints, but how many undocumented ones were running? Shadow APIs, created during rapid development and never cataloged, expand your attack surface every sprint.

Authentication enforcement. The APIs responded to requests without verifying identity. No OAuth, no API keys, no mutual TLS. Just open endpoints waiting for HTTP requests.

External exposure review. These APIs were deployed where external traffic could reach them. Either the network architecture allowed it by default, or nobody checked before deployment.

Continuous validation. These endpoints stayed exposed until external researchers found them. No scanning tool flagged them. No periodic access review caught them. The security team didn't know they existed.

What the Standards Require

The OWASP API Security Top 10 lists "Broken Object Level Authorization" as API1:2023 and "Broken Authentication" as API2:2023. These are critical API security risks, and McKinsey failed both.

PCI DSS v4.0.1 Requirement 6.4.2 mandates protecting web applications and APIs from attacks. If you're processing payment data, unauthenticated APIs to internal systems would fail this requirement immediately. The standard specifically requires authentication for all access attempts.

NIST CSF v2.0 function PR.AC-1 states: "Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users, and processes." Unauthenticated APIs bypass this control entirely.

ISO/IEC 27001:2022 Annex A.9.4.1 requires access control to restrict access to networks and network services. An API that answers requests from any source violates this control.

SOC 2 Type II Common Criteria CC6.1 addresses logical and physical access controls. If you're pursuing SOC 2 certification, your auditor will ask how you control access to APIs. "We don't" isn't an acceptable answer.

Lessons and Action Items

Build an API inventory today. Use runtime discovery tools that watch actual traffic, not just static analysis of your codebase. Platforms like Salt Security can show you what APIs are actually receiving requests. Your documented endpoints are a starting point, not the complete list.

Start with these questions:

• Which APIs are currently accepting external traffic?
• Which of those require authentication?
• Which authentication methods are in use (and are any of them deprecated)?

Require authentication at the gateway. Don't trust individual services to implement authentication correctly. Enforce it at the API gateway or ingress controller before requests reach your services. If a request arrives without valid credentials, it shouldn't make it past your perimeter.

For existing APIs, add authentication in phases:

1. Deploy the gateway with logging only (no blocking).
2. Review logs to identify legitimate vs. unexpected traffic.
3. Enable blocking for unauthenticated requests.
4. Monitor error rates and fix client configurations.

Scan for external exposure weekly. Your attack surface changes every time someone deploys code. Run automated scans from outside your network to find what's actually reachable. Tools like nmap, masscan, or commercial attack surface management platforms can show you what external researchers see.

Create a simple test:

# Can I reach this API without credentials?
curl -X GET https://your-domain.com/api/endpoint
# If you get data back instead of 401/403, you have a problem

Treat AI deployment like any other production system. The "AI" label doesn't exempt you from basic security controls. You're deploying services that connect to data sources and execute code. Apply the same authentication, authorization, and network segmentation you'd use for any production API.

Before you deploy:

• Document every endpoint your AI platform exposes.
• Verify authentication requirements for each.
• Confirm network segmentation prevents unintended external access.
• Add the APIs to your vulnerability scanning rotation.

Fix the process, not just the incident. McKinsey's 200 exposed endpoints didn't appear overnight. They accumulated because the deployment process allowed unauthenticated APIs to reach production. Your incident response should include:

• Why did this pass code review?
• What's missing from our deployment checklist?
• Which automated tests would have caught this?
• How do we prevent the next 200?

The real threat to your AI deployment isn't the model. It's the dozen APIs you created to feed it data, the MCP servers connecting it to tools, and the endpoints you forgot you deployed six months ago. Those are what attackers find first.

API security