Actions: from your OpenAPI spec to enabled tools
Import the spec, review classifications, choose an auth scheme, enable the tools you want. Everything starts disabled.
Import
Give the dashboard your OpenAPI (3.x) or Swagger (2.0) spec by URL or upload. Every operation becomes a tool definition with a JSON Schema for its arguments, and every tool starts disabled. Operations the importer cannot classify with confidence are marked needs review and cannot be enabled until you classify them yourself.
Classification
Each tool is read, write or destructive:
read(GET, safe operations) runs when the model asks, within the limits on its grant.write(POST, PUT, PATCH; "create", "update", "reschedule"…) requires a confirmation card in the widget stating exactly what will change, field by field.destructive(DELETE; "cancel", "refund", "delete", anything moving money) is off for the whole tenant by default, needs the card too, and is audited with the full before/after payload. Switch it on per tenant once you have read the security page.
Override any classification on the tool's page; a write can also be made to require the card on a read.
Auth schemes
Every enabled tool needs an auth binding, how the broker attaches a credential to the call:
- Token exchange (preferred): your app exposes an endpoint the broker calls with the identified user's id and receives a short-lived, narrowly scoped token for that user. The token lives in the broker's memory for its lifetime and is never logged.
- Service credential with on-behalf-of: a credential you store in the dashboard,
envelope-encrypted under your tenant's key; the broker sends it plus an
X-On-Behalf-Ofheader with the user's id. Your API decides what that user may do. - Bearer per user (last resort): a long-lived per-user key. It works; it is the least safe option and the docs say so.
Test the binding from the dashboard: a read tool is called against your API and the result, filtered to the response allowlist, is shown.
Response allowlist
For each tool you choose which fields of the response the model may see. Everything else is stripped in the broker before the model reads the result. Internal margins, other users' data and free-text fields you do not want in a prompt never reach the model.
Limits
A grant can cap calls per session and per day; the broker also applies per-tenant and per-site rates and a circuit breaker per upstream host. Every refusal is one audit row with its code.