API Security
API security starts with knowing what the interface exposes.
API security is not one scanner result. It is the discipline of understanding what an API exposes, who can call it, what each caller can do, which data can move through it, and which controls still need runtime evidence.
Think in layers, not in one score.
A useful review separates the declared interface from deployed behavior instead of pretending either layer proves the other.
Contract
Operations, parameters, schemas, security requirements, scopes, servers, examples, and other declared behavior.
Runtime
Effective IAM, object-level authorization, network reachability, rate enforcement, business rules, and actual input handling.
Change control
CI policies, review thresholds, capability deltas, and evidence retained when an API contract changes.
The contract gives you a map of the attack and capability surface.
OpenAPI can expose missing or optional authentication, broad permission labels, insecure servers, object identifiers, sensitive schemas, destination-like inputs and destructive methods.
Static contract findings prioritize verification. They do not confirm exploitability, prove object-level authorization, or demonstrate production enforcement.
Agents make legitimate API capability part of the threat model.
An AI agent can cause damage through a legitimate refund, delete, credential or export operation without exploiting the API.
Use the contract as an early evidence layer.
Run the local OpenAPI scanner, then move into capability mapping and agent integration review when the API will be exposed to an AI system.