Self Hosted API Discovery and Enforcement
API Security Local Edition is a self-hosted platform that discovers APIs from live traffic, maintains an inventory with inferred schemas and risk scoring, and pushes enforcement actions to BIG-IP. Because it runs entirely within the local environment, no traffic telemetry or API metadata leaves the perimeter, which makes it viable for deployments where a SaaS-based solution is ruled out: air-gapped networks, environments with data residency constraints, and compliance regimes that require all components to sit inside an audited boundary.
This article covers the deployment architecture, the data flows between components, and the discovery-to-enforcement workflow. The demo video at the end shows the workflow running against live traffic.
Architecture
1. The data plane is untouched
API Security Local Edition is not inline. Client requests continue to traverse BIG-IP on their way to the backend applications, exactly as they did before Local Edition was deployed. No proxy is inserted, no additional hop is added to the request path, and no client-facing change is required. Because BIG-IP is already in the traffic path acting as the gateway and traffic manager, it is already positioned to observe the full HTTP exchange (method, URI, headers, payloads, response codes), and discovery rides on traffic that is already passing through it.
2. Traffic insights are the input to discovery
BIG-IP forwards HTTP traffic insights to Local Edition out-of-band. This telemetry, not live traffic interception, is what the platform analyzes. From observed insights the platform:
- Discovers endpoints dynamically as they appear, including endpoints not present in any uploaded specification (shadow APIs) and previously known endpoints that are still serving traffic (zombie APIs).
- Infers schemas and analyzes usage patterns per endpoint.
- Flags sensitive data in requests and responses (for example credentials, tokens, and PII).
- Assigns a risk score per endpoint derived from the contributing factors it observes.
Because analysis runs on telemetry rather than on inline traffic, Local Edition can be added to and removed from an existing BIG-IP deployment without affecting production traffic flow.
3. Enforcement is operator-initiated and applied on BIG-IP
The third flow only fires when you act on a finding. When you choose to block an endpoint, Local Edition fetches the relevant BIG-IP security policy, computes the change, and presents it for review: the target BIG-IP, the security policy, the affected virtual server, and the specific modification to be applied. The change is only pushed after explicit approval. Enforcement is applied on BIG-IP, the device you already operate, so the runtime policy enforcement point is unchanged from a normal BIG-IP deployment. The full control loop from discovery to enforcement stays inside your environment.
Workflow
The typical workflow has four phases: seeding the inventory, running discovery, reviewing and acting on findings, and managing the inventory over time.
Seeding the inventory
The inventory can be populated two ways: by uploading an OpenAPI Specification for a domain, by letting discovery surface endpoints from observed traffic, or by some combination of both. Uploading an OAS gives you a known-good baseline of declared endpoints, each with an initial risk score, identified sensitive data fields, and authentication status. Discovery then fills in the gaps with endpoints that are seeing traffic but were not in the documentation.
In a greenfield environment with no specification on hand, you can let discovery build the inventory from scratch. In an environment with an existing OAS, uploading it first gives you a clear distinction between what was declared and what discovery finds outside the declared set.
Running discovery
Discovery is triggered from the base dashboard. The base dashboard aggregates state across all onboarded domains: total shadow and zombie API counts, the number of endpoints carrying sensitive data, and an overall risk score for the API surface. Triggering Analyze processes the collected traffic telemetry and updates the inventory with what it finds.
Endpoints discovered outside the uploaded specification are categorized as shadow APIs. Previously known endpoints that have not seen traffic over a set period of time are categorized as zombie APIs. Endpoints from the OAS that are seeing live traffic are categorized as inventoried-discovered, indicating the platform has gathered runtime data on them in addition to what the specification declared.
Reviewing findings
Drilling into a domain opens its endpoints dashboard. The inventory here can be filtered by discovery state, and risk scores reflect the latest analysis. This dashboard gives you additional telemetry including a requests timeline, the most active APIs, top sensitive data, and response code distribution.
Each endpoint’s risk score is composed of multiple contributing factors. Expanding the score shows the individual factors and their contributions.
Acting on findings
The Action menu on an endpoint exposes two operations: Block/Unblock and Mark as Non-API. Block/Unblock triggers an enforcement push to the BIG-IP fronting the affected virtual server. Mark as Non-API removes an entry from the inventory when discovery has surfaced something that should not be tracked as an API (static asset paths or health-check endpoints that share a host with real APIs).
Managing the inventory
Once an endpoint has been classified, it can be moved between states. Discovered shadow endpoints that turn out to be legitimate get promoted into the managed inventory. Endpoints that are no longer in use can be removed. The current inventory can be exported as a Swagger file at any time, which makes it possible to feed an authoritative, runtime-verified specification back into your API documentation, gateway configuration, or downstream tooling.
Demo
The video below shows the workflow above running against a sample environment, including OAS upload, discovery surfacing a shadow API, a block push to BIG-IP, and inventory management.
Additional Resources
F5 API Security Article Series:
F5 API Security: Discovery and Protection
Beyond Rest: Protecting GraphQL
Deploy F5 ADSP API Discovery and Security:
F5 ADSP Automation GitHub Repo
F5 Distributed Cloud Documentation:
F5 Distributed Cloud Terraform Provider Documentation
F5 Distributed Cloud Services API Documentation