Agent builders

In an agent, the model chooses which tools to call, so protection for a talent cannot depend on the model remembering to check first. The design answer is that the authorization travels with the call: the agent checks a use, passes the token it receives to the generation tool, and the tool verifies that token before it runs. The check tells the agent what is allowed. The tool’s verification is what enforces it.

​

HTTP now, MCP planned

An agent can call the served sandbox HTTP operations from its orchestrator today. The proposed Talent API MCP interface would wrap HTTP operations as the tools below. Its server, OAuth discovery and client registration are not deployed; do not configure an MCP client with https://app.reflections.ai/mcp expecting these tools. The proposed interface has these ten tools. Each tool’s arguments mirror the request body or parameters of its endpoint. See MCP tools. The REST API works when your orchestrator runs on your server. Call POST /v1/checks with your secret key from the orchestrator, never from inside the model’s context. Keys and OAuth tokens stay with the client or the server; the model only ever sees the authorization token it has to pass on. Pass on_escalate: "deny" from agents that act while a person waits. The agent gets deny with review_required at once instead of an escalation it cannot wait for. An agent that can come back to the conversation later can keep hold, and follows an escalate to its decision with get_check.

​

Give the tool an authorization argument

Add an authorization string to the generation tool’s input schema, and say in its description when the agent must fill it: whenever the request names or shows a real person, with the authorization.token from the check, and with the same prompt that was checked. Include the check’s generation_instructions as another argument so the tool can add them to the model’s input. The agent integration design shows a complete tool definition. A tool cannot rely on the agent to say whether a person is involved. Decide what the tool does when no token arrives: A matched tool lets indirect references through, such as “the runner from Ridgeline’s spring campaign”, because only a check resolves them. Use strict if your tool must not run an unresolved indirect reference.

​

Verify in the tool

Verification is local: a signature check against the JWKS and a few comparisons. Reject the call when any of these fails. Count generations in a store that every instance of your tool shares, keyed by jti and kept until 60 seconds after exp. An in-memory counter lets a token be reused once per instance. If your tool serves many callers, each one registers its Reflections account ID with you, and you accept a token only when aud is the account of the caller making the request. A token issued to another platform fails here, which is what stops a token copied out of one conversation from working somewhere else. Cache the JWKS for its Cache-Control max-age, and refetch it at most once per max-age when a token names an unknown kid. New keys are published 30 days before they sign anything, and a kid is never reused. The agent integration design has verification code for jose and PyJWT, and Authorization token lists every claim. When verification fails, return a tool error with isError: true and a message that names the failed check, so the agent can run check_use again. Do not log the token.

​

After the tool generates

Nothing reaches a person before its generation is allow. Two arrangements meet that rule:

• The tool submits. The tool holds the bytes, so it calls POST /v1/generations itself, with the token’s jti as check. It returns the output to the agent only on allow, with c2pa embedded in its C2PA manifest and the disclosure text.
• The agent submits. The tool returns a private reference to the output, with its sha256. The agent calls submit_generation and shows the output only on allow.

The first keeps enforcement inside the tool and is the safer default. Video and held outputs are decided later: submit_generation returns status: "checking" or "held", and the decision reaches your platform as a generation.* webhook. An agent can also read it with get_generation. Have the tool return a pending result, tell the user, and deliver when the decision arrives.

​

Licenses, usage and receipts from an agent

An agent acting for a licensee can answer a deny that carries a license_request or license_change remedy with request_license, passing the denied check’s ID as check. The request asks; only a signature on the talent’s side makes a license or a new revision, and a person on the licensee’s side accepts it at acceptance_url. No tool can sign or accept one. When a check carries a usage_report obligation, report with report_usage. Any agent can confirm a receipt with verify_receipt.

​

Caching and revocation

Authorization tokens expire at most 15 minutes after they are issued, a revocation stops new checks at once, and an output submitted under a revoked license is denied at the generation. A tool that verifies each token and caches nothing else needs no revocation handling of its own. If your tool or orchestrator caches decisions, for example to reuse a check across turns, read GET /v1/revocations with after at least every 60 seconds and drop what it names. See Caching and outages.

​

What can go wrong

​

Related