Chess-Inspired API Discovery: How Escape's Security Agents Map Shadow Endpoints

Most API security tools assume you know what APIs exist. Escape (YC W23) starts from the opposite position: large organizations have hundreds or thousands of APIs, many undocumented, and security teams discover breaches only after attackers find them first. The team borrowed search strategies from chess engines to build an agent that enumerates endpoints, infers schemas, and prioritizes scanning without requiring OpenAPI specs or access logs.

The chess analogy is not marketing. It describes a specific search problem: given partial information about a state space (your API surface), how do you efficiently explore branches (potential endpoints) and evaluate which paths (vulnerabilities) matter most?

The Discovery Problem

Traditional API security tools require one of three inputs:

OpenAPI or Swagger specifications
Web application firewall logs
Manual endpoint registration

None of these work when developers ship APIs without documentation, when traffic logs are incomplete, or when microservices proliferate faster than inventory systems can track them. The 2018 Facebook breach that exposed 50 million accounts happened because an undocumented API endpoint had a vulnerability that security teams never scanned.

Escape’s agent solves this by treating API discovery as a search problem. It starts with minimal seed information (a domain, a known endpoint, or traffic samples) and explores the space of possible API routes.

Chess Search Applied to Endpoints

Chess engines use minimax search with alpha-beta pruning. They evaluate positions by looking ahead several moves, pruning branches that cannot possibly improve the outcome, and prioritizing lines that maximize advantage.

Escape adapts this:

Lookahead: Instead of evaluating one endpoint at a time, the agent predicts likely related endpoints based on patterns. If it finds /api/users/{id}, it tests /api/users/{id}/orders, /api/users/{id}/payments, and /api/admin/users/{id} in parallel.

Pruning: Not every discovered endpoint matters equally. The agent scores routes based on:

Presence of authentication requirements
Parameter types that suggest sensitive data (IDs, tokens, emails)
HTTP methods that allow mutation (POST, PUT, DELETE)
Response codes that indicate logic errors (500s, unhandled exceptions)

Evaluation function: The agent ranks endpoints by exploitability, not just existence. An unauthenticated DELETE route scores higher than a public GET route that returns static content.

This is different from traditional crawlers, which follow links exhaustively. The chess-inspired approach prunes low-value paths early and focuses compute on branches likely to expose risk.

Schema Inference Without Specs

Once the agent discovers an endpoint, it needs to understand what parameters it accepts and what data it returns. Without an OpenAPI spec, this requires inference.

Parameter fuzzing: The agent sends requests with varied parameter types (strings, integers, arrays, nested objects) and observes:

Which parameters are required (400 vs 200 responses)
Which types are accepted (type coercion errors)
Which values trigger validation logic (regex patterns, length limits)

Response shape analysis: The agent parses JSON responses to infer schema structure. If /api/users/123 returns:

{
  "id": 123,
  "email": "user@example.com",
  "role": "customer",
  "created_at": "2024-01-15T10:30:00Z"
}

The agent infers:

id is an integer, likely a primary key
email is a string, possibly PII
role is an enum, suggesting authorization logic
created_at is a timestamp, useful for enumeration attacks

Traffic pattern correlation: If the agent has access to partial traffic logs (even anonymized), it correlates request patterns to infer relationships. Requests to /api/orders followed by /api/payments suggest a workflow dependency.

Prioritization Under Constraint

A fintech organization might have 800 APIs. Scanning all of them for every OWASP Top 10 vulnerability would take days and generate thousands of findings. The agent needs a priority queue.

Priority Tier	Criteria	Example
Critical	Unauthenticated + mutation + PII	`DELETE /api/accounts/{id}` with no auth
High	Authenticated + mutation + financial data	`POST /api/transfers` with weak rate limits
Medium	Authenticated + read + sensitive data	`GET /api/transactions/{id}` with IDOR risk
Low	Public + read + non-sensitive	`GET /api/health` returning status

The agent uses this scoring to decide:

