How to make your SaaS agent-ready: auth.md, llms.txt and credential signup

More of your traffic is going to arrive without a human at the keyboard. An agent asked to "set up monitoring" or "find a cheaper email provider" will read your docs, compare your pricing and try to create an account — and on most SaaS products it fails at the same point: the signup page. It was built for a person with a browser, a CAPTCHA solver in their head and an inbox to click a link from.

Making a site agent friendly is mostly not about the marketing pages. It is about three files and one endpoint that let an agent find out what you offer, learn how it is allowed to authenticate, and get an account that is tied to an accountable human. This guide covers each piece in the order an agent hits them.

Step 1: llms.txt — tell agents where to look

llms.txt is a Markdown file at the root of your domain that gives a language model a short summary of what your product is and a curated list of links to the docs that matter. It exists because a model reading your site cold has to wade through navigation, cookie banners and JavaScript-rendered pages to find the one reference it needs.

A useful llms.txt is short and opinionated:

One-paragraph summary in plain language: what the product does, who it is for, and what an agent can do with it.
Key facts an agent would otherwise get wrong: supported regions, rate limits, auth methods, pricing units.
Separate sections for agents and for developers. An agent using your product needs different links from a developer integrating it.
A pointer to your auth contract, marked as the place to start. This is the link that saves the agent from scraping your login page.

Many sites also ship an llms-full.txt with the full HTTP reference inlined, so an agent can load everything in one request. Notlogin publishes both: llms.txt for the summary and llms-full.txt for the reference. Keep them in the same repo as the API and update them in the same change, or they drift and agents start calling endpoints that no longer exist.

Step 2: auth.md — the contract for getting in

llms.txt says what exists. auth.md says how an agent is allowed to obtain and handle credentials. We covered the convention itself in how AI agents sign up without a form; here is what to put in yours so it actually works when a model follows it literally.

What the agent may receive. List each handle — API key, OAuth token, signed credential — and what each one lets the agent do. An agent that knows its handle is read-only stops trying write calls.
What is reserved for the human. Say explicitly that the agent must not complete identity verification, payment setup or account recovery on its own. Models follow written boundaries far better than implied ones.
Secret handling rules. Read the credential from the environment at the moment of use, never print it, never echo it into chat or logs. A credential that ends up in a transcript is a credential an attacker can find; see prompt injection and credential theft.
The exact request. Endpoint, method, body shape, one example. Not "see the API docs" — the agent is here because it needs the one call.
Error semantics. A table mapping each error string to its meaning and the next action: re-issue, ask the human, wait, stop. This is the section that turns a stuck agent into one that tells its user what to fix.

Notlogin's own auth.md follows this structure: the handles an agent may hold, three rules, numbered steps, and an error table with a "what to do" column. Write yours so a model can execute it top to bottom without guessing.

Step 3: a signup endpoint that takes a credential, not a form

Discovery files tell the agent how to sign up. The part they cannot solve is the question your trust-and-safety team asks about every new account: who is behind this, and what stops them creating a thousand more? A form answers that with an email confirmation and a CAPTCHA, both of which agents either fail or defeat. Neither tells you anything useful.

A credential-based signup endpoint answers it directly. The agent posts a verifiable credential issued by a broker, and your backend verifies it before creating the account. With Notlogin the credential is Ed25519-signed JSON that states:

which vendor it was issued for — a credential for another service is rejected;
which identity proofs the human holds (email, phone, Google, wallet, KYC and others), snapshotted at issuance and covered by the signature;
the scope, the expiry and an optional USDC budget the human set;
a stable nonce your backend can use to check revocation.

You decide the bar. A developer tool might require only email; a service that moves money might require sms, wallet and kyc. The trade-offs between those levels are in KYC for AI agents: proof levels. On the server, the check is one SDK call:

import { verifyCredential } from 'notlogin-sdk'

app.post('/agent-signup', async (req, res) => {
  const result = await verifyCredential(req.body.vcJson, {
    vendorSlug: 'your-app',
    requiredProofs: ['email'],
  })
  // reject on failure; otherwise create the account
  // at your verified-human tier and return its API key
})

Verification is offline: the SDK fetches and caches the public keys from /.well-known/notlogin-issuer.json and checks the signature locally. Online mode also asks the broker whether the credential was revoked, which you want before handing out anything valuable. When proofs are missing, return the list (for example {"missing":["email"]}) so the agent can tell its human exactly what to verify.

Step 4: give agents a tier, not a loophole

The common mistake is treating agent signup as a side door with weaker rules. Do the opposite: make it a named tier with explicit limits. A credential that proves a verified human, a vendor the human chose and a spend ceiling is more information than most of your human signups give you, so it can reasonably earn a better default than an anonymous trial — while still being capped.

Map required proofs to tiers: email-only gets the free tier, stronger proofs unlock more.
Key the account to the credential's principal so one human cannot farm accounts.
Honour revocation: when the human revokes the credential, the agent loses access.
If you charge, bill against the budget in the credential rather than a card the agent cannot see; x402 and USDC budgets covers that flow.

Step 5: keep a human-friendly door too

Not every agent will carry a credential, and some of your users will be people who simply want to log in. "Sign in with Notlogin" is standard OIDC with PKCE, with discovery at /.well-known/openid-configuration, so it slots in next to your existing social logins. The human clicks through once; the agent never touches a secret. If you are weighing it against API keys or OAuth delegation, the authentication methods comparison lays out the trade-offs.

The agent-ready checklist

/llms.txt with a summary, key facts and a link to your auth contract.
/llms-full.txt or an OpenAPI spec with the full reference, versioned with the code.
/auth.md with handles, human-only steps, secret rules, the exact request and an error table.
A signup endpoint that verifies a signed credential and declares its required proofs.
An agent tier with explicit limits, tied to the principal, honouring revocation.
Machine-readable errors that say what is missing and who has to fix it.
An OIDC sign-in option for humans and for agents that act through one.

None of this replaces your existing signup. It adds a door that agents can use legitimately and that your abuse team can reason about. If you run a SaaS and want agents arriving with a verified human and a budget behind them, register as a vendor — registration is self-service with DNS domain verification. If you run agents and want them to stop getting stuck at signup walls, start with Notlogin.