1. Overview
LabFrame is an agentic AI platform for research teams. The hosted service combines a control-plane web application, a PostgreSQL database, and per-agent isolated virtual machines that run user workloads independently.
Our security priorities are customer data isolation, secret handling, lifecycle control for agent VMs, and disciplined deployment and rollback procedures.
2. Architecture and isolation
- Each agent runs in its own isolated VM rather than in a shared long-lived application process.
- Platform data such as users, billing state, agent metadata, and session records live in PostgreSQL behind the control plane.
- Internal VM callbacks are authenticated with bootstrap and VM tokens, and token use is tied to VM lifecycle state and token generation.
- Runtime health and control-plane connectivity are tracked separately so recovery can distinguish VM boot problems from credential or API reachability failures.
3. Authentication and access
- LabFrame supports Google sign-in, email magic links, or both, depending on the deployment configuration.
- Application sessions use HTTP-only cookies, CSRF checks on protected routes, and a server-side Postgres-backed session store in non-test environments.
- Auth-sensitive routes use rate limiting to reduce abuse of login, callback, and magic-link verification flows.
- Agent and conversation access is enforced through route-level ACL checks and database-level isolation controls.
4. Data handling
- Data is encrypted in transit with TLS and stored on managed cloud infrastructure.
- Payment card information is processed by Stripe. LabFrame does not store full raw card numbers.
- AI prompts and relevant workspace context are sent to the configured model providers needed to serve user requests.
- Workspace retention and deletion behavior is described in the Privacy Policy. Customers that need a separate DPA or vendor security review can contact us.
5. Operations and deployment
- Production deploys are explicit and include health checks, smoke tests, and rollback procedures.
- Deploys enter a drain mode before switching releases so new chat turns are rejected with retry semantics while the system quiesces.
- Billing controls can stop new chats, wakes, and goal starts when a workspace lacks a plan or runs out of credits.
- Backup, restore, and incident-response procedures are tracked internally in repository runbooks.
6. Subprocessors
The hosted service relies on the following infrastructure and service providers:
| Provider | Purpose | Typical data involved |
|---|---|---|
| Google Cloud Platform | Application hosting, agent VMs, and managed storage | Account metadata, workspace data, service logs |
| Stripe | Subscriptions, top-ups, customer billing portal | Billing identifiers and payment metadata |
| AWS Bedrock / Anthropic | Claude-family model inference | Prompts and relevant user-provided context |
| Google Gemini | Gemini model inference | Prompts and relevant user-provided context |
| OpenAI | GPT-family model inference when enabled | Prompts and relevant user-provided context |
| Brave Search | Web search results for agent tool calls | Search queries submitted by user-directed agents |
| SendGrid | Email delivery for magic-link sign-in when enabled | Email addresses and transactional auth email content |
7. Security reporting
If you believe you have found a security issue in LabFrame, please report it privately to contact@labframe.ai. Include the affected URL or component, reproduction steps, and any relevant logs or screenshots.
Please do not publicly disclose vulnerabilities before we have a reasonable opportunity to investigate and remediate them.
8. Contact
Security reviews, vendor questionnaires, and commercial support requests can be sent to contact@labframe.ai.