Skip to content
Bunkhouse Docs

Security

Bunkhouse runs inside your application, next to your users’ data. This page covers the boundaries you configure and the ones you keep.

Keys

Section titled “Keys”
Prefix What it is Where it lives
pk_ Publishable site identifier In your page’s script tag; safe to expose
ss_ Signing secret for identity tokens Server only; never sent to the browser
sk_ Mint key for server-created sessions Server only; never sent to the browser

Create and rotate signing secrets and mint keys on the site’s Keys page in the dashboard.

Allowed origins

Section titled “Allowed origins”

Each site lists the exact origins where its script tag may run. Sessions are only created for those origins. An origin check identifies where a request came from; it does not identify or authorize a user. Use signed sessions to tie a session to someone your application has signed in, and enable anonymous access only for content anyone may use.

User identity and authorization

Section titled “User identity and authorization”

In signed modes, send a stable, opaque user ID such as your database ID, not a name or email address. Your backend decides who the user is before it signs a token or creates a session.

Your backend also stays in charge of what that user may do. The assistant acts through your application’s own interface and API in the user’s browser, so keep authorization checks on your server, exactly as you would for the user clicking through the UI.

Private content

Section titled “Private content”

Password, payment and file fields are never read. Mark any other part of the page the assistant must not read with data-agent-private:

<section data-agent-private>
  <!-- Not read by the assistant -->
</section>

You can also list CSS selectors in the hints file’s privateSelectors.

Disclosure and approvals

Section titled “Disclosure and approvals”

Before the first use, the pane shows a disclosure naming who receives the conversation and page data; the user must accept it before the assistant starts. Write actions (API writes, consequential WebMCP tools, and clicks or submits) are shown for review before they run, with a warning that they may not be reversible. Users can choose to auto-approve writes for a single run.

Next steps

Section titled “Next steps”