Security model
Encryption, read-only guarantees, PII redaction, the shared-credential threat model, and what leaves your network.
What leaves your network
Very little, and it is worth being precise about it.
Leaves: ticket text and metadata (after redaction), evidence the agent gathered, and prompts — all sent to your configured LLM provider, using your key. Plus configuration reads and writes between the portal and each desktop.
Does not leave: query results as a corpus, investigation reports, Console threads, usage totals, or anything the agent read that did not end up in a prompt. There is no telemetry channel that uploads investigation content to us.
The agent runs on a member's own machine and connects to your infrastructure from there. Your databases never need to be publicly reachable.
Encryption at rest
Every credential — shared integration secrets, AI provider keys, personal integration credentials, issue-tracker tokens — is encrypted with AES-256-GCM.
Two keys are involved, by design:
- Secrets in the cloud are encrypted under the platform key, delivered over TLS only to an authenticated desktop.
- On arrival they are re-encrypted under that machine's own local key, which never leaves the machine.
API responses only ever contain masked (•••) secret values. There is no endpoint,
and no admin screen, that returns a plaintext secret.
Losing a desktop's local key is unrecoverable
Stored secrets on that machine can no longer be decrypted and the affected
integrations report cannot decrypt stored secrets. Organization-shared integrations
re-sync from the portal; personal ones must be re-entered.
Read-only guarantees
Write protection is enforced at the MCP server level — read-only flags, non-destructive tool sets, disabled write operations — not by asking the model not to write.
That is the strong version of the guarantee, but it still depends on the MCP server's own code being correct. For production, do both:
- Point every integration at a read-only database user or a read-scoped token.
- Leave the read-only toggles on.
With both, the guarantee is independent of any single layer being bug-free.
A handful of integrations have no server-side write block at all, so for those the credential is the only boundary — they are called out in Connecting data sources.
PII redaction
On by default. Before any ticket content is assembled into a prompt, emails, phone numbers, national ID numbers, IPv4 addresses and Luhn-valid card numbers are redacted out of the subject, body and metadata.
Redaction runs on the same helpers for every path — background triage, the Console, ticket follow-up chat, playbook classification, and vector-search indexing — so there is no code path that quietly skips it.
It also runs over the identity fields derived from CRM association data, rather than relying on the LLM extraction step to catch them. PII removal does not depend on a model behaving.
The shared-credential threat model
Shared integrations let one credential serve the whole organization. The guarantee is:
A member cannot recover the secret value. The member-facing view has no credential, environment or header fields at all — not masked ones, none — so there is nothing to inspect in the UI or at the API level.
A member cannot repoint a stored credential. Members cannot edit shared integration
configurations, which closes the "change the command to env and read the
environment" exfiltration path. That is enforced by write access, not by masking.
"Use, not view" is about the secret, not the data
A member who can use a shared Postgres integration can read whatever that Postgres user can read, through the agent. "Cannot view" means the credential's value, never the data the credential unlocks. Scope the credential itself accordingly.
Webhook verification
Incoming HubSpot webhooks are verified against an HMAC-SHA256 signature — computed over method, URL, raw body and a request timestamp that must be within five minutes of now — whenever a webhook secret is configured.
Without that secret configured, the endpoint accepts unsigned payloads. Set it before pointing a real HubSpot subscription at anything but a local test.
Rate limiting
In-memory and per-process:
| Endpoint | Limit |
|---|---|
| Login | 10 requests / minute |
| Webhooks | 120 requests / minute |
| Everything else under the API | 600 requests / minute |
Audit
Every mutation to authentication, organizations and teams, playbooks, integrations, issue trackers, filed issues and ticket playbook assignment writes an append-only audit row with actor, organization, action, target, before/after payload and timestamp. See Audit log.
Practical hardening checklist
- Read-only database users and read-scoped tokens for every integration.
- A monthly spend cap set before members start working.
- Least-privilege issue-tracker tokens — issues read/write and metadata, not full
repo, where fine-grained tokens are available. - Leave PII redaction on.
- Configure the webhook secret before any production webhook.
- Review the audit log's actor column periodically; disable members promptly when they leave.