Security

connect0 is a hosted, multi-tenant platform that gives AI agents an identity, a budget, credentials to a business's systems, and a record of everything they did. This document is written for the person who has to decide whether to let it near their company's data. It states what the controls do, and — more usefully — what they do not.

It is versioned with the code. Every change that moves a boundary edits this file in the same pull request, and the published copy at /docs/security is generated from it, so the two cannot drift.

Last reviewed: 2026-09-24.

---

1. Reporting a vulnerability

Write to security@connect0.ai. Please include what you did, what you observed, and what you expected; a proof-of-concept request or a short script is worth more than a scanner report. We acknowledge within two business days.

Please do not run automated scans against production, do not access, modify or retain data belonging to another account, and do not perform denial-of-service testing. If a proof of concept requires a second account, tell us and we will provision one.

We do not currently run a paid bounty. We will credit you in the release notes if you would like that.

2. Scope

connect0 is hosted and multi-tenant. There is no self-deployed edition. The security boundary that matters most is therefore the one between two customers, and it is the account.

• An account owns projects, agents, connections, credits, files, threads and audit records. Every authenticated request resolves to a principal, and every principal is scoped to an account before any domain code runs.
• People hold roles on an account — owner, admin, member, viewer — and role checks live in the control plane, not in the agent.
• Agents are principals in their own right, with their own credentials and their own account scope. An agent is capped at member-equivalent authority; it cannot hold admin.
• Service-to-service calls between our own apps are authenticated and scoped; an internal route takes a run id and resolves the actor from the stored row rather than trusting a caller-supplied identity.
• Per-agent public endpoints and the MCP server are authenticated surfaces at the same account boundary. A public endpoint is public in the sense of reachable, not in the sense of unauthenticated.
• Blocks — the sellable engines such as the ledger — share the platform's identity and roles, and each keeps its tables in its own database. A block never reads another block's rows.

Out of scope for this document: the security of a customer's own connected systems, of a model provider we route to, and of a customer's own model keys when they bring them.

3. Protected assets and actors

Assets, in roughly the order an attacker would want them:

