Security and trust

Coco starts with approval. It can read freely, reason deeply, and prepare the work — but it cannot send, write, or spend without your explicit approval at the start. Once a workflow is approved and working well, you can let it run autonomously inside the guardrails you define.

Coco's security model has one rule that overrides everything else: no external action without your explicit approval at the start. Sending emails, writing to your CRM, spending credits on execution, posting to channels — every one of these is gated. Coco can read freely and prepare the work, but the action ships only when you approve. Once a workflow is approved and proven, you can let Coco run it autonomously inside the guardrails you define. Every action is logged. Every credit is tracked. Every output links to what happened. SOC 2 is in progress; EU data residency is available; your keys and your data stay yours.

Try Coco for free → · 1,000 credits free · no card · ~2-min setup

Approval gates — what they cover and what they don't

The approval model splits Coco's behavior into two halves. One half is free. The other half is gated.

What's gated: Sending emails. Writing to your CRM (new contacts, field updates, deal stage changes, contact deletions). Posting to Slack channels or DM-ing teammates. Calling third-party APIs that mutate state (enrolling a contact in an Outreach sequence, triggering an Apollo enrichment batch, scheduling a meeting on someone's calendar). Spending credits on execution-class work. Any action that creates a side effect outside Coco's container.

What's not gated: Reading data from connected tools to build context. Drafting content (emails, follow-ups, briefs, CRM field proposals, list segments). Planning workflows. Reasoning about what to do. Updating Coco's own per-user memory with patterns learned from your approvals. Lookups against safe, read-only API surfaces on connected tools.

The split is honest. Reads and drafts are cheap, low-risk, and don't change anything in the world, so they happen without the gate slowing the work down. Actions that ship or spend or change state stay behind it. The Apollo integration is the canonical example of how the split plays out: safe lookup tools work as soon as your API key validates; enrichment, list-building, sequence enrollment, and bulk operations stay approval-gated until you authorize the specific workflow.

The gate isn't a confirmation dialog after the fact. It's a structural part of the loop — Coco can't even attempt to ship a gated action without the approval token. That's the difference between an approval gate by default and one bolted on as a configurable option.

From approval to autonomous — how trust scales

Workflows don't have to stay at approve-each forever. Once a pattern has been approved a few times and you're comfortable with how Coco runs it, you can authorize that specific workflow for autonomous execution inside guardrails you define.

A guardrail is a per-workflow rule, written in plain English, that scopes what Coco can do without coming back for approval. Examples that exist in production today: "Auto-enrich any new HubSpot contact tagged 'design partner candidate' within 24 hours." "Auto-draft follow-ups for any deal silent more than 14 days at the qualified stage. Queue drafts for review; don't send." "Auto-archive contacts where every email has bounced and there's been no activity in 90 days. Notify me first." Inside that rule, Coco runs. Outside it, the gate holds.

The guardrails are yours. They're scoped per workflow, not global. You can authorize CRM hygiene to run autonomously while still requiring approval on every outbound send. You can authorize a follow-up draft workflow while reserving the actual send for human review. The trust ladder is gradual, granular, and reversible — if an autonomous workflow starts producing output you don't like, you pull it back to approve-each in a single setting.

This is what we mean by approval-first, then autonomous within your rules. The default is conservative. The graduation is earned. See the approval-gate philosophy deep dive for the longer argument about why the trust ladder beats both "ask every time forever" and "trust everything from day one."

Audit trail — what gets logged

Every action Coco takes is logged with enough context to reconstruct exactly what happened. The audit row for a typical external action captures:

• Who approved it. The user identity tied to the approval token.
• When. Timestamp.
• What changed. The specific field, record, draft, or message that was created or modified.
• What it cost. Credits debited from your balance, with itemization if the action touched a paid third-party API.
• What Coco reasoned. The plan card that led to the action, plus any clarifying questions and answers from the chat thread.

Approval reviews and audit-trail entries themselves cost no credits; only the underlying actions do. The audit feed is searchable and filterable; on the Team tier, the admin audit trail rolls up activity across all team members with the same level of detail.

