We scanned 2,608 public APIs for AI agent risk. Here's what we found.

The numbers

16.1% of public APIs expose at least one pattern that makes them unsafe for unmonitored agentic use. 22.9% had no findings at all — their specs follow patterns that Nexum's five deterministic rules cannot flag. 8.5% had CRITICAL findings, concentrated in auth leakage and destructive ambiguity patterns.

Of the 2,006 APIs with findings, 94.9% of all individual findings are missing idempotency contracts (NEXUM-004) — the most common agentic risk pattern across the entire catalog. Only 8.5% of APIs had CRITICAL findings, concentrated in auth leakage and destructive ambiguity patterns.

Findings by rule

Across all 2,608 specs, Nexum emitted findings across five rule categories. Here's how they break down by rule:

The finding that surprised us most

NEXUM-001 — credentials in query strings — fires on 71% of APIs. This isn't just small hobby APIs. It's Stripe, Slack, Twilio, SendGrid, and dozens of Fortune-500 infrastructure providers.

The root cause: legacy API design. Many APIs were built before bearer tokens became standard. They accepted api_key, token, or access_token as query parameters for "convenience" — and that convenience became load-bearing. Years later, the query-param path is still documented and still tested. Agents will use it.

When an agent sends a credential in a query string, that credential lands in:

• Server access logs (rotated, but often retained for months)
• Reverse-proxy logs (nginx, Cloudflare, AWS ALB)
• Browser history (for any UI that uses the same pattern)
• Referrer headers if the URL is linked anywhere

For a human developer, this is a known risk they can reason about. For an agent executing thousands of calls autonomously, it's a credential-exfiltration surface at scale.

The APIs that scored 100/100

Four APIs that you'd expect to be among the worst offenders — Slack, Stripe, GitHub, DigitalOcean — scored 100/100 on our risk scale. Not because they're safe. Because they're comprehensively, thoroughly risky.

Slack

58 CRITICAL findings. Every admin endpoint accepts token as a query parameter. /admin.apps.approved.list, /admin.conversations.list, /admin.users.list — all of them. An agent with Slack access using the wrong auth path exposes the workspace token in every log line.

Stripe

Multiple CRITICAL findings including /v1/financial_connections/accounts and /v1/payment_intents/{intent}. Stripe's API is extraordinarily well-designed by most metrics — versioned, documented, stable. But the query-param credential path persists for backward compatibility, and Nexum flags it regardless of how unlikely it is to be used in practice.

GitHub

404 findings total. NEXUM-001 fires on /applications/{client_id}/tokens. NEXUM-002 fires on DELETE /notifications and DELETE /user/keys — both delete resources without requiring a specific resource identifier in the URL. An agent that calls DELETE /notifications clears all notifications for the authenticated user, not one specific notification.

DigitalOcean

DELETE /v2/droplets and DELETE /v2/volumes both fire NEXUM-002. These endpoints delete resources by tag — a powerful batch operation for humans with a clear intent, and a catastrophic footgun for an agent that decides "delete these droplets" means "delete all droplets matching this tag."

What this means for teams building with agents

If your agent stack touches any of these APIs, you have three options:

• Scope down the API key. Most providers let you create keys with reduced permissions. An agent that only needs to read data shouldn't have a key that can delete.
• Add a human-in-the-loop gate. For any operation that Nexum flags NEXUM-002 or NEXUM-003, require explicit human confirmation before the agent proceeds.
• Use the Trust Manifest. The Nexum Trust Manifest is a machine-readable contract that tells your agent framework which operations are safe for autonomous execution and which require review. Scan your API, add the manifest to your agent config, and let the framework enforce the guardrails automatically.

Methodology

All 2,608 specs were fetched from the APIs.guru catalog and scanned with Nexum v0.1. Scans are fully deterministic — no LLM, no heuristics beyond rule definitions, no external API calls. Each finding includes the exact evidence snippet from the spec.

Five rules were applied:

• NEXUM-001 — Auth Leakage Risk: credentials in query strings
• NEXUM-002 — Destructive Ambiguity: DELETE/PATCH without specific resource ID
• NEXUM-003 — Unbounded Scope: wildcard parameters or mass operations without filters
• NEXUM-004 — Idempotency Missing: mutating operations without Idempotency-Key support
• NEXUM-005 — Schema Volatility: additionalProperties: true on mutation schemas

Risk score: CRITICAL=25pts, HIGH=10pts, MEDIUM=5pts, LOW=1pt, capped at 100. Tier 0 (0–30): no findings or low risk. Tier 1 (31–60): findings requiring attention. Tier 2 (61–100): high-confidence critical findings.

Full scan data is available in the public registry. Source code and rule definitions are on GitHub.