securitySchemes

securitySchemes is the Agent Card field that maps a name of the agent’s choosing to a SecurityScheme object, declaring each way a client can authenticate. The companion field securityRequirements says which of those schemes, and which scopes, a request must satisfy.

Scheme types. SecurityScheme is a oneof modelled on the OpenAPI 3.2 Security Scheme Object, so the JSON key names the type:

JSON key	Declares
apiKeySecurityScheme	An API key, with its location (header, query or cookie) and parameter name
httpAuthSecurityScheme	An HTTP authentication scheme such as Bearer or Basic, with an optional bearerFormat hint
oauth2SecurityScheme	OAuth 2.0 flows (authorization code, client credentials, device code) and an optional metadata URL
openIdConnectSecurityScheme	An openIdConnectUrl pointing to the provider’s discovery document
mtlsSecurityScheme	Mutual TLS with client certificates

Requirements. securityRequirements is a list. Each entry maps scheme names to the scopes they need, wrapped in a list field. Following the OpenAPI Security Requirement Object, which the v0.3 schema described as an OR of ANDs, any one entry is enough and every scheme inside an entry applies. Skills can carry their own securityRequirements. Illustrative: a bearer token, or an API key presented over mutual TLS.

{
  "securitySchemes": {
    "bearer": {"httpAuthSecurityScheme": {"scheme": "Bearer", "bearerFormat": "JWT"}},
    "partnerKey": {"apiKeySecurityScheme": {"location": "header", "name": "X-Partner-Key"}},
    "mtls": {"mtlsSecurityScheme": {"description": "Client certificate issued by Example Co"}}
  },
  "securityRequirements": [
    {"schemes": {"bearer": {}}},
    {"schemes": {"partnerKey": {}, "mtls": {}}}
  ]
}

How clients use it. Section 7.3 describes three steps: read the schemes from the card, obtain credentials out of band, and send them with every request in the binding’s headers or metadata. The server must authenticate every request. The enterprise guide notes that identity is established at the HTTP or transport layer, and A2A payloads do not carry it. The card itself should not contain credentials (section 14.3).

Version notes. The specification text still refers to AgentCard.security in places, while the proto field is securityRequirements; follow the proto. In v0.3 each scheme used a type discriminator, such as "type": "http", and requirements were plain maps from scheme name to scope list.

Neighbouring terms. OAuth 2.0 and OpenID Connect are the most common schemes. An extended Agent Card is fetched with one of these schemes.