# FPLai auth.md

This document tells AI agents and automated clients how (and whether) to
authenticate against `fplai.app`. It follows the self-contained `auth.md`
convention for services that have no agent-specific registration flow.

## Audience

This applies to any autonomous agent, crawler, or tool-calling assistant
reading `fplai.app` — including agents fetching pages as Markdown via
`Accept: text/markdown`, calling `GET/POST` endpoints under
`/api/v1/agent/*` and `/api/agent/*`, or using the `/mcp` (Model Context
Protocol) and `/a2a` (Agent2Agent) endpoints.

## Registration

**FPLai does not offer agent or API-key registration.** There is no
provisioning endpoint, no agent registration route, and no client-credentials or
API-key flow for agents. Accounts are created only by humans, through the
product itself:

- `https://fplai.app/register` — email + password, or "Continue with
  Google" (Google OAuth via Supabase Auth)

Do not attempt to register an account, request credentials, or probe any
auth/registration endpoint on behalf of an agent — there is nothing for an
agent to authenticate as.

## Supported authentication methods

- **For the public agent surface: none required.** `GET /api/v1/agent/*`,
  `GET /api/agent/*`, `POST /mcp`, `POST /a2a`, `/openapi.json`, `/llms.txt`,
  and every public page (including their `text/markdown` variants) are
  served without any credential, header, cookie, or token. Access is
  anonymous by design.
- **For account-linked features: human sign-in only.** Team analysis,
  saved plans, and other account-linked functionality are available only
  to a signed-in human inside the FPLai web app (`fplai.app`) or the iOS
  app, using the session that Supabase Auth issues after the human signs
  in. There is no bearer token, secret, or agent identity an automated
  client can obtain to act as a user; agents should not attempt to
  reuse, request, or fabricate one.

## Credential use

No credentials are issued to or expected from agents on any surface listed
above. If a request to a public agent endpoint receives a `401`/`403`, that
indicates a bug or a path outside the public surface, not a missing
credential agents should try to supply — do not invent an `Authorization`
header, cookie, or query-string token.

## agent_auth (WorkOS Agent Auth discovery)

The OAuth authorization server metadata at
`https://api.fplai.app/auth/v1/.well-known/oauth-authorization-server`
publishes an `agent_auth` block per the WorkOS Agent Auth convention:

```json
"agent_auth": {
  "skill": "https://fplai.app/auth.md",
  "identity_types_supported": ["anonymous"]
}
```

Only the `anonymous` identity type is declared — this document is the
`skill` reference for it. FPLai does not implement `identity_assertion` or
`service_auth`, and does not publish `identity_endpoint`, `claim_endpoint`,
or `events_endpoint` values, because there is no registration or claim
ceremony to perform: the public agent surface is unauthenticated by design
(see "Supported authentication methods" above), so there is nothing for an
agent to register or claim.

## Resource metadata

Authoritative machine-readable detail (resource identifier, scopes, and
where account-linked-feature auth is documented) is published per
RFC 9728 at:

- `https://fplai.app/.well-known/oauth-protected-resource`

## Further reading

- `https://fplai.app/.well-known/service-docs/agent-guide.md` — full agent
  guide (endpoints, Markdown negotiation, error recovery)
- `https://fplai.app/llms.txt` — long-form content index
- `https://fplai.app/openapi.json` — OpenAPI 3.1 description of the public
  agent endpoints