Security
Last updated: 2026-06-19
This page is for three readers. A workspace admin preparing an IT and legal approval memo before installing Mycelium. A Fortune 100 procurement reader following a sales-link to understand the trust posture. And a security researcher looking to report a vulnerability. All three are below.
Eight trust commitments
Eight commitments Mycelium ships on every tier, in code and in the Terms of Service. These appear inline in the onboarding wizard at the OAuth step, not buried in fine print. Some commitments are tier-conditional (Team and Enterprise add audit log and a private personal layer); we flag the tier explicitly per commitment.
These eight are the canonical list. We add new commitments only after panel review (to avoid trust-claim creep). If a future surface adds one, it lands here first, before any marketing copy refers to it.
1. Credentials encrypted at rest
What this means. OAuth tokens, refresh tokens, and API keys are encrypted at rest at the storage layer. Customer content at rest is encrypted too. We never read tokens or content in plain text from disk.
How we enforce it. Postgres-managed at-rest encryption with AES-256 on every persistent surface. TLS 1.3 at the public boundary; mTLS at the inter-service boundary inside the runtime. Per-tenant encryption keys (BYOK) are available on the Mycelium Enterprise tier; key rotation via the admin API. The full encryption surface is documented in the Data Processing Addendum.
2. Disconnect equals delete within 24 hours
What this means. When the workspace admin disconnects a connector, the data ingested from that source is removed within 24 hours. That covers raw events, derived embeddings, and indexed knowledge-graph nodes that traced to the source.
How we enforce it. Disconnect runs in two phases, both now architecture-enforced end-to-end.
Phase 1 (synchronous): when the admin disconnect endpoint is called, the runtime flips the source into the tenant’s disconnected_sources set. Every webhook receiver (Slack, GitHub, Notion, Linear, Gmail, Salesforce, Microsoft 365, Confluence, Google Workspace, ServiceNow, Workday, and twelve more) checks this set before signature verification and returns HTTP 410 Gone if the source matches. No new content ingests after the call returns. The audit log carries connector.disconnect.requested + connector.disconnect.scheduled on the same tick.
Phase 2 (asynchronous, scheduled): the same call queues a purge job at vault_path/.runtime/disconnect_jobs/{source}.json with scheduled_at = now + grace_period_seconds (default 24 hours, configurable 0 to 720 hours). The worker tick processes due jobs on a 15-minute cadence: it walks vault_path/External Inputs/{source}/, removes the files, then drops the matching embedding rows. The audit log carries connector.disconnect.purge_started and connector.disconnect.purge_complete (or purge_failed on error, with operator alert and retry within the grace window). Worst-case purge latency is grace_period + 15 minutes, which keeps the end-to-end 24-hour SLA architecture-tight when the default grace is used.
Customers can cancel a scheduled disconnect before the worker picks up the job (token-level acceptance resumes); cancel returns 409 once the purge has started. Customers needing a custom grace window or pre-scheduled erasure write to privacy@mycelium-ai.co and an operator coordinates the change.
Disconnect at the connector level does not touch other connectors. Deleting the account revokes access across every connector immediately. Full content erasure then runs per connector through the Phase 2 purge described above; a single account-wide hard-delete call is in-progress work, not yet shipped.
The implementing endpoints are POST /admin/connectors/{tenant_id}/{source}/disconnect (schedule), GET /admin/connectors/{tenant_id}/{source}/disconnect (status), and DELETE /admin/connectors/{tenant_id}/{source}/disconnect (cancel-while-scheduled). The source code lives in the open runtime at src/connectors/disconnect.py + src/connectors/worker.py; the full spec is at docs/api/admin-connectors.md. F100 procurement officers asking how Mycelium proves a deletion was honored can request a sample audit-log export of the canonical event sequence on a non-prod tenant.
3. Never used for training
What this means.Customer content is never used to train any AI model, ours or anyone else’s. This is contractual, not aspirational.
How we enforce it. The Terms of Service prohibit training on customer content. Mycelium does not currently train any model on customer data. When you use Hosted Pass-Through inference (an opt-in feature at Team and Enterprise), the upstream model provider (Anthropic, OpenAI, Google) operates under their enterprise contracts, which prohibit training on customer prompts. The default path is BYO inference (commitment #4 below), which keeps your content off any Mycelium-controlled inference endpoint.
4. BYO inference
What this means. Mycelium does not bundle inference cost. You bring your existing Claude Pro, ChatGPT Plus, Gemini, or API key. Your content never reaches a Mycelium-controlled inference endpoint unless your workspace explicitly opts into Hosted Pass-Through.
How we enforce it. The runtime ships with adapter-pattern model routing. Default routing sends inference calls through the BYO subscription you configure at install. Hosted Pass-Through is an opt-in tier-level feature with an explicit toggle in the admin UI. The adapter does not buffer prompts on Mycelium-side servers in the BYO path. The commercial reason matters: avoiding per-token resale is structural, not seasonal. See the Pricing section for the BYO commitment in plain copy.
5. Pause sync (one-click for sensitive periods)
What this means. A one-click toggle pauses connector ingestion across all sources without disconnecting them. Useful for litigation holds, M and A windows, internal investigations, or any period where you want the ingestion path closed temporarily.
How we enforce it. The pause toggle lives on the Connectors page. While paused, no new events are ingested, no embeddings are computed, no knowledge-graph updates fire. Existing data remains queryable. Resume re-enables ingestion from the resume point forward. Backfill of the paused window is opt-in per source.
6. Audit log at Team and Enterprise
What this means. At Team and Enterprise tiers, every search query and every AI invocation is logged with timestamp, actor identity, source IP, and the query payload. The workspace admin can export the log on demand.
How we enforce it. The append-only audit log lives at audit-log.jsonl per tenant. Workspace admins export the log via the admin endpoint. Retention defaults to 12 months at Team, extendable to 7 years at Enterprise for SOX or HIPAA-adjacent buyers. Audit exports are gzipped JSONL signed with a tenant key. Personal-tier accounts do not have an audit log because they do not have admins to audit; the log is a Team-and-up surface by design.
7. Personal layer private at Team
What this means. At the Team tier and above, every workspace member has a personal layer connected to their personal sources (personal Gmail, personal Notion, iMessage, etc.). The personal layer is private to that user. Workspace admins cannot search it. Other team members cannot see it. It does not feed the company brain.
How we enforce it.The runtime enforces a per-user privacy boundary at the storage and query layer. The personal layer lives under a per-user JWT scope; the company brain is a separate JWT scope. Cross-scope reads are denied at the auth layer. An integration test asserts that an admin token cannot read another user’s personal-layer paths. The departing-employee flow (covered in the IT-approval scoping guide below) exports the user’s personal-layer content to them within 7 days, then deletes it. The full access-control architecture ships at /security/rbac.
8. Third-party security audit and SOC 2 Type II in progress
What this means. Mycelium has commissioned a third-party security audit and is running a SOC 2 Type II observation period. Both ship before the first paying customer onboards.
How we enforce it. Vendor selection and audit kickoff are tracked under a sibling work item. The audit firm name and observation window appear in Audit statusbelow as they land. We do not claim “SOC 2 certified” until the SOC 2 Type II report is in hand. During the observation period, the badge reads “in progress.” The audit covers code review of the productized runtime, the marketing site, and the Studio app, plus penetration testing of mycelium-ai.co and the Studio app, plus review of connector OAuth flows, data-at-rest encryption, disconnect-equals-delete enforcement, and tenant-boundary enforcement.
Deployment isolation and tenancy
For Fortune 100 procurement readers and IT teams evaluating tenant boundary enforcement. Mycelium ships shared-tenant by default with logical isolation, and offers a single-tenant path for the highest-sensitivity workloads.
Shared-tenant (default for Personal, Team, and Enterprise tiers). Logical isolation via tenant ID plus Postgres row-level security plus a per-tenant audit log stream that never mixes entries across tenants. Tenant UUIDs are opaque identifiers (no inference from name patterns). Per-tenant rate limits and API key scoping. Cross-tenant reads are denied at the auth layer and an integration test asserts that a tenant-A token cannot read tenant-B paths. Personal layer privacy (commitment 7 above) holds inside shared-tenant deployments via per-user encryption keys.
Single-tenant on Hyperscale custom installs. Dedicated Fly app plus dedicated Postgres instance plus customer-controlled VPC peering on request. Available for the highest-sensitivity Fortune 100 deals where shared infrastructure is a procurement blocker regardless of compensating controls. Hyperscale is a custom-priced tier; mechanics on the pricing section as they get added.
HIPAA + BAA-ready. Risk assessment plus technical safeguards documented; BAA template available on request. Status row in the audit status table below tracks the Active-by date. HIPAA-adjacent buyers can run a shared-tenant deployment with BAA in place; the most regulated workloads route to single-tenant on Hyperscale.
Audit status
Current state of the third-party security audit and the SOC 2 Type II observation period. Updated as each milestone lands. Fortune 100 procurement should read the auditor name and the observation window directly off this row, not off a sales deck.
| Milestone | Status | Date |
|---|---|---|
| Third-party audit firm | Three-firm shortlist finalized. Engagement letter not yet signed. | Firm name published here on signature. |
| Compliance platform | Platform shortlist finalized. Not yet onboarded. | Platform name published here on contract. |
| Third-party audit kickoff | Pending vendor selection | Follows firm selection |
| SOC 2 Type II observation start | Pending platform onboarding | Follows platform contract |
| SOC 2 Type II certification | Not yet certified | Targeted 2027 |
We do not claim “SOC 2 certified” until the SOC 2 Type II report is in hand. During the observation period, the badge reads “in progress.” That distinction matters to procurement. We hold ourselves to it.
F100 procurement officers asking for the auditor name pre-signature: contact security@mycelium-ai.co and we share the three-firm shortlist and current status under NDA. The names land publicly here once the engagement letter signs.
IT-approval scoping guide for workspace admins
For workspace admins planning a Team or Enterprise install. Before you click “Connect” on a company Google Workspace, Slack, Notion, or similar OAuth flow, get IT and legal approval. This guide walks the standard path.
The reason this matters: admin-level OAuth to a company Google Workspace is real scope creep. You as the admin can click the consent screen, but does your IT and legal team actually have written authority for Mycelium to ingest all company email and Drive content the connector reaches? If the memo overpromises and the IT team waves it through, the IT approval becomes the privacy violation, not the enabler. This guide is built to avoid that.
Step 1. Review the scope
Read the eight trust commitments above. Decide which connectors you actually need at install. Be specific about which Slack channels, which Drive folders, and which Notion workspaces are included. The admin overrides on each connector let you tighten the default scope further.
Step 2. Draft the memo
Use the sample IT and legal memo template in Section 10 below. Fill in the company-specific blanks. Be honest about the scope you are requesting. Do not over-promise.
Step 3. Get written approval
Send the memo to your IT and legal contacts. Ask for written approval that covers (a) the connector scope, (b) the data-handling commitments, (c) any residency requirements, and (d) the audit-log retention window if you need a deviation from defaults. Do not click “Connect” in Mycelium until you have it.
Step 4. Document the approval
Save the approval thread or signed memo in your engagement-letter file with Mycelium. We can reference it in the contractual MSA or DPA as the scope authorization document.
Step 5. Install and audit
Complete the OAuth flow. The audit log starts logging immediately. Track support tickets for IT or legal objections that arise post-install. We iterate the scoping guide based on real objections, not hypothetical ones.
Sample IT and legal memo template
A copy-paste template you can hand to your IT and legal teams. Fill in the [BRACKETS] with your company specifics. The template is published under the same terms as the rest of mycelium-ai.co; you are free to copy, modify, and use it for your internal approval process.
Download IT and legal memo template (Markdown)
The template covers: executive summary, connectors proposed, what gets ingested per connector, what gets skipped per connector, encryption surface, the eight trust commitments, audit status, subprocessor list, data residency, DPA reference, departing-employee flow, questions to ask Mycelium in writing, and recommended next steps for IT and legal.
Spanish-language version: Descargar plantilla de memo de IT y legal (Markdown).
Role-based access control inside your tenant
Mycelium ships folder-glob role-based access control inside every tenant. Each JWT carries a roles claim. Every vault-touching route resolves the role-set against the target path before reading or writing. Denials produce structured audit-log entries.
This is the Phase 4 deliverable on the SOC 2 CC6.1 control path. The full documentation, including the default 10-role library, the admin API surface, webhook denial behavior, backward-compatibility behavior, and the operational caveats most pages hide, lives at /security/rbac.
Vulnerability disclosure
Mycelium runs a coordinated disclosure program. Researchers who report vulnerabilities in good faith and in line with the rules below are acknowledged in our public CHANGELOG and credited in any related security advisory.
Reporting
Send vulnerability reports to security@mycelium-ai.co. Encrypted submissions are welcome; PGP key fingerprint available on request.
Please include:
- A clear, reproducible description of the issue
- The affected URL, endpoint, version, or component
- Proof-of-concept output or steps that demonstrate the impact
- Your preferred name for credit (or a request to remain anonymous)
Response timeline
- Acknowledgement within one business day
- Initial triage and severity assessment within five business days
- Remediation plan and target date within fifteen business days
- Public disclosure window: ninety days from initial report, or sooner if a fix has shipped and the customer base has been notified, whichever comes first
Scope
In scope:
- mycelium-ai.co and all subdomains operated by Mycelium
- The open-source memory layer at github.com/mycelium-hq/ai-brain-starter
- The productized runtime endpoints exposed to customers under engagement letter (subject to the safe-harbor section below)
Out of scope:
- Third-party services (Vercel infrastructure, Resend, PostHog, Anthropic, OpenAI, etc.). Please report to the vendor directly.
- Social engineering of Mycelium employees, contractors, or pilot customers
- Physical attacks on Mycelium offices or hardware
- Denial-of-service or rate-limit testing without prior written authorization
Safe harbor
Research conducted in line with this policy is considered authorized and Mycelium will not pursue civil action or report it to law enforcement. Researchers must avoid accessing or modifying customer data, must stop testing immediately on request, and must give Mycelium reasonable time to remediate before public disclosure.
Recognition
Researchers who follow this policy and submit valid vulnerability reports are acknowledged in the public CHANGELOG and (with the researcher’s consent) in any published security advisory. Cash bounties are not currently offered; we expect to launch a paid program after the SOC 2 Type II audit completes.
Privacy and data subject inquiries
For privacy questions or data-subject requests under GDPR, UK GDPR, CCPA, or LGPD, write to privacy@mycelium-ai.co.
Mycelium · founded 2026