Which endpoints to scan first
Which vulnerability classes to test (SQL injection, NoSQL injection, IDOR, SSRF)
How much time to spend on each endpoint before moving on

This is a resource allocation problem. The agent balances coverage (scanning everything eventually) with urgency (finding critical issues fast).

Orchestration Flow

The discovery agent runs as a continuous background process, not a one-time scan. The flow:

Seed collection: Ingest known endpoints from CI/CD metadata, DNS records, or initial manual input
Exploration phase: Use chess-inspired search to enumerate related endpoints
Schema inference: Fuzz parameters and analyze responses to build internal API models
Vulnerability scanning: Test high-priority endpoints for exploitable issues
Feedback loop: Discovered endpoints become new seeds for the next iteration

State management is critical. The agent maintains:

A graph of discovered endpoints and their relationships
A priority queue of endpoints awaiting deeper scanning
A history of tested parameter combinations to avoid redundant work
A map of confirmed vulnerabilities and their remediation status

Failure Modes

False positives from fuzzing: Aggressive parameter testing can trigger rate limits or WAF rules, causing the agent to misclassify legitimate endpoints as vulnerable. Mitigation: respect Retry-After headers and back off when 429 responses appear.

Schema drift: APIs change between scans. An endpoint that returned JSON last week might return XML today, breaking inference logic. Mitigation: version schema snapshots and flag breaking changes for manual review.

Authentication boundary confusion: The agent might discover an endpoint but fail to test it properly if it cannot obtain valid credentials for different user roles. Mitigation: integrate with identity providers or credential vaults to test endpoints under multiple personas.

Compute cost: Deep exploration of large API surfaces consumes significant compute. A single fintech org might have 10,000 potential endpoint variations. Mitigation: use the priority queue aggressively and set time budgets per endpoint.

Deployment Shape

Escape runs as a SaaS platform, but the architecture suggests a hybrid model for enterprises:

Cloud control plane: Manages agent orchestration, stores discovered API inventory, and runs the vulnerability database
On-premises scanner: Deploys inside the customer’s network to access internal APIs without exposing traffic externally
CI/CD integration: Hooks into build pipelines to scan APIs before they reach production

The agent itself is stateless. It pulls work from the priority queue, executes scans, and writes results back to the control plane. This allows horizontal scaling during high-discovery periods (post-acquisition, post-merger).

Security Boundaries

The agent needs broad network access to discover APIs, which creates risk:

Credential leakage: If the agent stores API keys or tokens, it becomes a high-value target. Use short-lived tokens and rotate frequently.
Accidental mutation: Fuzzing DELETE or PUT endpoints can corrupt data. Run discovery agents in read-only mode by default, with explicit opt-in for mutation testing.
Log poisoning: Attackers might inject fake endpoints into logs to mislead the agent. Validate discovered endpoints against known infrastructure before scanning.

Observability

Key metrics for a discovery agent:

Endpoints discovered per hour: Measures search efficiency
False positive rate: Percentage of flagged vulnerabilities that are not exploitable
Time to critical finding: How long between deployment and discovery of a high-severity issue
Coverage percentage: Proportion of known APIs that have been scanned in the last 30 days

Alerting should trigger on:

Discovery of unauthenticated mutation endpoints
Sudden increase in 500 errors (suggests the agent is breaking things)
Credential expiration (agent loses access to authenticated routes)

Technical Verdict

Use Escape’s approach when:

Your organization has distributed API development with weak central inventory
Security teams discover APIs only after incidents
You need continuous discovery, not point-in-time scans
You have the budget for a SaaS platform or the engineering capacity to build similar orchestration

Avoid when:

You have strong API governance and complete OpenAPI specs for all endpoints
Your APIs are entirely internal with no external exposure
You lack the security maturity to act on findings (discovery without remediation creates alert fatigue)
Your APIs use non-standard protocols (gRPC, GraphQL) that require different inference strategies

The chess analogy is apt. API discovery is not exhaustive enumeration. It is strategic search under resource constraints, where the goal is to find the most dangerous vulnerabilities before attackers do.