For the complete documentation index, see llms.txt. This page is also available as Markdown.

Authentication

Authentication is where you mint and manage the credentials clients use to reach the agent — the API keys, widget keys, and similar credentials that authorize calls from embedded widgets, API integrations, and headless backends. Each key has a type, a status, and a value that's stored masked. The keys generated here pair with the integration choices on the Export and integrate page; together they're what turn the agent from "configured in the builder" into "callable from production."

Manage Agent → Authentication keys table

Reach this page from Manage Agent → Authentication in the left navigation.

The keys table

The right pane is a table of credentials.

ColumnWhat it holds

Name

A friendly name for the key (for example, Default, Production Widget, Mobile API).

Key

The credential value, displayed masked as ********. Click the copy icon next to it to copy the unmasked value.

Type

The key's type — Widget Key was observed during capture; other types likely exist when adding a new key.

Status

The key's status — Active (green check) is the live state. Other statuses (revoked, expired) presumably exist.

A + Add Key button sits in the top-right of the section.

Each row has a overflow menu on the right with per-key actions.

Note — Depth gap The full set of key types available when clicking + Add Key was not enumerated during capture. Widget Key was the only type observed in the existing rows. The actions in the per-row menu (rotate, revoke, view) were also not exercised.

Key types

The type of key you mint depends on how the agent will be invoked.

  • Widget Key — used by the embeddable widget produced from Export and integrate → Embed Agent. The widget includes the key in its calls to the platform; the key is scoped to allow the widget to run.

  • Other types (likely API keys, headless keys) — gate API and headless integrations described on the Export and integrate page.

Working with keys

Adding a key

Click + Add Key in the top-right of the section. The platform opens an authoring form for the key — Name, Type, and any per-type configuration. Save to generate the key value and add it to the table.

Revealing and copying a key

Click the copy icon next to the masked key in the Key column. The platform places the unmasked value on your clipboard. The display in the UI stays masked.

Rotating or revoking a key

Use the menu on the row. Rotating generates a new value and invalidates the old one; revoking marks the key inactive.

Important Treat the unmasked key as a secret. Anywhere the key is pasted — application code, environment variables, configuration files — should follow the same handling rules as any other credential. Do not paste it into Instructions or commit it to a public repository.

Security considerations

Three pages together govern how the agent is reached from outside:

  • This page — what credentials are valid.

  • Whitelisted Domains — what web domains the widget is allowed to run on.

  • Export and integrate — what kinds of integration are exposed.

A tight Authentication configuration with a tight Whitelisted Domains list together produce an agent that's hard to invoke from anywhere you didn't intend. Loosening either of them — generating long-lived keys, leaving the domain list empty — widens the agent's exposure correspondingly.

Why this matters

Auth keys are how an integration introduces itself to the agent at runtime. A leaked key — pasted into a public repo, exposed in a client-side bundle, included in a screenshot — is effectively a granted right to invoke the agent on your behalf. The Authentication page is the smallest surface to lock down well: name keys descriptively so you know what to rotate when something's wrong, rotate proactively rather than reactively, and don't reuse a single Default key across multiple integrations if you can avoid it. The cost of giving each integration its own key is one row in this table; t

Last updated