The one-sentence summary.

What you control

• The database. A database you provision, with credentials only your team holds. OpenBean writes through a per-deployment system credential you rotate.
• The application. A web app and an AI-connection server you deploy, on infrastructure you choose (VPS, on-premise, Vercel + hosted database, fully air-gapped).
• The credentials. The API keys your AI tools use, the per-member sign-in credentials, the system-level credential for the engine, and the rotation cadence for all of the above.
• The audit log. The knowledge log is append-only, enforced by a database rule, not by application code. The rule cannot be bypassed by any code path through the engine.
• The compliance posture. The compliance posture of your OpenBean deployment is the compliance posture of your infrastructure, not the posture of OpenBean the project.

What OpenBean the project does

• The engine. MIT-licensed source. The same source the maintainer team ships is the source that runs in your instance.
• The governance gate. A write gate in front of every change: route → classify → plan. Every change is classified by structural type before it is stored.
• The high-stakes approval queue. Configurable approval rules: which categories are always held for a person to approve, which accumulate versus replace, and the confidence line below which a change is set aside for review.
• The per-company wall. Database-level isolation between companies, enforced at the database layer, not by application filtering.
• The adversarial test suite. 40+ checks, required status check on every change, including a forged-credential attempt, a cross-company read attempt, and a system-bypass attempt.

What the project does not do

• The project does not run a cloud service that holds a copy of your data.
• The project does not phone home, telemetry, or analytics from your instance.
• The project does not bundle a proprietary tier, a paid add-on, or a feature that lives in a separate, source-inaccessible repository.
• The project does not provide a hosted or managed deployment. Self-hosting is the design, not an option.

Threat model

• An AI tool overreaches its scope. A per-connection identity (local) or a hashed, revocable API key checked on every request (remote). Revocation takes effect on the very next request, on every access path.
• A change is written without a human’s review. The high-stakes category list (pricing, contract terms, deployment targets, API key references, customer commitments) is held for review. The reviewer is a human with the right role, verified server-side on every request.
• A change is mutated or deleted after the fact. Append-only by a database rule. The rule is on the table itself; the engine has no UPDATE or DELETE permission against it.
• One company’s data is visible to another. Per-company isolation at the database layer. The wall is verified by an adversarial test that uses a forged credential, on every change.
• A forged credential is accepted. Cryptographically signed, expiry-verified, constant-time- compared. A forged credential is rejected before any other check runs.
• A member’s identity is fabricated. The session’s company identity is only ever minted from a verified membership row. A session credential alone is not sufficient.
• A bug in application code bypasses the gate. The gate runs in the same transaction as the change. A failed gate is a rolled-back transaction, not a logged failure.

Compliance posture

OpenBean is an MIT-licensed engine operated by your engineering team on your infrastructure. The compliance posture of your OpenBean deployment is the compliance posture of your infrastructure.

For a SOC 2 / HIPAA / ISO 27001 attestation, the third-party attestation is yours to commission on your own deployment. The Professional Services catalog has a Security Review that walks your team’s security questionnaire against OpenBean’s documented properties. The review is a written memo, not a certification.

Disclosures

• Public security advisories. SECURITY.md in the public openbean-docs repository.
• Vulnerability reporting. SECURITY.md in the public openbean-docs repository. The maintainer team responds within one business day to a private report.
• Known limitations. A named Known Limitations document — every limitation named, with a workaround and a target iteration — is shared with every evaluating team. Ask for it via contact.
• Roadmap for security work. Named in each iteration’s completion report, shared with evaluating teams alongside the Known Limitations document.

Sources (verify the claims)

• Architecture one-pager
• Deployment guides
• Engine spec, AI identity lifecycle, and the adversarial acceptance suite — shared in source form with evaluating teams under the evaluation program.
• Professional Services — Security Review