Skip to main content
An allow from POST /v1/checks carries authorization.token. Pass it to the tool or model provider that runs the generation. The tool verifies it offline against the published keys, and generates only what the token covers. The token is a JWS in compact serialization, signed with ES256 (ECDSA on P-256 with SHA-256).

Claims

The full obligations, with their instructions and disclosure text, are on the check. The token lists only their types, so a tool can tell, for example, that a generation_check follows.

Example payload

The token from Ridgeline’s image check, run by Northlight for one end user:
exp is 2026-10-17T18:15:00Z, fifteen minutes after iat.

Verify a token

A tool verifies the token before it runs anything. Reject the request if any step fails.
1

Check the header

alg is ES256 and typ is tlp-auth+jwt. In live mode, reject a kid that starts with rfl-test-.
2

Check the signature

Find the key whose kid matches in the JWKS. Cache the JWKS for its Cache-Control max-age. When a token names an unknown kid, refetch it, at most once per max-age. Verify the ES256 signature over <header>.<payload>.
3

Check who it is for

iss is https://app.reflections.ai, and aud is the acct_ ID of the platform you serve. A token issued to another platform fails here.
4

Check the time

The current time is no later than exp plus 60 seconds of leeway, and no earlier than iat minus 60 seconds.
5

Check what it covers

tlp.ver has major version 1, tlp.decision is allow, tlp.execution.model is the model about to run, and every type in tlp.obligations is one your tool handles.
6

Count generations

Keep a count per jti in a store every instance shares, until 60 seconds after exp. Refuse a generation once the count reaches tlp.max_generations.
These steps do not need the license. A party that can read it, such as the licensee or a connected platform, can also confirm the signed terms: for each entry in tlp.licenses, read the revision it names with GET /v1/licenses/{license_id}/revisions/{revision_id} and compare that revision’s terms_digest with the entry’s.

Request digest

tlp.request_digest binds the token to the exact request the check decided. If the tool receives the inputs, it can recompute the digest and refuse a request that differs. The token does not show whether the check asked for reuse, and under a reuse window later requests differ by design, so compare digests only when the platform tells you the check had no reuse. The digest is sha256: and the lowercase hex SHA-256 of the tlp-json-1 canonical form of this object, shown here before canonicalization:
  • inputs are in the order sent. A text input keeps role and text. A media input is replaced by role, sha256 and media_type, whether it was sent as a file, a URL or a digest.
  • execution keeps only provider and model.
  • tlp-json-1: UTF-8 JSON, object keys sorted by Unicode code point, no insignificant whitespace, numbers in their shortest round-trip form, no duplicate keys.
See Binding the request for where each input comes from.

Agent builders

Pass the token with each tool call, and verify it in the tool.

Model providers

Verify tokens at your inference API.

Session token

The short-lived token for live sessions.

Tokens in the Standard

The normative token rules.