Context
The OpenAPI Initiative recently merged a new vendor extension into the official Extensions Registry:
https://spec.openapis.org/registry/extension/x-agent-trust.html
x-agent-trust is a registered extension for APIs that serve AI agents. It lives inside securitySchemes and describes agent-signed authentication via an Agent-Signature header:
components:
securitySchemes:
AgentTrust:
type: apiKey
name: Agent-Signature
in: header
x-agent-trust:
algorithm: ECDSA-P256-SHA256
trust-levels: [L0-UNTRUSTED, L1-RESTRICTED, L2-STANDARD, L3-ELEVATED, L4-FULL]
minimum-trust-level: L2-STANDARD
jwks-uri: https://example.com/.well-known/agent-trust-keys
paths:
/v1/charges:
post:
x-agent-trust-required: L3-ELEVATED
Question
As AI agents start calling APIs at production scale, Kong is a natural enforcement point for agent authentication. I wanted to raise a few questions so users who hit this know what to expect:
-
When Kong ingests an OpenAPI spec (via decK, Kong Manager, or deployless config), how does it currently handle vendor extensions like x-agent-trust? Is the extension preserved, ignored, or surfaced anywhere?
-
Is there existing guidance on how users should implement agent signature verification via an existing plugin (custom Lua, pre-function, request-transformer, or similar)?
-
Would the Kong team be open to a community plugin that reads x-agent-trust metadata from an imported spec and enforces the trust level at the route level? I would be happy to prototype one against the Kong Plugin Development Kit.
Why
Kong sits at a position in the stack where edge enforcement of agent trust levels makes a lot of sense, and the extension being officially registered means it is now a discoverable standard rather than a vendor-specific proposal. This is a light-touch issue to understand the right path forward rather than a feature demand.
Thanks for any pointers.
Context
The OpenAPI Initiative recently merged a new vendor extension into the official Extensions Registry:
https://spec.openapis.org/registry/extension/x-agent-trust.html
x-agent-trustis a registered extension for APIs that serve AI agents. It lives insidesecuritySchemesand describes agent-signed authentication via anAgent-Signatureheader:Question
As AI agents start calling APIs at production scale, Kong is a natural enforcement point for agent authentication. I wanted to raise a few questions so users who hit this know what to expect:
When Kong ingests an OpenAPI spec (via decK, Kong Manager, or deployless config), how does it currently handle vendor extensions like
x-agent-trust? Is the extension preserved, ignored, or surfaced anywhere?Is there existing guidance on how users should implement agent signature verification via an existing plugin (custom Lua,
pre-function,request-transformer, or similar)?Would the Kong team be open to a community plugin that reads
x-agent-trustmetadata from an imported spec and enforces the trust level at the route level? I would be happy to prototype one against the Kong Plugin Development Kit.Why
Kong sits at a position in the stack where edge enforcement of agent trust levels makes a lot of sense, and the extension being officially registered means it is now a discoverable standard rather than a vendor-specific proposal. This is a light-touch issue to understand the right path forward rather than a feature demand.
Thanks for any pointers.