Skip to content

Document handling of x-agent-trust OpenAPI extension (agent authentication) #14854

@razashariff

Description

@razashariff

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:

  1. 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?

  2. Is there existing guidance on how users should implement agent signature verification via an existing plugin (custom Lua, pre-function, request-transformer, or similar)?

  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions