# Gateway Tokens and Chat Access Tokens

An [Agent Channel](/products/ai-studio/agent-channels/) uses two credentials, and the split exists because one of them can safely reach a browser and the other cannot. A **Gateway Token** is your server's long-lived key to a channel; a **Chat Access Token** is a short-lived credential for exactly one conversation. This page explains what each one permits, how long it lasts, and what happens when you rotate or revoke it.

Read it before you decide where in your architecture each credential lives — that decision is difficult to reverse once an application is deployed, and it is the main thing that determines what a stolen credential is worth.

## The Two Credentials

| Property  | Gateway Token  | Chat Access Token  |
|  --- | --- | --- |
| **Prefix** | `tasgwt_` | `tascat_` |
| **Held by** | Your server, never a browser or a mobile app | Your server, or your client if you allow it |
| **Scope** | One SDK App — which means one shared work folder and one executor, many chats | One chat. It permits nothing else |
| **Issued by** | The executor, from the channel's page in Treasure AI Studio | The Agent Gateway, automatically, when your server creates a chat |
| **Lifetime** | Until it expires or is revoked. The expiry is chosen at issue; **No expiration** is allowed | 24 hours idle, extended by use, up to an absolute ceiling of 30 days |
| **What it can do** | Create chats, reissue and revoke Chat Access Tokens, read a chat's status, archive a chat | Send prompts, stop a turn, read the conversation |


The channel fixes the folder and the executor, so the Gateway Token itself carries no permissions. That is why issuing a second one grants nothing new and why rotation is safe.

## Issuing a Gateway Token

The channel's first token is issued by the creation wizard. Later ones come from the channel's detail page: open **Settings → Agent Channels**, open the channel, and select **Issue token** in the **Tokens** section. The channel's executor and any manager of its folder can issue one.

You choose the expiry at that moment and cannot change it afterward:

- **7, 30, or 90 days** — 90 is the default, and a bounded lifetime is the better habit: a token you forget to rotate stops working instead of staying valid indefinitely.
- **A custom date** — resolved to the end of that day, 23:59:59, in your personal time zone. It must be tomorrow or later in that zone.
- **No expiration** — valid until revoked. Reasonable for a server integration you monitor, provided you have a rotation practice that does not depend on an expiry to force it.


The zone is the **Timezone** on your Settings page, not your computer's — so a token dated "through the 21st" means the end of the 21st as you have chosen to read dates, and the field names the zone it used. The expiry is stored as an exact instant, so it does not shift for colleagues in other zones, and the token list shows each expiry in your own zone under **Expires**.

The secret is shown once, in a dialog you must acknowledge with **I have stored the values** before it closes. Afterward the channel shows only a hint — the last few characters — which is enough to tell rows apart and to name one in a support conversation, and nothing more. Treasure AI Studio stores only a digest, so a lost token cannot be recovered by anyone, including support.

Each token row also shows **Last used**, updated coarsely rather than on every request. Use it to find tokens nothing is calling any more before you revoke them.

## Rotating a Gateway Token

A channel can hold several tokens at once, and that is what keeps rotation uneventful: every token under a channel has the same scope, so the new one behaves exactly like the old one.

1. Issue a new token on the channel's detail page and store it.
2. Deploy your server with the new token.
3. Confirm the new token's **Last used** has moved and the old one's has stopped.
4. Revoke the old token.


Tokens section after a rotation: a Revoked row and an Active row, each showing its hint, issue date and issuer, expiry, and Last used, with a revoke icon only on the active row
Do not revoke before deploying. There is no grace period on a revoked token, and no way to undo the revocation.

Rotation is also how you change an expiry, since the expiry on an existing token is fixed. To move a channel from **No expiration** to a bounded one, issue a dated token, switch over, and revoke the undated one.

## Revoking a Token

Revoking is immediate and permanent. It takes effect within about a minute everywhere, because the gateway caches a successful credential check briefly rather than asking on every request.

Revoking a Gateway Token also stops **every Chat Access Token issued through it**. Conversations that are open at that moment lose their connection. A turn the agent was already running is not cancelled by the revocation, so whatever it was doing finishes on the server; what stops is the client's ability to see it or send anything more.

Several other actions stop credentials without revoking them, which matters when you need the arrangement back:

| Action  | Effect on Credentials  |
|  --- | --- |
| **Revoke a Gateway Token** | That token and every Chat Access Token issued through it stop. Permanent. Other tokens on the channel are unaffected |
| **Disable the channel** | Every token under the channel stops authenticating. Nothing is revoked — enabling the channel restores all of them |
| **Resign as executor** | The channel is disabled in the same action, so all of its tokens stop. Nothing is revoked |
| **Delete the channel, or delete its folder** | Every token stops working and the channel is gone. Permanent |
| **The executor loses access to the folder** | Tokens stop authenticating for as long as that is true. Permissions are checked on every request |


