Enterprise FAQ
The landing page’s FAQ is for a visitor deciding whether to read further. This FAQ is for a security reviewer, procurement lead, or enterprise architect who has decided to read further and now has specific, named questions. Each answer points at the canonical public document so you can verify it against the source.
What a security reviewer needs.
The engine is MIT-licensed, and every evaluating and customer team receives the full source. No feature is gated behind a proprietary tier; the source the maintainer team ships is the source that runs in your instance.
By Postgres row-level security policies on the `claims` table, enforced at the database layer rather than by application filtering. The same RLS wall protects the `tenant_users`, `scope_grants`, and `ai_identities` tables. The adversarial acceptance suite verifies the wall on every PR with a forged JWT — see CHECK 5b, 5c, 6, 8.
Two ways. Local connections use the engine's service-role key, scoped by a per-connection `OPENBEAN_PRINCIPAL` value. Remote connections use a hashed, revocable API key checked on every request, against a `kind='service'` row in `ai_identities`. Revocation takes effect on the very next request, on every access path — not just on writes.
All of it. The engine, the governance gate, the RLS policies, and the MCP protocol implementation are MIT-licensed and provided in full to your security team as part of an evaluation. Every invariant is verified by the adversarial acceptance suite on every PR; the CHECK numbers are part of the documentation.
OpenBean is an MIT-licensed engine run by your own engineering team on your own infrastructure — the compliance posture is your deployment's, not OpenBean the project's. The Professional Services catalog has a Security Review service (see the Services page) that walks your team's security questionnaire against OpenBean's documented properties; a third-party SOC 2 / HIPAA / ISO 27001 attestation is the customer's responsibility to commission separately.
Every structural invariant the engine makes: append-only integrity, scope isolation, tenant isolation, the trust root (session tenant minted only from verified membership), the materialized-view leak seal, the gate's branch logic, the tenant-stamping trigger, and the revocation enforcement. 40+ checks, run on every PR against a real Postgres stack. The CHECK numbers are part of the architecture overview.
No. AI connections are structurally incapable of governance actions because they have no `tenant_users` row — `getRole()` returns null, and `canApprove(null)` is false. Approving or retracting a claim is a role-gated human act (owner or admin only), checked server-side on every request. This is enforced by construction, not by an added permission check.
What a platform engineer or SRE needs.
Six targets are documented in the deployment guides: local development (Windows, macOS, Ubuntu WSL), fresh Ubuntu 24.04 VPS, Vercel + hosted Supabase, self-managed Postgres on a VPS or VM, dedicated server / on-prem Kubernetes, and fully on-premise / air-gapped. Local development and Vercel + hosted Supabase are Verified — exercised against a real host by the maintainer team. The remaining four are Designed — the procedure is correct against the application's interfaces, but the maintainer team has not yet run the procedure on a real host of that shape. Each Designed target names the verification gap explicitly in the guide.
No — self-hosting is the design, not a deployment option. Your company's knowledge lives on infrastructure you control, full stop. What OpenBean does operate is a small control plane (openbean cloud) for licensing, downloads, and support — it never holds your company's memory. Organizations that don't want to run the instance alone can buy hands-on help through Professional Services (Deployment Support, Support agreements), which keeps operations in your hands with our engineers alongside.
Architecturally, yes — nothing in the design is tied to a specific cloud vendor. Today's fully documented and tested path is the application plus a Postgres database you provision and hold the credentials to. A from-scratch, zero-external-dependency deployment guide is designed in the deployment guides; the maintainer team has not yet exercised it on a real air-gapped host, and the Professional Services Deployment Support or On-Premise Deployment engagements are the right shape for an organization that wants hands-on help standing one up.
Nothing happens to it — it was never on our infrastructure, and your database, application deployment, and credentials keep working exactly as they do today. The engine is MIT-licensed source you can fork and run as-is, with or without the maintainer team. Reading, searching, and exporting your knowledge never depends on us being reachable — not even on a license.
Three pieces, all in the engine today: `npm run backup` produces a single archive of the entire instance (memory, accounts, connections, secrets); `npm run restore -- <archive>` restores it (prompts before overwriting; verified by drill on real data, not a unit test); `npm run doctor` runs eight health checks, each failure paired with its cause and the exact recovery command. Recovery is a documented, exercised path, not a sketch on a roadmap.
For the local development path: `npm install && npx supabase migration up --workdir packages/engine --local && npm run dev:up`. For the Vercel + hosted Supabase path: `git push` to the tracked branch (which triggers Vercel's build), then `npx supabase db push --workdir packages/engine` for any new migrations. The `migration up` / `db push` step is the easy-to-miss one and the documentation repeats it deliberately: it applies any new migrations from the pulled code, and skipping it leaves the database schema behind the code.
What a product owner or governance lead needs.
Any client that speaks the Model Context Protocol. Verified directly with Claude Code and Cursor. The protocol is open, so this list is not a gate — a vendor's cooperation is not required to participate.
An SDK and a CLI are planned (Phase C of the roadmap) and are not yet built. The engine's compiled exports are usable as a library today (`openbean`, `openbean/gate`, `openbean/mcp/*`), and the `npm run mcp` script exposes the engine's seven MCP tools over stdio for local use. The Professional Services Migration Assessment is the right engagement for an organization that wants a real, typed client for an integration today.
The gate is configuration, not hardcoded exceptions. The `config` table holds `HIGH_STAKES` predicates (which always wait for a human), `ACCUMULATE` predicates (which pile up rather than supersede), `SUPERSEDE_ON_RERUN` predicates (which auto-replace on a new value), the decay rate, and the trust floor. The Organization page in the product renders the live `config` as a read-only Policies card. Editing the policy today is a database operation, not a UI button — this is a deliberate constraint, because `config` is one instance-wide table, not tenant-scoped, and a browser edit here would silently change governance for every organization sharing the instance.
The gate routes it to `pending_review` regardless of how trusted the writer is. A human owner or admin reviews it from the Review page, with the proposer's identity, the confidence, the gate's reasoning, and the full provenance visible. The reviewer can approve, decline, correct, merge, or escalate. A correction re-enters review (philosophically right; may need explanation in-product). A merge keeps one and declines the other in a single decision.
No. The append-only trigger is the last line of defense, and it is a database trigger, not application code. 'Removing' a fact is always an append: a retraction or a correction is a new row that supersedes the old one. The full claim chain remains intact, with the retraction's reason. This is the same property that makes the audit trail trustworthy.
What a procurement lead or executive sponsor needs.
The engine is free and MIT-licensed. There is no per-seat, per-instance, or per-claim charge. Professional Services engagements are scoped and priced per the catalog; conversations that don't fit a catalog shape are answered in writing. Pricing is deliberately not on the public page; a templated number produces a templated engagement, and OpenBean would rather scope an engagement to your deployment than publish a number that does not match any real one.
Yes. The Support service (see the Services page) is a named, time-bounded engagement with named response-time targets (Severity 1: 1-hour response, 4-hour mitigation; Severity 2: 4-hour response, 1-business-day mitigation; Severity 3: 1-business-day response), a quarterly review, and a written incident report for every Severity 1. The Pilot Program service is the right engagement for an organization that wants a structured pilot before committing to a production deployment.
Yes, for the Architecture Review, Security Review, Migration Assessment, and Health Check services, before the engagement starts. The NDA is the customer's standard form where possible; the maintainer team has a form it can offer when the customer does not.
No. Self-hosting is the design: your organization's knowledge lives only on infrastructure you control. What exists instead is hands-on help — the Professional Services Deployment Support and On-Premise Deployment engagements walk your own engineers through standing up and operating a self-hosted instance, and a Support agreement keeps our engineers reachable afterward.
Licenses belong to your organization, not to individual users — there is no per-seat price and no usage metering. An evaluation license is free, runs 30 days, and restricts nothing: install, activate, connect your AI tools, invite the team, capture and recall at full capability. When it expires (after a 7-day grace window), the deployment becomes read-only: everything already captured stays readable, searchable, and exportable, and nothing is ever deleted. Activating a purchased license on the same deployment restores full functionality immediately — no reinstall, no migration.
Yes. A license is a signed file bound to your deployment. You can download it from the portal on any machine and paste it into your server — the server verifies it locally against a pinned public key and never needs to call us. There is no phone-home requirement: an OpenBean deployment keeps working with zero network access to OpenBean the company.
Didn’t find your question? Use the structured intake to ask it directly.
Ask the maintainer team