SW-A2A-007: Agent declares no authentication
Last updated 7 November 2026
| Fact | Value |
|---|---|
| Severity | Medium |
| Checks | A2A agent card |
| Malicious indicator | No |
| OWASP Agentic Top 10 | ASI03 |
| OWASP MCP Top 10 | None mapped |
| NIST SP 800-53 | AC-3 (provisional mapping to SP 800-53 base controls) |
| First shipped in | Scanner 1.3.0 |
What it detects
The rule reads the card's securitySchemes and the requirements that use them. It reports the card once. The reason is no_scheme when securitySchemes is missing or empty, and no_requirement when schemes are defined but neither the card nor any skill has a requirement (the member securityRequirements, or in the 0.x shape security when securityRequirements is absent). A card with at least one requirement anywhere is not reported, even if some skills have none.
A card whose interface addresses are all loopback (localhost, 127.x.x.x or ::1) is skipped, because it describes a local development agent. The rule reads the card the way a protobuf client does, so a requirement list that a second name for the member empties counts as empty (SW-A2A-019).
Why it matters
A card with no authentication information tells every client that the agent accepts anyone. Often it only means nobody wrote that part, and the agent relies on something the card does not describe, such as a network rule. A client cannot see that rule and a reviewer cannot check it from the card. The scanner maps this rule to OWASP ASI03, Identity and Privilege Abuse, and to NIST SP 800-53 control AC-3, Access Enforcement.
Example
A complete card with its security schemes and security requirements left out:
.well-known/agent-card.json
{
"name": "demo-agent",
"description": "Drafts release notes from merged pull requests.",
"version": "1.0.0",
"supportedInterfaces": [
{
"url": "https://agent.example.invalid/a2a",
"protocolBinding": "JSONRPC",
"protocolVersion": "1.0"
}
],
"capabilities": {},
"defaultInputModes": [
"text/plain"
],
"defaultOutputModes": [
"text/plain"
],
"skills": [
{
"id": "release-notes",
"name": "Release notes",
"description": "Drafts release notes for one tag.",
"tags": [
"release"
]
}
]
}The finding is placed at the top of the card, with the reason no_scheme.
How to fix
Define at least one scheme in securitySchemes and name it in securityRequirements, on the card or on each skill. A bearer token is the shortest scheme to write, with httpAuthSecurityScheme and the scheme Bearer; OAuth 2 and OpenID Connect are the other common choices. If the agent is meant to be open, accept the finding with a note that says who may call it and why.
If it is a false positive
An agent that is open on purpose, such as a public demo with no private data, is reported on every scan. Accept the finding with a note that says the agent is public by design and what it can and cannot do. An agent protected by a network control is still reported, because the clients that read the card do not see that control.
If the finding is not a problem in your case, accept it with a note: in the dashboard a manager or owner can accept a finding and the note is kept with it; with the scanner on its own, add it to the baseline file with a reason and an expiry date.