How do I require a verified agent credential before an API returns paid or sensitive data?

What should I check, step by step?

1. Classify responses: public (OK anonymously), authenticated-human (session or user OAuth), and agent-only (paid feeds, bulk export, PII, holds, prices under contract). Only the last class needs an agent credential gate.

2. Require a credential on agent-only routes: Authorization header or signed proof carrying a crd_... (or your issuer's equivalent) with audience = your API and scope that names the route or data class.
3. Verify on every request: signature or proof-of-possession, expiry, revocation list, optional config_hash binding, and scope ⊇ requested operation. Cache the public revocation feed with a short TTL; fail closed if verification is unavailable for sensitive routes.
4. Prefer sender-constrained credentials: OAuth 2.0 DPoP (RFC 9449) binds the access token to a key the client proves per request; a stolen token without the private key fails. Short TTL (minutes) plus refresh at your broker beats a long-lived API key in the agent's env.
5. For high-value answers, optionally require a Verified AI Run receipt id that proves which model/config produced the request context you are willing to honour, then still check the agent credential that presents it.
6. Deny anonymously with 401 or 403 and a machine-readable error (code, how to register, link to your agent docs). Do not return partial paid fields, different SKU existence signals, or slower timing that lets agents probe what sits behind the gate.
7. Keep human HTML pages free and indexable when that is your product: the gate belongs on the API that returns paid JSON, not on the marketing URL search engines need. Distinct URLs or Accept-driven negotiated resources beat cloaking the same URL.
8. Log credential id, scope, decision and response class for audit; revoke on abuse without rotating every human password.

What the gate is checking

Identity: who is accountable for this agent (owner verification tier), and that the credential is still live. Rightshold's free verify answers validity, revocation and optional scope in one call.

• Configuration binding (optional but strong): a config hash in the credential that must match what the agent claims to be running, so a silent prompt or tool swap breaks access.
• Authorization: even a valid credential must include the scope for this paid route. A read-only marketplace browser credential must not unlock settlement exports.

Short-lived proof beats a long-lived key in the prompt

RFC 9449 DPoP has the client send a fresh signed proof JWT with method, URL, time and token hash on each call; the resource server checks the binding. Agents copy context into logs and tools, so bearer API keys leak easily; a proof-of-possession token limits replay.

• Mint at a broker the model cannot rewrite: the agent proposes the operation, your broker exchanges for a minutes-long token bound to that audience and scope, then attaches the proof. The model never sees the long-lived secret.
• Web Bot Auth (HTTP Message Signatures with a published key directory) can identify which operator signed the HTTP request to your site; pair it with an application-level credential when the response itself is paid data, because signature ≠ entitlement.

Denying anonymously without teaching scrapers your catalog

Use one error shape for "no credential" and "credential lacks scope" on paid routes if distinguishing them would reveal whether a SKU or person exists. Put the detailed reason in server-only logs.

• Do not rely on robots.txt Disallow as the gate for /api/paid/*. Non-compliant agents ignore it, and compliant ones still need a real authn/authz check when you want them to pay or identify themselves.
• If you also sell the same facts on a human page, keep that page's public HTML honest for search engines and put the bulk or machine-priced feed on a clearly authenticated API. That is negotiation and product packaging, not cloaking.