API Auth Transparency
stableCategory: ai-signals · Methodology v4.5
How clearly your API exposes its authentication method to an agent.
Signal Source
- Source
prefetched OpenAPI spec (components.securitySchemes) + homepage HTML auth hints- Kind
- http_response
Score Bands
| Verdict | Condition |
|---|---|
| Pass | OpenAPI components.securitySchemes are defined, OR a strong auth hint appears in the HTML — an explicit scheme such as api-key/x-api-key, Authorization: Bearer, OAuth2, client id/secret, securitySchemes, or Basic auth |
| Partial | Only generic authentication hints are present (e.g. 'authentication', 'authorize', 'access token', 'api docs', 'rest api') with no explicit scheme named |
| Fail | No security schemes in the spec and no public authentication hints in the HTML |
Description
API Auth Transparency checks whether your API declares its authentication method in a way an AI agent can read. friendly4AI passes the parameter when your OpenAPI spec defines components.securitySchemes or your homepage HTML names an explicit scheme (such as api-key, Authorization: Bearer, or OAuth2). It fails when neither source carries any auth signal.
What does this parameter measure?
How clearly your API exposes its authentication method to an agent. friendly4AI reads two sources:
- The prefetched OpenAPI spec — it reads
components.securitySchemesfor named schemes. - The homepage HTML — it scans for strong auth hints (
api-key,x-api-key,Authorization: Bearer,bearer token,oauth2,client id,client secret,securitySchemes,Basic auth) and weaker generic hints (authentication,authorize,access token,api docs,rest api).
A named security scheme in the spec, or any strong hint in the HTML, counts as explicit transparency.
Why does it matter for AI-readiness?
An agent can't call a protected endpoint unless it knows how to authenticate. Declare securitySchemes in your spec — an OAuth2 flow, an API key header, bearer tokens — and explain in your docs how to obtain and use credentials, and an AI tool can finish the auth handshake on the user's behalf. Leave the auth story vague or absent and automation stops cold: the agent sees the endpoint but has no way in. Machine-readable auth is what separates a documented API from a usable one.
How is it scored?
This is a gradient AI-Specific Signals parameter, scored in three tiers:
- Pass (100): the spec defines any
securitySchemes, or the HTML carries an explicit scheme hint. - Partial (50): only generic authentication language appears, with no named scheme.
- Fail (0): neither the spec nor the HTML reveals any auth information.
Scoring is API-conditional. The weighted contribution counts only when an API is detected on the site (via api-discoverability). Without one, the effective weight drops to zero and the parameter is excluded from the score, so sites with no API aren't penalized for undeclared auth.
How do you fix common issues?
- Declare your authentication in the OpenAPI spec under
components.securitySchemes— for exampleoauth2,apiKey, orhttp bearer. - Name the scheme outright in your developer docs (
Authorization: Bearer,X-API-Key, or an OAuth2 flow) instead of only saying "authentication required." - Show how to obtain credentials, authenticate a request, and refresh tokens, with a complete example.
- Mention the auth scheme on a getting-started page so the strong hints surface in the HTML.
- Re-scan once auth is documented to confirm an explicit scheme is detected.
Version History
- Introduced
- v1
- Last changed
- v4.5
Key takeaways
- Signal: prefetched OpenAPI spec (components.securitySchemes) + homepage HTML auth hints
- Category: AI-Specific Signals
- Passes when: OpenAPI components.securitySchemes are defined, OR a strong auth hint appears…