You are three weeks into a new job on a platform team, and the first thing on your plate is an API security review. Someone forwards you Kong's engineering post on API security best practices for 2026 and says, start here. You have a meeting in an hour, and you need to know what to take from it and what to leave.
The post opens with numbers. 32% of organizations had an API security incident in the past year. 66% saw their API count grow by more than 50%. Both figures come from Salt's survey. It adds a 2026 global average breach cost of $4.99 million, up 12%. You notice what the APIs.io write-up notices: these are third-party survey figures cited by a gateway vendor, and a gateway is where the post ends up. You discount the framing accordingly.
The line that sticks is about consistency, not controls: "If 40 teams each build authentication policies their own way, you end up with 40 versions of authentication." You think about your own company and wince.
What survives the discount is specific advice. Start with an inventory, because shadow and zombie APIs are where attackers look first. Use mTLS for service-to-service calls. Cap JWT lifetimes, pin signing algorithms, and check issuer and audience. Put an ownership check on every endpoint that takes an object ID, because Broken Object Level Authorization tops the OWASP API Security Top 10. And alert when one consumer collects 403s across 20 or more object IDs in 10 minutes, which is a BOLA probe in progress. You copy that last one into your notes word for word.
Then the write-up does something you didn't expect. It turns the advice back on the company that gave it. If inventory comes first, what does Kong's own estate look like? On APIs.io, Kong carries 139 API pages, which makes it a fair test of its own first practice.
The controls in the post map to those pages. The Kong Plugins API attaches the JWT, Request Validator and Rate Limiting plugins the post names. The Kong JW Ts API, Kong API-keys API and Kong ACLs API cover authentication and authorization. The Kong MTLS-auth credentials API and Kong Certificates API cover the mTLS practice. The Kong Consumers API is the key a per-consumer rate limit hangs on, and the Kong Gateway page ties them together. So the advice is not abstract. Much of it is exposed as API surface you could read.
The scores are mixed in a way you can use. Kong scores 71.8 on the Kin Score, rated exemplar, led by access clarity at 84.2 and contract quality at 67.6. Contract governance is 45.5. That is Kong's second-weakest facet and well above most of the catalog, but it is the facet that measures exactly the drift the post warns about: 40 teams, 40 versions.
Agent Readiness is 46.9. Auth clarity, delegated identity, protected resource metadata and error semantics are lit. The unlit list is the interesting part: MCP server, well-known catalog and idempotency. The post closes by saying the same approach covers AI and MCP, and Kong sells a Kong MCP Registry. Yet an agent arriving at Kong's own estate still finds no MCP server and no machine-readable catalog of those 139 APIs.
You put your pen down. Nothing here says Kong is careless. The record says the practice is hard, even for a vendor that sells the tooling, and that a catalog is only useful if it can be read by something other than a person.
Walking into your meeting, you know what you are taking. The advice is good, and you will use it: inventory first, mTLS between services, tight JWT rules, an ownership check on every object ID, and that 403 alert. The statistics you will cite as survey figures, not as facts about your company. And you will count your own APIs before anyone buys anything, then ask whether that count lives somewhere a machine can read it.
Read the original: https://apis.io/2026/11/03/kong-says-inventory-every-api-first-its-catalog-record-shows-139/