Security FAQ.

No. Brainverse does not hold SOC 2, ISO 27001, or any formal security certification. The infrastructure Brainverse runs on (Anthropic for inference, GitHub for code, Railway for BrainSync) is certified. Our shared responsibility matrix shows which party is accountable for each control. We do not publish a Brainverse certification roadmap.

None that are Brainverse-owned. Brainverse runs on certified infrastructure. Anthropic maintains SOC 2 Type II and ISO 27001. GitHub Enterprise maintains SOC 1/2 Type II, ISO 27001, and FedRAMP. Railway maintains SOC 2 Type II. Each provider publishes their current certifications at their own trust center; links are in our shared responsibility matrix. Brainverse's own posture is operational discipline layered on top of certified infrastructure, with a clear shared-responsibility allocation between Brainverse, your team, and the providers we run on.

Brainverse is a small team. A certification program at our size would cost more than it would signal. Rather than pursue certifications we would have to stretch to afford and renew, we built on certified infrastructure, we published our architecture in plain language, and we gave you the shared-responsibility matrix so you can see exactly what each party is accountable for. If your procurement process requires a certified vendor for the party holding the data, the data itself lives on certified infrastructure you control (your GitHub organization, Anthropic under a direct or Bedrock relationship). If your procurement process requires a certified vendor for Brainverse specifically, we are not the right fit today.

HIPAA BAAs are available case-by-case as a custom Enterprise addendum. We are not a productized HIPAA vendor. If you are a HIPAA-covered entity and your workflow requires a BAA, we can scope one with you as part of the Enterprise contract, and your deployment runs in Mode A or Mode B under your own BAA with the inference provider. If your workflow is not HIPAA-covered or does not touch PHI, no BAA is required. Mode C is not compatible with HIPAA-regulated workflows.

Brainverse operates as a data processor on behalf of the client, who is the data controller, for personal data processed through Brainverse services. For data subject rights requests (Articles 15-22), email [email protected] and we will respond within the required timeframe. If your workflow requires a formal Data Processing Addendum, talk to us as part of the Enterprise contract.

Brainverse does not train, fine-tune, or aggregate on your data. Brainverse does not operate or train foundation models. Your prompts and outputs are not used to train Anthropic's foundation models; Anthropic's commercial API terms describe Anthropic's data-use policy, and for clients who want the strongest posture available we configure Zero Data Retention on the Anthropic endpoint (available directly from Anthropic or through Bedrock or Azure OpenAI). Training-data protection is a policy of the LLM provider you contract with (directly or through us), not a Brainverse-level guarantee for models we do not operate.

That depends on the deployment mode you select. Your source code and agent team always live in your GitHub organization. In Mode A (Local-only), everything else lives on the practitioner's laptop. In Mode B (Client-hosted), BrainSync memory and runtime live in your AWS, Azure, or GCP environment under your IAM. In Mode C (Brainverse-hosted), BrainSync lives on Brainverse-operated Railway infrastructure. In Mode D (Hybrid), runtime data lives at the runtime tier (local or your cloud) and only session metadata and audit events cross to Brainverse.

Fully air-gapped deployment is not supported because inference requires network access to Anthropic, AWS Bedrock, or Azure OpenAI. Air-gapped-adjacent deployment is supported: the laptop or runtime talks only to a single endpoint on a private network, which then forwards to the inference provider. We provide a reference implementation using a client-hosted proxy that forwards only the inference call and blocks everything else.

Yes. Mode B (Client-hosted) is designed for clients with existing AWS, Azure, or GCP standardization. Your cloud, your IAM, your VPC, your egress policy. Brainverse operates inside the boundary you define; data does not traverse Brainverse-owned infrastructure. Terraform, Bicep, and Deployment Manager modules are in active development; for engagements that need them today, we deliver customized infrastructure-as-code during the engagement.

Yes. You can bring your own Anthropic key (or Bedrock or Azure OpenAI routing) in any mode except the default configuration of Mode C. We verify Zero Data Retention configuration on your workspace before go-live and record the verification in the engagement's security evidence folder.

For confirmed security incidents affecting client data, Brainverse targets notification within 72 hours of our confirmation, consistent with the processor-to-controller expectation in GDPR Article 33. Notification is sent by email to the designated security contact. For incidents where the impact is indeterminate, we provide a status update within the same window and continue to update until the impact is resolved. Contractual incident-response SLAs (specific acknowledgment, initial-analysis, and root-cause time commitments) are available at Enterprise tier and are negotiated per engagement. Foundation and Team tiers operate on best-effort incident response.

We log session-level metadata: who dispatched the agent, when, which agents ran, token usage, cost, and outcome. Tool-by-tool call records live in the Claude Code local JSONL transcript on the machine where the agent ran, which is exportable but not automatically shipped to the server. In Mode B and Mode C you can query the BrainSync session history via the REST API. In Mode A, session history is in the local .brainsync-sessions.json plus the JSONL transcript. Memory changes are version-tracked by content hash.

