Busymate AI
Try the demo

Trust

Security, built into the product

Here is what you can verify today, in plain words, with the exact standard next to each promise. No compliance badge appears here until an audit exists.

Talk to usDeveloper guide

The same rules for every workspace

Sign-in confirmation expires after
120 s
Action confirmation expires after
300 s
PKCE method
S256
Access levels
3, plus a confirmation step
1Host2Kept separate3Handshake4Sign-in5Access level6Confirm step7Write-only keysUnknown host403

01Control

Your data stays yours

Each business’s data is kept separate from every other — enforced in the database itself.

  • Every conversation, published version and permission belongs to one workspace, and the database enforces it (row-level security), not only the app.
  • A web address that is not mapped to a workspace never sees anyone’s data; its signed-in paths answer with a 403.
  • If the system cannot tell which workspace a request belongs to, it refuses the request instead of guessing.

02Control

The standards we use

Nothing home-made: the standards are named exactly, and this page reads them live.

  • Your systems are connected over HTTPS using MCP (JSON-RPC 2.0), and every action’s schema is visible at discovery.
  • AI tools connect to the platform with OAuth 2.1 with PKCE (S256), dynamic client registration and refresh tokens.
  • The sign-in response names its issuer, so a token cannot be mixed up between servers (RFC 9207) — advertised by our authorization server and checked by our connector client.
  • When the platform connects to your systems it names the exact resource it is asking for (RFC 8707). Token exchange (RFC 8693) only where configured.
MCP · JSON-RPC 2.0OAuth 2.1PKCE S256RFC 9207RFC 8707
/.well-known/oauth-authorization-server/mcpjson
{
  "issuer": "https://busymate.ai/mcp",
  "authorization_endpoint": "https://busymate.ai/mcp/authorize",
  "token_endpoint": "https://busymate.ai/mcp/token",
  "registration_endpoint": "https://busymate.ai/mcp/register",
  "grant_types_supported": [
    "authorization_code",
    "refresh_token"
  ],
  "code_challenge_methods_supported": [
    "S256"
  ],
  "token_endpoint_auth_methods_supported": [
    "none"
  ],
  "authorization_response_iss_parameter_supported": true
}

Read from the live authorization-server metadata when this page renders — never typed.

03Control

Who the customer is

Your sign-in vouches for the customer.

  • Your site signs a short-lived confirmation with your own key (ES256 is the reference algorithm; the allowed algorithms are part of your registration).
  • The confirmation is at most 120 seconds old, can be used once (a one-time nonce and jti), and names the audience busymate-ai and your workspace.
  • Nothing the browser says about who it is gets trusted; the assistant acts only for the identity in the signed confirmation.
Recognize signed-in customers

04Control

What it may do

You decide what it may do, and it asks before it changes anything.

  • Every action has one of three access levels: open to anyone, signed-in customers only, or on the customer’s behalf.
  • A change waits for a confirmation on the server, not in the browser: any action you mark for confirmation stops at a confirmation card, and so does any action the assistant does not recognize.
  • The panels inside the chat only display results; they never run a change.
  • When it acts on a customer’s behalf it carries a signed confirmation issued by the platform (HS256, 300 s) or the customer’s own OAuth permission.
Connecting your systems

05Control

Your keys and your data

We can use your keys but never show them again — not even to you.

  • Credentials for your systems are write-only: set them, rotate them, never read them back.
  • Permissions are stored encrypted per workspace and per connection; one business’s permission is never reused for another.
  • Before connecting to a new address we check it cannot reach anything internal (SSRF protection).
  • Requests go to your own systems — you own the data.

06Control

Who else sees conversation text

Only the AI providers you allow, and only when you say so.

  • The AI providers on your allowed list are the sub-processors; you choose them per workspace, and usage is shown per provider.
  • Anything that sends conversation text elsewhere — an AI model, a translation step during handoff — is switched on per workspace and disclosed to the customer.

07Control

Reporting a vulnerability

Found something? Tell us before anyone else.

  • The current contact and scope are published in our security.txt.
/.well-known/security.txtAsk bro

Read the rules, then connect

The same rules apply to every workspace. Connect your systems and see them enforced.

Get startedConnect your systems
claude mcp add --transport http busymate-ai https://busymate.ai/mcp