> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dubot.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Governance and security

> The current browser, identity, action, and publishing boundaries

## Authority is explicit

Dubot combines several controls rather than treating an installed script or connected AI client
as unrestricted product authority.

| Control             | Boundary                                                                                  |
| ------------------- | ----------------------------------------------------------------------------------------- |
| Client token        | Public workspace and SDK-delivery identifier, optionally constrained by origin            |
| Identity token      | Customer-server proof of the current end user                                             |
| Capability          | Reusable context and the outer action allowlist for a wizard or the Resource Center Agent |
| Published registry  | Exact action version, schema, endpoint, mask, and availability                            |
| Execution policy    | Auto or explicit confirmation                                                             |
| Customer executor   | First-party code that owns authentication and performs Session API calls                  |
| Response mask       | Fields that may return to the assistant                                                   |
| Test/Production     | Draft visibility versus published customer traffic                                        |
| MCP workspace grant | Authoring boundary for an external AI client                                              |

## Identity

The workspace identity-verification secret stays on the customer's server. That server signs an
HS256 JWT whose subject matches the `userId` passed to the SDK. Test and Production can observe
signature coverage before enforcing it.

Unsigned identities should not be allowed to authorize or use the end-user MCP action channel.

## Action execution

Session API actions are executed by customer-owned first-party code. The SDK asks for a published
tool by id and supplies validated arguments; it does not accept an arbitrary method or destination
from the model. The customer's application keeps possession of its own bearer token, cookies,
CSRF logic, and other credentials.

Client-side callbacks are functions the host explicitly registers. They are available only while
the current host registration and a published Skill capability attached to the active agent both
allow them.

## Policy and confirmation

`auto` actions can run without an approval prompt. `confirm` actions show the exact proposed
operation and wait for approval. High-risk and destructive classifications prefill Confirm in the
current authoring interface, but reviewers must verify the saved execution policy.

Confirmation is one control, not a replacement for least-privilege endpoints, server-side
authorization, input validation, rate limits, or safe failure behavior.

## Publishing

Production resolves published versions only. Saving, merging code, previewing in Test, or showing
a Storybook state does not publish customer configuration. Unpublishing and archiving are separate
operations.

## Review checklist

Before a journey reaches customer traffic, document:

* customer outcome and environments in scope;
* allowed origins and public client token;
* user-id source, JWT minting, lifetime, rotation, and enforcement mode;
* minimum session context;
* every action, response mask, risk, and execution policy;
* customer-side authorization and failure handling;
* knowledge sources and scope;
* publish, rollback, and unpublish ownership;
* activity, retention, and escalation expectations;
* representative success, decline, failure, and unavailable-state tests.