Reversibility depends on the underlying system. A Gmail draft is unsent until you approve, so reversing is trivial. A HubSpot field write can be reverted from the audit log; Coco stored the prior value before the change. A Salesforce deal stage move can be rolled back the same way. An email already sent is in the world; the audit row records it, but undoing the action requires a follow-up email, not a button click. The honest framing: most writes are reversible; most sends are not. The approval gate is the structural defense against the unrecoverable category.

Per-user runtime isolation

Each user gets a dedicated Hermes container — the runtime Coco operates inside. The container has its own volume, its own session history, its own memory, and its own tool configuration. Tenants cannot read each other's sessions, prompts, or intermediate memory. There's no shared model context across users, no cross-tenant memory leak.

The isolation runs deeper than a typical multi-tenant SaaS. The container model means even Coco's reasoning state — the chain-of-thought, the plan generation, the intermediate tool calls — lives in a per-user sandbox. If User A's session is processing a sensitive HubSpot deal review, User B's session has no way to observe or interfere with it.

A few technical anchors for the security team reading this: WebSocket connections authenticate with JWT on every upgrade. Internal endpoints are blocked at the public edge so they're never directly addressable. Per-user internal bearer tokens are hashed with SHA-256 before storage. session_id and user_id are validated at every ingress to prevent session smuggling. Container WebSocket errors don't leak infrastructure details to the frontend — error messages stay generic at the user surface.

The isolation is enforced at the container boundary, not at the application layer. That's the difference between "we promise tenants are separated" and "the operating system enforces it."

Data handling — what Coco sees and what it stores

Coco only sees the tools you connect and the scopes you grant. There's no implicit data access. The connection flow is explicit about which scopes are requested, and you can grant the minimum subset of those scopes if you want Coco to run in a more restricted mode. Read-only connections let Coco research and draft without ever being able to write or send.

You can audit or revoke any connection at any time from the integrations page. Revocation is immediate; pending workflows that depend on the revoked connection pause and surface as needing reconnection. Coco doesn't cache the data it pulled before the revocation — what's left is what you explicitly approved into your CRM, your inbox, or Coco's own per-user memory.

Memory is persistent but scoped. Coco remembers your ICP shape, your tone in outreach, your team's playbooks, the tools you prefer for which jobs, and the rules you've set on workflow guardrails. That memory lives in your isolated container, not in a shared model. Other users don't see your memory; you don't see theirs. Custom voice training on the Founder tier and above feeds the per-user memory specifically and doesn't pool into a shared corpus.

For the model layer: model calls go to upstream providers (Anthropic, OpenAI, depending on the workflow) per their data-use terms. We don't train on customer content. Inputs go to the providers under their privacy contracts; the responses come back into your container and are logged in your audit trail.

Compliance posture

Honest section.

SOC 2 — in progress. Coco is working through the SOC 2 audit. Team tier customers can request the current status and the controls catalog under NDA. We'll publish certification once we have it; we won't claim it until we do.

EU data residency — available. Available, not automatic. If your team needs data to stay in the EU, the Team tier ships with EU-resident infrastructure on request. The default deployment is US-resident.

DPA — on request for Team tier. A Data Processing Agreement is signed on request as part of the Team onboarding. GDPR-aligned terms; customer-specific addenda accommodated case by case.

Your keys, your data. When you connect a tool with an API key (Apollo, ZoomInfo, custom integrations), the key is encrypted at rest using Fernet symmetric encryption inside your isolated key store. The key is decrypted only inside your container at the moment a tool call needs it. Team-owned credentials use environment variables on the backend; per-user credentials use the encrypted store. See the integrations hub for how connections are scoped per-user.

The principle behind the posture: claim what's true today, name what's in progress, and don't oversell. SOC 2 is in progress because the audit is real. EU residency is available because the infrastructure exists. The transparency is part of the trust model — if we overpromise on compliance, the rest of the security story loses credibility.

Defense in depth

Below the application layer, the container runtime itself is hardened:

• Runs as unprivileged user. Uid 10001, hardcoded. The container has no root.
• All capabilities dropped. Linux capabilities are stripped at startup — the runtime can't escalate, can't mount, can't bind low ports, can't access raw network sockets.
• Privilege escalation blocked. no_new_privs is set so even a misbehaving binary can't gain capabilities it didn't start with.
• Read-only root filesystem with bounded /tmp. The container can't write to its own image. Temporary writes land in a tmpfs with a fixed size cap so a runaway process can't fill the disk.
• Capped PID count. A fork bomb can't take down the runtime.
• Internal endpoints not exposed. The Hermes management interface is blocked at the public edge so it's never directly addressable from outside the trusted network.

