> For the complete documentation index, see [llms.txt](https://docs.uptiq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.uptiq.ai/console/agent-builder/deploy/authentication.md).

# 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 Integrate Agent panel; together they're what turn the agent from "configured in the builder" into "callable from production."

Reach this page from **Manage Agent → Access & Security** in the left navigation, where the Access Keys section holds the credentials described below.

### The keys table <a href="#the-keys-table" id="the-keys-table"></a>

The right pane is a table of credentials.

| Column     | What it holds                                                                                                    |
| ---------- | ---------------------------------------------------------------------------------------------------------------- |
| **Name**   | A friendly name for the key — for example `Default`, `Production Widget`, `Mobile API`.                          |
| **Key**    | The credential value, displayed masked as `********`. Select the copy icon beside it to copy the unmasked value. |
| **Type**   | The key's type. See [Key types](#key-types) below.                                                               |
| **Status** | `Active` is the live state. A key you revoke is no longer accepted.                                              |

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.

### Key types <a href="#key-types" id="key-types"></a>

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

* **Widget Key** — used by the embeddable widget produced from Integrate Agent → Embedded Chat. The widget includes the key in its calls to the platform; the key is scoped to allow the widget to run.
* **API key and secret** — used for server-to-server calls to the Agent API, as described on [Integrate Agent](/console/agent-builder/deploy/agent-integration.md). The key is sent as `x-api-key` and stays visible here; the secret is sent as `x-api-key-secret`.

{% hint style="warning" %}
**The API secret is shown once, when the pair is generated.** It is not retrievable afterwards — the table shows the key, not the secret. If you did not record it, rotate the pair and record the new secret. Keep both server-side; the widget key is the only one of these that may ship in browser code.
{% endhint %}

### Working with keys <a href="#working-with-keys" id="working-with-keys"></a>

#### Adding a key <a href="#adding-a-key" id="adding-a-key"></a>

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 <a href="#revealing-and-copying-a-key" id="revealing-and-copying-a-key"></a>

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 <a href="#rotating-or-revoking-a-key" id="rotating-or-revoking-a-key"></a>

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 <a href="#security-considerations" id="security-considerations"></a>

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.
* **Integrate Agent** — 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 <a href="#why-this-matters" id="why-this-matters"></a>

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; the cost of sharing one key across all of them is that revoking it takes every integration down at once.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.uptiq.ai/console/agent-builder/deploy/authentication.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.