Hi @miqui @handrews -- thanks for the approval. Is there anything else needed to get this merged? Happy to address any feedback.

@razashariff - I have added this to the week TDC agenda. We should be able to merge it then.

No, x-agent-trust-required is not registered separately yet. Happy to register it as a follow-up PR if the group prefers it as a standalone entry.

@razashariff we talked about some more general auth planning ideas in the TDC (technical developer community) call today, which might impact this so we did not get to deciding on merging it. I might have some additional feedback here between now and next week based on that more general planning, and we should be able to get things merged then.

@razashariff I guess my first question here is why this is a new OpenAPI Object / Operation Object field instead of leveraging the Security Scheme Object and Security Requirement Object. How are you thinking about the relationship between these things?

Thanks Henry, appreciate the update. Happy to align with the broader auth direction -- let me know if any changes are needed and I'll update the PR. Looking forward to next week.

The core issue is that agent authentication introduces a concept that doesn't exist in the current Security Scheme model: graduated trust.

Today's securitySchemes answer a binary question -- is this caller authenticated? Agent auth answers a different question -- how much should I trust this caller, and what should I allow based on that trust level?

An agent with a valid OAuth2 token is authenticated. But that tells the API nothing about whether the agent has been verified, what its behaviour history looks like, whether it's been sanctioned, or what trust tier it belongs to. Trust levels (L0-L4) gate access per operation based on verified agent identity and reputation -- that's a layer above authentication.

The verification model is also distinct. Agent trust tokens use JWKS-based local verification with pre-signed credentials from a trust authority. No redirect flows, no token introspection, no authorization server round-trips. The API caches the issuer's public keys and verifies independently. This maps closer to certificate-based identity than to OAuth2 or OpenID flows.

There have been 30+ CVEs filed against MCP implementations in 2026 (CVE-2026-23744, CVE-2026-0756, CVE-2025-6514). The root cause in most cases is that APIs have no way to verify agent identity or enforce trust-based access. The OWASP MCP Security Cheat Sheet documents this gap.

I built this as an extension because it addresses a pattern that the current Security Scheme types weren't designed for. If the auth rework creates a path to express this within the core security model, I'd welcome that and will adapt accordingly.