These are infrastructure-engineering details that won't show up in your daily use of Coco. They show up when your security team reviews the architecture. The point of including them on this page: when your security team asks "what stops a misbehaving workflow from doing real damage," there's a specific answer that goes deeper than "we monitor it."

A note on what these details don't do: defense-in-depth at the container layer doesn't replace the approval gate at the application layer. They sit in series. The gate stops Coco from attempting to ship an unauthorized external action; the container limits what would happen if something went wrong inside the runtime itself. Both layers exist; both layers hold.

What we recommend our customers do

The trust model works best when you bring it into how you set up your team:

• Connect tools with scoped credentials where possible. Use API keys with the minimum scope each workflow needs, not personal logins with full account access. The HubSpot integration page lists the exact scopes Coco uses per workflow.
• Use approval gates aggressively at first. Don't graduate workflows to autonomous execution until you've watched them run a few times. The graduation is reversible; the bad-output risk is not always reversible.
• Use Team tier for shared workflows. Centralized audit trails mean the GTM lead or RevOps owner can see what's running across the team without each operator having to surface it manually. Team tier includes the admin audit trail; see the pricing page for the full feature list.
• Rotate API keys quarterly. The encrypted key store supports rotation without losing the configured workflows; updating a key takes a minute. Quarterly rotation is a low-effort hygiene practice that limits the blast radius if a key is ever compromised upstream.

None of these are mandatory. They're the practices that make the security model hold up in real-world use rather than only on paper.

Try Coco for free → · 1,000 credits free · no card · ~2-min setup

Frequently asked questions

What data does Coco see?

Only the tools you connect and the scopes you grant. There's no implicit data access. The connection flow explicitly requests scopes, and you can grant a minimum subset if you want Coco running in a more restricted mode. You can audit or revoke access at any time from the integrations page; revocation is immediate.

Where is data stored?

In your per-user isolated container with its own volume, session history, and tool configuration. Tenants can't read each other's data. EU data residency is available on the Team tier; the default deployment is US-resident. Memory is persistent across sessions but scoped to your container — no cross-tenant memory pooling.

Can I revoke Coco's access?

Yes, at the integration level, at any time. Disconnecting a tool from the integrations page is immediate. Pending workflows that depend on the revoked connection pause and surface as needing reconnection. Coco doesn't retain a cached copy of the data it pulled before revocation — what's left is what you explicitly approved into your own systems and Coco's per-user memory.

Is Coco SOC 2 certified?

In progress. The audit is underway; we'll publish certification once we have it. Team tier customers can request the current status and the controls catalog under NDA during the onboarding conversation. We don't claim certification we haven't earned — the transparency is part of the security posture.

Does Coco share data with model providers?

Model calls go to upstream providers (Anthropic, OpenAI, depending on the workflow) per their data-use terms. We don't train on customer content. Inputs travel under the providers' privacy contracts; responses come back into your container and are logged in your audit trail. If a specific model provider isn't acceptable to your team, the Team tier conversation includes routing options.

What happens to a workflow mid-approval if I'm offline?

It waits. Coco doesn't execute external actions while you're away unless you've authorized autonomous mode for that specific workflow with explicit guardrails. The pending approval queues in your inbox/activity feed and waits for you to come back. Session state persists across reconnects so no work is lost; nothing executes silently.

How are API keys stored?

Fernet-encrypted at rest in your per-user encrypted key store. Decryption happens only inside your container at the moment a tool call needs the key. Team-owned credentials use environment variables on the backend rather than the per-user store. Rotation is supported without losing configured workflows.

Get started

If your security team needs more than what's on this page, the Team conversation is where the controls catalog, the SOC 2 status update, and DPA terms get walked through end to end. For everyone else, the fastest way to evaluate the trust model is to connect one tool, watch the approval gate in action on a real workflow, and decide whether the posture matches what your team needs.

Try Coco for free → · 1,000 credits free · no card · ~2-min setup

Or book a walkthrough → if you'd rather have your security team in the room first.