API Surface
Find the endpoints your OpenAPI spec forgot
Osprey reads live traffic from your gateways and clusters, builds the real inventory, then tests authorisation per role on every endpoint it finds.
Connects to AWS, NGINX, Kubernetes and Envoy in minutes.
osprey / api surface
Workspace
Sources
Endpoints
Findings
Policies
Evidence
Connect a source
View endpoints
last run 4m ago
1,190
Endpoints seen
38
Shadow endpoints
11
Zombie endpoints
Severity · Finding
Critical
PII in the /v1/users response
High
Role check missing on PATCH
Medium
Verbose error on /orders
Low
No pagination cap on /events
Low
Deprecated /v0 still routable
Your spec is a wish. Traffic is the truth.
Without Osprey
An inventory that was accurate the day it was written
Shadow endpoints nobody documented or decommissioned
Authorisation tested per route instead of per role
PII leaking through responses nobody reads
With Osprey
An inventory rebuilt from live traffic, continuously
Shadow, zombie and undocumented endpoints surfaced
Every role tested against every endpoint it can reach
Secrets, PII and over-fetching flagged in the response body
Connect a traffic source and the map builds itself
01
Connect a source
Point Osprey at an AWS load balancer, an NGINX log stream, a Kubernetes ingress or an Envoy mesh. Read-only, no agent to install.
02
Watch the inventory build
Endpoints appear as traffic hits them, tagged as documented, shadow or zombie, with the roles that reached them.
03
Test authorisation per role
Osprey replays each endpoint as every role you define and reports anywhere the answer should have been a 403.
Built for the API surface you actually run
Shadow and zombie discovery
Endpoints serving traffic that are in no spec, and endpoints in the spec that stopped serving months ago. Both are risks.
Reads real traffic sources
AWS, NGINX, Kubernetes and Envoy, read-only. No sidecar, no agent, no change to how requests are routed.
Authorisation per role
Most API bugs are authorisation bugs. Osprey replays every endpoint as every role and flags each one that should have refused.
Response body inspection
Finds secrets, personal data and over-fetching in what your API actually returns, not just in what it accepts.
Ranked by blast radius
An IDOR on invoices outranks a verbose error on a health check, whatever the CVSS calculator says about it.
Correlated with the rest
An exposed endpoint plus a leaked key plus a permissive IAM role is one attack path, and Osprey reports it as one.
Why authorisation is where APIs break
Injection gets the headlines. In practice the finding that ends up on the incident page is almost always a missing ownership check.
Every endpoint replayed as every role you define
Object-level checks, not just route-level checks
Detects horizontal access across tenant boundaries
Flags PATCH and DELETE that skip the ownership check
Confirms the 403 before closing the finding
Endpoint
PATCH /v1/organisations/:id/members
Reached by
Member role, across a tenant boundary
Blast radius
1,190 organisations, 38 with billing access
Questions platform teams ask about discovery
Do you need an agent in our cluster?
No. Osprey reads from sources you already run, with read-only credentials: AWS load balancer logs, NGINX access logs, Kubernetes ingress and Envoy access logs.
Will this add latency to our requests?
No. Discovery reads logs and mirrored traffic out of band. Nothing is added to the request path and nothing is proxied through us.
How do you know which endpoints are shadow?
Osprey diffs live traffic against every spec you upload. Anything serving traffic that is not in a spec is shadow. Anything in a spec with no traffic for 30 days is zombie.
Can you test authenticated endpoints?
Yes, and that is where most findings come from. You provide a token per role, and Osprey replays each endpoint as each role to find authorisation gaps.
What about GraphQL and gRPC?
GraphQL operations are discovered and tested individually rather than as one endpoint. gRPC discovery is supported where reflection is enabled.
Does it work with a private VPC?
Yes. Discovery runs against log sources you grant access to, so nothing has to be reachable from the public internet for the inventory to build.