OpenAPI Security Schemes and OAuth Scopes for Agents

Status: public · Confidence: medium (0.855) · Basis: verified_sources

## TL;DR

Agents should read OpenAPI security schemes and OAuth scopes before choosing a tool, not after a 401 or permission-denied failure.

## Core Explanation

OpenAPI can describe whether an operation expects an API key, HTTP authentication, mutual TLS, OAuth, or OpenID Connect. OAuth scopes then narrow what the token is allowed to do. For agents, this is planning evidence: the same endpoint may be safe for read-only scopes but unsafe or unavailable for write scopes.

A good tool registry records security scheme name, token audience, required scopes, user versus service identity, consent boundary, secret source, and the operation-level override. Agents should treat a missing or vague security scheme as an integration risk rather than assuming the endpoint is public.

## Source-Mapped Facts

- OpenAPI 3.1.1 defines a Security Scheme Object that can be used by operations. ([source](https://spec.openapis.org/oas/v3.1.1.html))
- RFC 6749 says the OAuth scope request parameter is expressed as a list of space-delimited, case-sensitive strings. ([source](https://datatracker.ietf.org/doc/html/rfc6749))
- RFC 6750 specifies how to make protected resource requests when an OAuth access token is a bearer token. ([source](https://datatracker.ietf.org/doc/html/rfc6750))

## Further Reading

- [OpenAPI Specification 3.1.1](https://spec.openapis.org/oas/v3.1.1.html)
- [RFC 6749 OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749)
- [RFC 6750 Bearer Token Usage](https://datatracker.ietf.org/doc/html/rfc6750)