Four independent revocation paths. Revoke the GitHub PAT (or remove the user from the organization). Revoke the Anthropic API key in the console. Revoke the BrainSync bearer token on the BrainSync server. Revoke the MCP OAuth grants in your Google Workspace admin or GoHighLevel admin console. Any one of the four stops the corresponding agent capability. Each revocation takes under 30 seconds on the relevant provider's admin console and does not require Brainverse cooperation.

Five PreToolUse hooks block credential writes, destructive bash, memory corruption, config weakening, and outbound credential exfiltration via covered MCP integrations. Four of the hooks are designed so that a crash in the hook itself blocks the operation rather than allowing it. Memory entries being pushed to the database are scanned for prompt-injection patterns at push time. Data-interpretation prompting within an agent's authorized scope is a mitigation, not a boundary; scope-minimization of agent inputs is the first design principle.

Your deployment is your property. The agents, the customization, the memory, and the repo are yours. Our agreement includes a change-of-control provision: if Brainverse is acquired, you receive written notice, continuity of service under existing terms for a minimum window, the right to terminate for convenience with a pro-rata refund, and because your team is running in your repo on your infrastructure, you keep operating either way. Specific windows and refund terms are in the applicable Order Form.

Your deployment keeps running. Agents live in your repository on your infrastructure; a Brainverse shutdown does not shut off your agents. For the managed tier where we host, a wind-down clause in the Enterprise Order Form grants you ownership of the deployment and a defined period of operational runbook access. You are not bankrupt-locked-in.

No, by design. Agents inherit the calling user's permissions via per-user OAuth on integrations that support it (Gmail, Google Drive, Google Calendar), and per-installation tokens scoped to the minimum privileges on integrations that do not. No agent shares a service account that grants broader scope than the user's own credentials. An agent acting on behalf of a non-admin cannot read what that non-admin cannot read in the underlying system (Google Workspace, your database, your CRM). Tool-call boundaries are checked against the user's scope on every call, not once at agent startup.

At the tool-call layer, a chain of PreToolUse hooks blocks credential writes, destructive bash commands, weakening of the linter or formatter or settings configuration, and the --no-verify escape on git commits. Four of these hooks are designed so that a crash in the hook itself blocks the operation rather than allowing it. The hooks share no code with the BrainSync memory layer, which means a refactor on the memory side cannot regress the security side. The hook chain order is declarative in .claude/settings.json; an auditor can read the settings file and predict the security behavior without running any code.

Scoped by design. A compromised Brainverse staff laptop reaches only the clients that staff member was provisioned for, and only the credentials that staff member holds. There is no Brainverse-wide master key. A compromised GitHub personal access token reaches only the repositories the token was scoped to; the token cannot clone repositories it was not explicitly granted. A compromised Anthropic API key reaches only inference on that key's account. A compromised BrainSync bearer token reaches only memory entries in the project the token was issued for; cross-project reads are rejected at the Postgres row-level. A compromised MCP OAuth grant (Gmail, Drive, Google Calendar) reaches only the user's own Workspace, scoped to the minimum permissions requested. Every compromise scenario ends at a boundary enforced by the underlying provider, not by Brainverse policy.

Three independent mechanisms, each enforced by a different system, each failing closed on its own. Layer 1 (GitHub repo RBAC): a personal access token that is not a member of the client's GitHub organization cannot clone the repo; GitHub's auth layer returns 404 before any Brainverse code runs. Layer 2 (Filesystem with per-client submodules): an agent attempting to read a submodule its token was not granted hits ENOENT on the filesystem, not a policy check. Layer 3 (Postgres Row-Level Security on BrainSync, optional): memory entries carry project_id and agent_id; every query routes through a Postgres role that is RLS-scoped to the bearer token's project. If one layer fails, the other two still hold; none of the three depend on an agent's cooperation.

Yes, with the boundary enforced by your GitHub organization's RBAC and your BrainSync project tokens. The pattern is one shared agent-definitions repo (granted to whatever audience your org chooses) plus per-team scoped repos with their own GitHub team ACLs. Each scoped repo includes the shared roster as a git submodule, so the sub-team runs the same agent set against their own data without a fork. Users without team membership and without inherited org-admin scope receive a 404 from GitHub on clone — by Layer 1, before any Brainverse code runs. BrainSync partitions memory and dashboards by project_id at the Postgres row level (Layer 3); a query authenticated under one project's bearer token does not return rows tagged with a different project's ID.

This pattern is a configuration of GitHub RBAC plus BrainSync project partitioning. It does not, on its own, qualify a deployment for HIPAA-regulated PHI, MNPI workflows, or jurisdiction-regulated personnel data — those require the engagement-level deployment-mode and contract scoping covered on the deployment-modes page.

What this is: workspace-level scoping enforced by your GitHub RBAC plus BrainSync project partitioning. What it is not: data-classification policy, attribute-based access control on the data itself, or an exception to the Brainverse-staff engagement-level access disclosed in the honest-limits table. Full mechanism, customer-side responsibilities, and regulatory carve-out are on the deployment-modes page.