To end one user's session without touching anyone else's, revoke that chat's Chat Access Token rather than the Gateway Token. The Agent Gateway's control API can revoke a single token or every token of one chat — see [the endpoint reference](/products/ai-studio/agent-channels/building-an-app#control-api-reference).

## Chat Access Token Lifetimes

A Chat Access Token is created with each chat and handed back to your server along with the chat's endpoint URLs. Two limits apply:

- **Idle lifetime — 24 hours by default.** Each use pushes it out again, so an active conversation stays valid.
- **Absolute lifetime — 30 days by default.** Fixed when the token is issued and not extended by activity.


Whichever comes first wins. The channel's detail page shows the values in effect under **Connection settings** as **Chat token idle TTL** and **Chat token maximum TTL**, and **Edit** changes them for that channel — see [Edit a Channel's Settings](/products/ai-studio/agent-channels/sdk-apps#edit-a-channels-settings).

When a token expires, the chat itself is untouched. Your server reissues a token for the same chat through the control API and the conversation carries on — which is why it is worth storing the chat id, not just the token.

## Browser Access

Whether a browser may call the messaging API at all is a single setting on the SDK App, shown as **Browser access** on its detail page and set with **Allow chats to be driven from end users' browsers** in the wizard. It is **off by default**, and off means *"Server only"*: the gateway refuses any request that arrives with an `Origin` header.

That rule reaches further than it first appears. A browser cannot suppress its `Origin` header when a request carries an `Authorization` header, so with the setting off, **no code running in a browser can reach the gateway** — not your own page's script, and not a compromised dependency or an injected script on it. Your server stays in the path, and so does everything you do there: your own authentication, your audit log, your rate limits, whatever you check a prompt against.

Turning it on is a decision to trust the code in your page. Do it only if your architecture genuinely needs the browser to hold a Chat Access Token and talk to the gateway directly — see [Choose where the token lives](/products/ai-studio/agent-channels/building-an-app#choose-where-the-token-lives) for the trade-off in full.

A proxy must not forward the browser's Origin header
If your server proxies the messaging API, build its own request rather than replaying the browser's headers. Passing the `Origin` header through makes your server look like a browser, and the gateway answers `403` with a message saying the chat cannot be called from a browser. This is the most common way a working integration breaks.

### Why This Is a Switch and Not a List of Origins

Browser access is a yes/no setting. The Agent Gateway holds no list of permitted origins, and that is deliberate rather than unfinished — an allowlist would be the weaker control.

**An allowlist governs what a browser may read, not what it may send.** A request from an origin that is not on the list still arrives at the gateway, the prompt still reaches the agent, and the agent still runs; the browser only discards the answer it is not allowed to read. So an allowlist cannot answer the question you actually have — *can a page I do not control make my agent run, on my credits?* It can only make the answer invisible.

**The switch answers it.** With browser access off, the request is refused with `403` **before the prompt reaches the agent**, so nothing runs. No browser can get around that: a script that sets `Authorization` cannot suppress `Origin`, and a request that omits `Authorization` cannot authenticate at all. The guarantee holds for your own page's script and for anything injected into it.

Two consequences worth planning for:

- **With browser access on, any origin holding a valid Chat Access Token can call.** The gateway echoes the calling origin rather than checking it against a list. What bounds the damage is the token: one chat, and the idle and absolute lifetimes above.
- **Neither setting stops a token copied out to a server.** Requests from a server carry no `Origin`, so they pass in both modes. If that matters, keep the token server-side — the [proxy shape](/products/ai-studio/agent-channels/building-an-app#choose-where-the-token-lives) is what closes it.


## Handling Credentials Safely

- **Keep the Gateway Token on the server.** Put it in a secret manager, not in source control, a build artifact, or an environment variable printed by a debug endpoint. It is as sensitive as the folder it reaches.
- **Never ship it to a client.** Nothing in a browser or a mobile app should be able to obtain it, directly or through one of your own endpoints.
- **Give each application its own channel.** A shared token cannot be revoked for one consumer only.
- **Bound the lifetime where you can.** A 90-day token with a rotation reminder beats an undated one nobody revisits.
- **Watch Last used.** A token nothing has called in months belongs either to a forgotten deployment or to nothing at all; either way it should not stay active.
- **Treat a leak as a rotation, not an investigation.** Issue a replacement, deploy, revoke the leaked token. Then work out how it got out.


## Next Steps

- [Building a Chat App with the Vercel AI SDK](/products/ai-studio/agent-channels/building-an-app) — using these credentials in code.
- [Creating and Managing an SDK App](/products/ai-studio/agent-channels/sdk-apps) — issuing and revoking from the interface.
- [What an Agent Channel Chat Can Reach](/products/ai-studio/agent-channels/channel-chats) — what a credential's holder can actually make the agent do.