You own your data. Your agents run under credentials you control, inside boundaries you define.
Brainverse deploys agent teams into infrastructure you control, under credentials you hold, with isolation enforced by independent systems at three layers. You own the deployment on day one, including if we disappear tomorrow. Your prompts and outputs are not used to train Anthropic's foundation models, and Brainverse does not train, fine-tune, or aggregate on your data. This page is the artifact your security team reviews; every claim links to the mechanism, the contract, or the provider that backs it.
Running a small team? Read the first three sections and skip the rest. Everything after Section 3 is for IT and security reviewers.
The short version, in plain English.
You own the repo that holds your agent team, and you own the data that lives in it. Brainverse staff do not have standing access to client data. Operational access is per-incident, time-boxed, and logged on your provider's own audit trail. For engagements that require ongoing support, we hold scoped per-engagement credentials that you can revoke at any time from your own admin console. Your prompts and outputs are not used to train Anthropic's models, and Brainverse does not train any model of its own on your data. If any of this changes, we tell you before it changes.
The mechanism, the files, and the deployment modes.
Brainverse runs in four deployment modes: Brainverse-hosted, client-hosted, local-only, or hybrid. The three-layer isolation model (GitHub RBAC, filesystem with per-client submodules, optional Postgres Row-Level Security) is enforced by independent systems and fails closed at each layer. The full architecture, egress allowlists, and firewall compatibility live on the deployment modes page.
Threat model, compliance inheritance, honest scope.
Brainverse is not SOC 2 or ISO 27001 certified and does not publish a certification roadmap. Our posture is operational discipline layered on top of certified infrastructure (Anthropic for inference, GitHub for code, Railway for BrainSync), with a shared-responsibility matrix that shows exactly which party is accountable for each control. Threat model, hook architecture, and blast-radius analysis are documented in the FAQ.
How isolation actually works.
Most vendors describe isolation as a property of the product. We describe it as three independent mechanisms, each enforced by a different system, each failing closed on its own. If one layer fails, the other two still hold. None of the three layers depend on an agent's cooperation to remain effective, because an agent under adversarial prompting will follow whatever instructions reach the top of its context window.
Three layers, each enforced by a different system. Fail-closed by default.
Coarse-grained. 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.
Runtime. A Brainverse deployment uses a parent repo 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. This pattern is the recommended deployment for engagement-scoped delivery; Brainverse's own internal operation uses a simplified variant of the same pattern. The same isolation pattern can extend one level deeper inside a single client: a sub-team repo is gated by its own GitHub team under Layer 1, imports the shared agent-definitions repo as a submodule, and partitions memory under its own BrainSync project_id at Layer 3. The boundary is enforced by your GitHub organization's RBAC, not by Brainverse. See deployment modes for the configuration.
Fine-grained. Memory entries in the BrainSync Postgres database carry project_id and agent_id; every query routes through a Postgres role that is RLS-scoped to the bearer token's project. Cross-project reads are rejected at the row level, not at the application layer. Clients who do not use BrainSync do not have this layer, because their memory lives in their own git repo and is protected by Layers 1 and 2 only.
Each layer enforces independently of the others. A compromised OAuth token does not grant filesystem access. A compromised laptop does not grant database access, because the database still rejects a bearer token scoped to the wrong project. An insider who commits a malicious agent definition does not bypass the hooks, because the agent still runs inside the same harness, and every Write, Edit, and Bash call still passes through secret-check.cjs, memory-write-guard.cjs, config-protection.cjs, and no-verify-block.cjs. The layers are not redundant copies of the same check; they are different checks at different tiers, enforced by different systems that share no code.
Full threat model, blast-radius analysis, and technical questions in the FAQ →Mode A, Local-only.
The runtime lives on a practitioner's laptop. The agent team has no cloud footprint of its own; the only outbound traffic is Anthropic inference. Best fit for confidential or air-adjacent workflows where the only acceptable external dependency is the inference provider.
Mode B, Client-hosted.
The runtime lives in your AWS, Azure, or GCP environment. Your cloud, your IAM, your VPC, your egress allowlist. Brainverse operates inside the boundary you define; data does not traverse Brainverse-owned infrastructure.
Mode C, Brainverse-hosted.
your data lives on our infrastructure in this mode
BrainSync (dashboard and memory database) runs on Brainverse-operated Railway infrastructure. Client code and agent team live in the client GitHub organization. Fastest to deploy; shared-responsibility slice for data-at-rest shifts to Brainverse. Not compatible with HIPAA-regulated workflows; PHI-handling clients should select Mode A or Mode B.
Mode D, Hybrid.
Runtime in your cloud, dashboard and memory on Brainverse-hosted infrastructure. Useful when you want client-cloud runtime isolation but do not want to self-host the BrainSync dashboard.
Who is responsible for what.
The Shared Responsibility Matrix shows, row by row, which party is accountable for each security control: you, Brainverse, Anthropic, GitHub, or Railway. Credential rotation, data-at-rest encryption, prompt content review, offboarding revocation, audit log retention, and every other control your IT team is likely to ask about appear as a single row with a single primary-responsible party.
This is the document a CISO is most likely to forward internally. It is a one-page PDF, designed so that a security reviewer can mark it up, paste rows into a vendor-risk workbook, and move on. Download below.
Download the Shared Responsibility Matrix (PDF, 1 page)Our compliance posture.
If your team is under 25 people and doesn't have a dedicated InfoSec function, this section is mostly context. The short version is in the hero and the honest limits table. Read on if your procurement process requires formal compliance posture.
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 itself does not hold SOC 2, ISO 27001, or any formal certification. Our posture is operational discipline layered on top of certified infrastructure, with clear shared-responsibility allocation between Brainverse, your team, and the providers we run on.
- Anthropic:SOC 2 Type II, ISO 27001. See their trust center
- GitHub Enterprise:SOC 1/2 Type II, ISO 27001, FedRAMP. See their trust center
- Railway:SOC 2 Type II. See their trust center
While Brainverse does not hold a formal certification, the following audit-grade artifacts are available under NDA during procurement:
- Git commit history of every agent definition and hook change.
- BrainSync session exports covering the retention period for your tier.
- Internal Red Team Challenger verdicts on every public security claim.
- Hook-health telemetry demonstrating the crash-blocks-operation invariant.
- `/qa` pipeline verdicts on every release.
Request the evidence package at [email protected].
Why Brainverse is not certified
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.
Can I use sensitive business data with Brainverse?
Yes — and that is exactly what Brainverse is designed for. Your real workflows involve real data: internal documents, client records, proprietary processes. A system that could only handle sanitized information would not solve your actual problems. The architecture is built so that sensitive data stays within your control, and the setup is designed to earn your IT team's sign-off before you go live.
Your Brainverse deployment runs in a repo your organization controls, under an identity provider your organization operates, with an inference endpoint that either sits on your team's Anthropic account or on Brainverse's (your choice at kickoff). The three-layer isolation model ensures agents cannot read data they were not explicitly granted access to, and the hook chain prevents agents from writing credentials, running destructive commands, or exfiltrating data through outbound message bodies. You hold the revocation paths at every layer.
- Paste your own team's workflow notes, meeting summaries, internal documents, and confidential process documentation into agents deployed for your engagement.
- Ask agents to read, summarize, and act on repositories and documents your organization already has legitimate access to.
- Use the agent team for any workflow your existing IT policy allows you to do with a GitHub Copilot, ChatGPT Enterprise, or Claude for Work license.
- Do not paste third-party confidential material (another client's data, another vendor's confidential source) that your organization has not been authorized to process.
- Do not upload personally identifying information for individuals who have not been informed their data will be processed by an AI agent team.
- Do not use a production agent deployment for a HIPAA-regulated workflow unless your engagement is explicitly scoped to Mode A or Mode B with the relevant BAA in place.
If your IT or security team wants a reference document before they sign off, the "What IT needs to see" one-pager in Card B above is written for them. Most teams complete their review in one meeting.
| What we do NOT claim | What we admit | What that means for a small team |
|---|---|---|
| SOC 2 Type II, ISO 27001, or any formal certification for Brainverse itself | We are not certified and we do not operate a certification roadmap | If your procurement requires a Brainverse-level certification, we are not your vendor today. The data lives on certified providers regardless. |
| "No admin backdoor" as an absolute architectural claim | Brainverse staff hold scoped credentials (PATs, project tokens) for active engagements, as required to deliver and support the work | Access is per-engagement, logged in the provider's audit trail, and revocable by you at any time from the provider's own admin console. There is no Brainverse-side unified access log today. |
| Prompt injection is a solved problem | Prompt injection is not solved in the field; our defense is layered, not absolute. The hook chain blocks credential writes, destructive bash, and config tampering. Data-interpretation prompting within an agent's authorized scope is a mitigation, not a boundary. | Agents can still be misled by data they are entitled to read. Treat agent output as advisory on sensitive decisions until you have verified the underlying source. |
| 24x7 SOC monitoring or dedicated incident response team | We target 72-hour notification for confirmed incidents affecting client data. Specific SLAs (acknowledgment time, resolution cadence) are available at the Enterprise tier and are set in the Order Form. | Foundation and Team tiers operate on best-effort incident response. If you need a contractual acknowledgment-time SLA, ask about Enterprise. |
| A unified cross-provider access log for every Brainverse staff action | Each provider we touch (GitHub, Railway, Anthropic) keeps its own audit log. We do not aggregate them into one Brainverse-side view. | You can pull a full access log for any client-hosted resource from the provider directly; you do not need Brainverse cooperation to do so. |
| Automated cross-service offboarding within a fixed SLA | Offboarding is a documented checklist today, not an automated workflow. Each revocation (GitHub PAT, Anthropic key, BrainSync token, OAuth grants) typically takes seconds on the relevant admin console. | You can revoke our access from your side without waiting for us. Four independent revocation paths, any one of them stops the corresponding capability. |
| Cryptographically signed, tamper-evident audit events | Session metadata is stored in Postgres over TLS. Events are not HMAC-signed today. | For evidence workflows that require tamper-evidence, the provider-side audit log (GitHub, Railway) is a stronger source than our session table. |
| PII scrubbing at the memory layer for SSN, DOB, or account-number patterns | The push hook scans for credential and secret patterns before memory entries reach the database. It does not scrub general PII categories today. | If your workflow routinely processes regulated PII, talk to us about a custom scrubbing pattern or stay in Mode A or Mode B where memory lives in your own infrastructure. |
| Agents run in a fully-locked sandbox by default | Brainverse internal development uses the `--dangerously-skip-permissions` flag for velocity; the client template does not inherit this flag. Enabling it for a client engagement requires explicit written approval, per operator, per engagement, with documentation in the security evidence folder. | Your agents run under Claude Code's default sandbox. Brainverse only raises permissions with your explicit approval. |
Frequently asked questions.
Are you SOC 2 certified?
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.
Is our data used to train any model?
Your prompts and outputs are not used to train Anthropic's foundation models. Anthropic's commercial API terms prohibit training on customer inputs or outputs by default, and Brainverse's managed-mode deployments run with Zero Data Retention enabled on our Anthropic account. Brainverse does not train, fine-tune, or aggregate on your data. If you deploy in Mode A or Mode B with your own Anthropic key, you configure Zero Data Retention on your own workspace; we verify it before go-live and record the verification in the engagement's security evidence folder.
See full training-data answerCan you sign a BAA?
HIPAA BAAs are available case-by-case as a custom Enterprise addendum. Brainverse is not a productized HIPAA vendor. If you are a HIPAA-covered entity and your workflow requires a BAA, we scope it with you as part of the Enterprise contract, and your deployment runs in Mode A or Mode B under the client's BAA with the inference provider. If your workflow does not touch PHI, no BAA is required.
See full HIPAA / BAA answerWhat happens if a Brainverse staff laptop is compromised?
Every client that staff member was provisioned for becomes part of the blast radius until the affected credentials are revoked. Mitigation: full-disk encryption on staff devices, hardware-assisted OS authentication, and contractual commitment to notify every affected client within our 72-hour incident target. Revocation does not require Brainverse cooperation; each client can revoke Brainverse-held credentials from their own provider admin console.
See full laptop-compromise answerWhat controls do you actually enforce yourself?
At the tool-call layer, a chain of PreToolUse hooks blocks credential writes, destructive bash commands, weakening of the linter/formatter/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.
See hook-architecture answerWhat exactly runs inside our firewall when the installer executes?
The installer is a thin shell script that calls public vendor installers from Apple, Microsoft, GitHub, the Node.js Foundation, and Anthropic. Every download URL, install destination, and verification step is documented on the Installer Transparency page. No telemetry to Brainverse, no kernel extensions, no auto-launch daemons, no remote code execution after install completes. The only Brainverse-specific code that gets pulled is the customized agent repository, which lives in a GitHub organization the client owns.
See full installer-transparency pageTalk through it.
30 minutes with Jeff Leggett. No prep, no security-reviewer vocabulary required.
Book the callSend it to your team.
A forwardable one-page PDF with everything an IT lead needs to decide on a Brainverse engagement.
Download the PDFRead the FAQ.
Threat model, blast-radius analysis, hook architecture, and the 20+ most common security-review questions, grouped for skim and depth.
Open the security FAQ- Security questions, privacy requests, or anything not covered on this page:[email protected]
Last updated 2026-04-27.