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.