Asset	Where it lives	Protection
Connection tokens (the customer's OAuth grants to their own systems)	Encrypted at rest, held by the OAuth aggregator we operate	Never rendered to a model; never returned by an API read
Platform model keys	Encrypted with a KMS key, unwrapped in memory at call time	Never leave the request path; never logged
A customer's own model keys (BYOK) and their ChatGPT subscription grant	Encrypted at rest	Used only for that account's calls
Den secrets	Encrypted at rest, injected into the machine at start	Plaintext inside the running machine, by necessity
Conversation and model-request data (threads, the stored request envelopes)	Our Postgres	Redacted on the operator console until an audited reveal
Agent memory	Our Postgres, per account	Scoped per account; provenance-tiered
Files	Object storage, per account	Signed, expiring URLs; never a public bucket
Audit records	Our Postgres	Append-only in practice; not customer-erasable
Money (credits, spend caps)	Our Postgres	Caps enforced before the spend, not after
Side effects in connected systems	The customer's systems	The subject of most of this document

Actors:

• Account members, by role.
• Operators (us). What an operator can and cannot do is the next section.
• Agents — the first-party assistant (Zero) and the customer's own agents.
• Sandboxes and dens — the compute an agent's code runs in.
• Model providers — they receive prompts.
• The OAuth aggregator we operate — it holds connection tokens.
• Connected services — they receive the agent's calls.
• Inbound channels — e-mail and webhooks deliver content we did not author.

4. Trust boundaries, and what we assume about ourselves

We operate the cloud account, the network, the databases, the key management, and the initial administrative grants. We are the operator this document cannot protect you from, and saying so plainly is more useful than implying otherwise.

Concretely:

• An operator can read customer content. Thread messages, tool arguments and model payloads are redacted by default on the internal console; revealing them requires an explicit action that writes an audit row naming the operator, the run and a stated reason. The reveal is audited, not consented — we do not ask the customer first. Aggregates (counts, durations, costs, error kinds) are never gated, because an operator can do most of the job without reading anything.
• An operator cannot act as a customer's user. There is no impersonation path: the actor on a run is derived from the stored row at dispatch, and no header, tool argument or internal field substitutes a principal.
• An account's admins can read that account's threads, except those a person marked private. This is a product decision, not an accident.
• Model providers receive prompts. Which provider a call goes to is chosen by the model router; a customer using their own key sends to their own provider under their own contract.
• The agent is not trusted to make authorisation decisions. Identity, scope, grants and effect gates are enforced by the control plane before a tool runs. An agent that "decides" it may do something does not thereby may.
• Inbound and connector content is untrusted data. Authentication of a webhook proves who sent it, not that what it says is true or safe. Text that arrives from outside is data; it is never an instruction, however it is phrased.

5. What the controls do and do not guarantee

The controls below are designed to reduce the chance and the blast radius of an agent doing something a person did not intend. They are not a formal proof of anything.

• An approval means a human accepted the displayed action under the information available. It does not mean the action was safe, that the displayed summary was complete, or that the model's intent matched its description.
• Audit supports investigation. It does not prevent. An audit row is written because something happened.
• A spend cap bounds money, not damage. An agent can do something irreversible and cheap.
• Screening is heuristic. It is a model judging text. It will be wrong in both directions.
• A command policy is a speed bump, not a sandbox. See the known limitations below.

6. Security postures

One setting per account, which a project or an agent may only make stricter, never looser. The account's choice is a floor.

• Strict — every tool call with a side effect pauses for a person's approval before it runs. Approvals can be granted once, for the current conversation, or standing for that tool. Reads never pause. The cost of Strict is that unattended work (a schedule, an inbound message at 3am) waits for a person and eventually times out; that is the trade, and it is stated to the model in its own instructions.
• Auto (the default) — nothing pauses, and external content is screened before the model sees it. Content that the screen judges to be trying to issue instructions is quarantined: it is replaced in the model's view by a one-line notice, a person is offered the choice to release or discard it, and the run continues without it. A hostile web page can therefore cost you a step; it cannot stop your agent.
• Dangerous — neither. It exists because some workloads are entirely internal and the friction is not worth it. It is never a default and the console says what it means.

Hard denials, authentication, tenancy, credential scope and audit apply in every posture, Dangerous included. The posture governs approvals and screening, nothing else.

A separate sharing posture governs what may leave the account through a shared thread or a carried skill.

7. Deliberately portal-only actions

Three things can never be done by an agent, a tool, a skill or an API token acting on an agent's behalf. They are available only to a signed-in person in the dashboard. These are walls, not gaps:

1. Changing who is a member of an account, or what role they hold.
2. Acting as a principal other than the one the run resolved.
3. Resolving an approval — approving a gated tool call, confirming a proposed action, answering an elicitation, or releasing quarantined content.

Each of these authorises future agent behaviour. An agent that could perform any of them could grant itself the authority it was refused, so the decision must come from outside the agent. A build gate (check:portal-only-walls) fails the repository if the functions behind these actions are ever imported into a tool registry, an agent-reachable route, or a skill client.

8. Known limitations

Every line here is a thing we do not do. They are listed because a reviewer's time is better spent on the gaps than on the guarantees.

• The command policy is bypassable. It normalises and inspects command text before running it, and it catches the common evasions (quoting, sh -c, eval, heredocs, pipes into a shell, variable substitution, SQL client payloads). A determined author can still write a file and execute it, or encode a command the normaliser does not decode. Treat it as a speed bump.
• The sandbox does not block network egress. Its restricted mode is advisory: it is exported to the shell for cooperative scripts, and nothing prevents a process from reaching the public internet.
• Sandbox and den credentials are plaintext while in use. They are encrypted at rest and injected at start; a process inside the machine can read them.
• Browser actions sit outside the approval gate. A browsing task is approved once, as a task, and bounded by spend caps — not per action.
• Screening is incomplete as well as heuristic. Command output, binary content, images and raw webhook payloads are not screened.
• An operator can read customer content — see Trust boundaries above — audited.
• An account's admins can read that account's threads other than private ones.
• Memory-poisoning defences are heuristics. Memory carries a provenance tier and lower-trust content is marked, not excluded.
• Spend caps fail open if the counter store is unavailable. We would rather let work continue than stop an account because a cache is down; the alternative is an outage disguised as a control.
• Stored request envelopes may retain text that a memory redaction removed, for up to 90 days, until the envelope sweep reaches them.
• Snapshot and share links are bearer credentials. Anyone with the link has the access until it expires or is revoked.
• A dashboard session cannot be revoked before it expires once the token has been copied out.
• No secret scanning on file write. An agent that writes a key into a file in its workspace is not stopped.
• No account-level kill switch. Stopping everything at once today means removing credentials or caps.
• Revoking a provider token is per provider. Some providers do not offer programmatic revocation, so "disconnect" means we forget the token, not always that the provider invalidated it.

9. Dependencies

• Dependencies are pinned by a committed lockfile and installed with --frozen-lockfile in CI; updates arrive as reviewed pull requests.
• Structural boundaries are enforced by build gates rather than by convention: service boundaries, client/server import direction, identifier boundaries at the API edge, and the portal-only walls in the portal-only walls above. A pull request that crosses one fails.

10. Supported versions

main, hosted by us. There are no released versions to patch and no self-deployed installations to support. A fix ships to production on the next release, which is usually the same day.