Kong’s Konnect Platform API is the cleanest target in the field for automated agent onboarding. 1,242 operations across the Gateway Admin API and the Konnect Platform API, 13 native MCP operations, and a first-class audit/streaming surface in the Event Gateway. Every leg of the agent-onboarding Naftiko Capability composes from operations Kong already publishes.
What the agent does
An agent shows up at a Kong-backed provider with a Web Bot Auth signature (RFC 9421), reads /.well-known/api-catalog, finds the x-onboarding extension pointing at /onboard, computes the SHA-256 of the published consent terms, and posts a single signed request. The capability does the rest.
What the capability composes
Five Kong operations, one round trip:
POST /{workspace}/consumers
→ create the agent's identity record
POST /{workspace}/consumer_groups
→ create the scoping container for this agent's credentials
POST /{workspace}/consumer_groups/{cgId}/consumers
→ bind the consumer to the group
POST /{workspace}/consumers/{consumerId}/key-auth
→ mint the scoped credential the agent will use
POST /v1/event-gateways/{gw}/topics/audit-events/produce
→ record the Web Bot Auth signature + consent hash on the audit trail
Scope is enforced via Kong plugins attached to the consumer group — ACL, rate-limiting, and request-validation policies inherit to every consumer in the group. The agent’s credential carries no policy of its own; the group does. That’s the abstraction that makes Kong such a good fit for this flow.
Revocation is one DELETE on the key-auth endpoint. Quota changes are policy edits on the consumer group, propagated to every agent in it. The provider’s policy file declares the agent tiers (research-low, research-high, partner-trusted) and the capability maps each tier to a consumer group at deploy time.
What’s distinctive about Kong
The MCP control plane is first-class. Kong’s Konnect API publishes thirteen MCP-specific operations under /v1/mcp-cp/{controlPlaneId}/mcp-servers/... and /v1/mcp-servers/.... That includes list-mcp-server-configs, create-mcp-server-config, get-mcp-server-code, and get-mcp-server-kong-entities — meaning Kong both manages MCP servers as configuration and exposes the Kong objects each MCP server is built from. The agent-onboarding capability surfaces these to the agent via /.well-known/mcp without any custom orchestration on top.
The Event Gateway is the audit surface. No side-channel, no Cloud Audit Logs, no CloudTrail. Kong publishes 104 audit/event/log-flavored operations on a single API. The Web Bot Auth signature from the onboarding request flows directly into a Kong topic the provider can subscribe to.
The whole adapter is one API surface. Every operation above lives at *.api.konghq.com. The implementation effort estimate is ~4.5 days to ship a working Kong adapter end-to-end (details in the working evaluation) versus 6.5+ days for any of the multi-origin gateways.
What the provider configures
One YAML file:
adapter:
gateway: kong-konnect
endpoint: https://us.api.konghq.com
workspace: agent-tenants
trust:
signatures:
web-bot-auth-2025:
issuers: [anthropic.com, openai.com]
scopes:
automated: [read:public, read:catalog]
approval: [read:private, write:*]
defaults:
consumer_group: research-low
rate_limit: { rpm: 60, burst: 100 }
audit:
topic: audit-events
The capability picks up the policy, the gateway honors the policy, the agent gets a credential. Provider doesn’t touch Kong’s UI for a registration.
Why Kong adapter ships first
The recommended build order across all evaluated gateways puts Kong first for three reasons: the operation surface is comprehensive, the composition is single-API, and the MCP discovery leg works against ops the gateway already ships. The Kong adapter exercises every part of the Naftiko Capability contract, so the v0.1 implementation is also the cleanest reference for what every subsequent adapter needs to do.
If you run a Kong Konnect tenant and the “agents need credentials and we can’t onboard them fast enough” problem is real, the capability is one engagement away from running in front of your tenant. The first design partner gets to shape the policy surface, the trust model, and the credential lifecycle to fit their needs while the standardized package is still being defined.
The real artifact
A schema-validated Naftiko Capability for Kong agent onboarding is committed at api-evangelist/kong/capabilities/kong-agent-onboarding.yaml. 473 lines of valid naftiko: 1.0.0-alpha2 covering all five Kong Admin operations above, two orchestration flows (onboard-agent and revoke-agent), three exposed surfaces (REST POST /v1/agents/onboard, MCP agent-register tool, agent skill at /skills/onboard-agent.md), and five governance policies. What’s distinctive about the Kong artifact: it’s the single-surface reference that every other adapter in the series benchmarks against — every operation composed in the orchestration lives on *.api.konghq.com, no side-channel origins, no IAM short-circuit, no per-call consent. The cleanest first-design-partner build target.
The artifact is design-validated but not yet executed against a real Kong Konnect tenant. That’s the first design-partner engagement.
See the master writeup on API Evangelist for the broader pattern.