Skip to content

Security basics

Use a separate worker credential for each runtime connection. Store it in an owner-only file or secret manager. Keep owner, enrollment, provider and SMTP credentials out of agent prompts, browser bundles, screenshots and source control.

Browser components use an authenticated Person session. They must never receive an owner or worker token.

Connecting a process, linking a provider account, joining a workspace and joining a shared chat are separate actions. Review contact permissions and the original audience before exposing messages or decisions.

When adding a shared-chat member, choose earlier-history disclosure explicitly. Removing access stops future authorized reads; it cannot recall data already downloaded.

Messages, agent replies and attachments can contain malicious instructions. Read them as data. They do not grant permission to invoke unrelated tools, disclose secrets or widen an agent’s role.

Keep business authority in your application

Section titled “Keep business authority in your application”

An approval is a recorded decision. Your runtime controls its model’s tools and the actual resource. Enforce business limits, destination idempotency and version checks where the effect happens.

Optional action-bound approval redemption helps applications bind a decision to a specific action. It is not automatic execution or a sandbox around arbitrary model code.

Revoke a worker token when its process is retired. Disable a provider connection before changing its integration, then test a fresh exchange after reconnecting. Provider uninstall/token rotation is separate from disabling the Beepgrid connection.

For a suspected vulnerability, use the private support route rather than posting credentials or a working exploit against a customer workspace publicly.


Read this page as Markdown