# Trust Center — OpenAssistant OpenAssistant's security posture, compliance certifications, and policy documents — all in one place. OpenAssistant handles the data you connect — email messages and threads, calendars, contacts, files and documents, and messages on the platforms you link — on behalf of users and their organizations. This page summarizes our security and compliance program. Questions, or reporting a vulnerability? security@openassistant.us — monitored by our security team. ## Certifications & Compliance - **SOC 2 Type II** — Audited annually by an independent CPA firm. - **GDPR Compliant** — Data protection rights for EU residents. - **CCPA Compliant** — Privacy rights for California consumers. - **Encrypted in Transit & at Rest** — TLS 1.2+ in transit. AES-256 at rest. ## How We Protect Your Data - **Encryption** — All data encrypted in transit via TLS 1.2+ and at rest via AES-256. - **Access Controls** — Role-based access and least-privilege principles enforced across all systems. - **Annual Pen Testing** — Third-party penetration tests conducted annually. Summary available to customers under NDA. - **Vendor Management** — Sub-processors are security reviewed before onboarding and reassessed periodically. - **No AI Training on Your Data** — We never train on your data. AI providers are contractually prohibited from doing so. - **Data Deletion** — Delete your account at any time and we begin deleting your data. What we keep, and for how long, is set out in our Privacy Policy. ## Policy Documents Available on request (security@openassistant.us) or linked directly: - [Privacy Policy](https://openassistant.us/privacy) - [Terms of Service](https://openassistant.us/terms) - 2025 SOC 2 Type II Report (Compliance) — request via security@openassistant.us - Risk Assessment and Treatment Policy (Policy) — request via security@openassistant.us - Change Management Policy (Policy) — request via security@openassistant.us - Baseline Hardening Policy (Policy) — request via security@openassistant.us - Vendor Management Policy (Policy) — request via security@openassistant.us - Systems Development Life Cycle (SDLC) Policy (Policy) — request via security@openassistant.us - Access Control and Termination Policy (Policy) — request via security@openassistant.us - Network Security Policy (Policy) — request via security@openassistant.us - Board and Leadership Oversight Policy (Policy) — request via security@openassistant.us - Incident Response Policy (Policy) — request via security@openassistant.us - Chief Information Security Officer (CISO) Policy (Policy) — request via security@openassistant.us - Risk and Governance Executive Committee Charter (Policy) — request via security@openassistant.us - Company Handbook (Policy) — request via security@openassistant.us - Information Security Policy (Policy) — request via security@openassistant.us - Acceptable Use Policy (Policy) — request via security@openassistant.us - Personnel Security Policy (Policy) — request via security@openassistant.us - Business Continuity and Disaster Recovery (Policy) — request via security@openassistant.us - Data Classification Policy (Policy) — request via security@openassistant.us ## Security Controls ### Access Control Access to systems and data is restricted and continuously monitored. - Role-based access controls (RBAC) enforce least privilege - Multi-factor authentication (MFA) is required for production systems - Access is logged and audited - Permissions are reviewed and revoked when no longer needed - Separation of duties to prevent fraud and errors - Organizations can enable SAML single sign-on and SCIM-based user provisioning, with exportable audit logs of administrative activity ### Data Protection Customer data is protected throughout its lifecycle. - Data is encrypted in transit and at rest - Customer data is logically isolated between tenants, verified by a dedicated and ongoing isolation-testing programme - Inside your own assistant, access is need-to-know: when it negotiates a meeting time, that process works from availability alone, not the titles of your meetings or who is in them - Data collection is limited to what is required for product functionality - Sensitive data access is restricted to authorized personnel only ### System Security Production systems are secured and continuously monitored. - Access to production infrastructure is restricted and authenticated - Systems are monitored for anomalies and unauthorized activity - Security patches and updates are applied on a regular basis - Vulnerability management processes are in place ### Approval & Agent Controls Your assistant acts on your behalf, and the controls that bound it are enforced in code rather than asked for in a prompt. - Your assistant is software: no person works through your requests by hand, and you remain the one who reviews what goes out - Consequential actions are staged for your review and shown in full before they are sent - For messages, no AI model runs between your approval and the send — the words you approved are the words that go out. We may attach your signature or thread the message onto the right conversation, and your own supervision settings may add a recipient; nothing rewrites your text - The assistant has no direct send capability; every outbound action routes through the review step - Files attached to outgoing messages are checked against what you asked for, and every item in a batch of actions is reviewed before anything is sent - The assistant cannot approve its own work, and cannot loosen the oversight it operates under — tightening is allowed, loosening is blocked - You choose which categories of action run automatically and which require your approval - An account-wide stop halts every pending and in-flight action, released only from your own account - An automated recurring workflow can pause or resume only itself, and only for you — it cannot switch off other workflows, and pausing it never affects anyone else who shares that workflow - Customer data is not used to train models, and our AI providers are contractually prohibited from doing so ### Our Commitments What we will not do with your content or on your behalf. - We never take a perpetual or irrevocable licence to your content or your outputs: you own what you put in and what comes out - We never appoint ourselves your agent: your assistant acts within the scope you configure or approve, and nothing it does creates a commitment you did not authorise - We do not sell your data, and data from the services you connect is never used for advertising ### Connected Services Access to the services you connect is bounded at the point of connection, not just at the point of use. - We request the narrowest set of permissions each connection needs, rather than a standing maximum - Administrators can disable a connected service for their organization, and lock that choice so an individual cannot re-enable it - Administrators control which third-party tools their people may connect, and can permit or block individual services - Inbound email must pass sender authentication before it reaches your assistant; unusual requests are held for your confirmation rather than acted on - When someone's role changes, their assistant's access to them ends across every channel ### Extensibility & Developer Access Skills, integrations, and API access are governed by administrator-controlled policy, not left to individual defaults. - Administrators control which skills are available to their organization — restricting by tier, allow-listing or blocking individual skills, and blocking distributed skills at the organization or team level - Administrators can enable or disable MCP (Model Context Protocol) tool connections for their organization, and lock that choice so it can't be changed per user - API keys used for programmatic and CLI access can be scoped to an account, an organization, or an individual user, and can be revoked at any time by an administrator or the key's own owner, taking effect immediately ### Logging & Monitoring All critical system activity is recorded and reviewed. - System and access logs are maintained and monitored - Audit trails are available for key actions - Alerts are triggered for suspicious or abnormal behavior - Implemented data leakage prevention mechanisms - Robust event and audit log management - Intrusion detection and prevention systems ### Infrastructure Hosting and environment architecture are designed for security and resilience. - Documented business continuity and disaster recovery plans - Infrastructure primarily hosted on Amazon Web Services (AWS) - Development, testing, and production environments logically separated - Each user's automated workspace (file access, browser sessions) runs in its own isolated, ephemeral compute environment with no public network access and no administrative privileges inside it, and is torn down after a period of inactivity ### Endpoint Security Company-managed devices are protected against threats and unauthorized access. - Anti-malware solutions are installed on all company-managed devices - Established requirements for the use of cryptographic controls - Host intrusion detection systems (HIDS) - Host intrusion prevention systems (HIPS) ### Reliability & Availability Systems are designed for resilience and continuity. - Infrastructure is deployed across multiple availability zones - Regular backups are performed and tested - Incident response procedures are defined and exercised - System performance and uptime are continuously monitored ### Vendor Management Third-party providers are evaluated and controlled. - Vendors are assessed for security and data handling practices - Data shared with vendors is limited and purpose-specific - Contracts restrict use of customer data - Vendor risk is periodically reviewed ## Subprocessors OpenAssistant uses the following third-party sub-processors, each security reviewed before onboarding and reassessed periodically: - **Amazon Web Services** — Cloud Infrastructure & Platform Services - **Google Workspace** — Business Apps & Productivity - **Slack** — Business Apps & Productivity - **Anthropic** — AI & ML Services - **OpenAI** — AI & ML Services - **TypeSafe AI** — AI & ML Services - **LangSmith** — AI & ML Services - **Twilio** — Business Apps & Productivity - **MongoDB** — Data Stores & Warehouses - **Microsoft** — Business Apps & Productivity - **Stripe** — Payment Processing ## Reporting a Vulnerability If you believe you have found a security vulnerability, email security@openassistant.us, which is monitored by our security team — not by an assistant. We will acknowledge your report within 2 business days, give you our assessment within 10 business days, and keep you updated until it is resolved. **Safe harbour.** We will not pursue legal action against anyone who reports a vulnerability in good faith under this policy, and we will not report you to law enforcement. If a third party brings action against you for research conducted under this policy, we will make it known that your research was authorized. In scope: openassistant.us, app.openassistant.us, and our public APIs. Please do: report promptly, and give us reasonable time to fix an issue before disclosing it publicly. Please do not: access, modify, or retain data belonging to anyone other than yourself; degrade or disrupt the service for other users; use social engineering, phishing, or physical attacks against our staff or customers; or condition a report on payment. Machine-readable contact details: https://openassistant.us/.well-known/security.txt ## Updates **OCTOBER 2026** — When a person is deactivated, including through your identity provider, or an organization is deleted, every API key they held is revoked and stops working straight away. **OCTOBER 2026** — Data a developer sends to our tracing API is always stored in that developer's own account. It can't be attached to another account's conversations or tasks, or to their usage and billing. **OCTOBER 2026** — Revoking or deleting an API key now takes effect everywhere before we confirm it. If that can't be guaranteed at that moment, the request is refused with a try-again error instead of reporting success. **OCTOBER 2026** — Signing out now ends your session on our servers as well as in your browser, within seconds. A copy of your sign-in cookie taken before you signed out stops working, and signing out also clears the data this site stored in your browser. **OCTOBER 2026** — Your account can only take a company record it owns as its own company profile. A company that belongs to another account can't be claimed or edited from yours, and the confidential notes in a company profile are visible only to its administrators. **OCTOBER 2026** — Signing in reaches your account only through an email address proven to be yours, or through the sign-in you already linked to it. An address that hasn't been verified can't be used to get into your account, and verifying your address removes any earlier sign-in someone else set up with it. **OCTOBER 2026** — One-time sign-in and verification codes, and the second factor for administrator sign-in, can be guessed only a limited number of times, even when many attempts arrive at once. Each second-factor challenge and code works only once. **OCTOBER 2026** — When you sign in with Microsoft, your email address counts as verified only when Microsoft confirms that exact address. **OCTOBER 2026** — On team and organization plans, only administrators and owners can invite people to a team, and in an organization only organization administrators can add people to its teams. Invitations can no longer be sent by anyone else. **OCTOBER 2026** — When a person is removed from an organization or their account is deleted, their API keys are revoked and stop working straight away. An organization's own API key cannot create or manage API keys, and can act on behalf of a person only if that person belongs to that organization. **OCTOBER 2026** — When someone who doesn't use OpenAssistant asks an assistant that belongs to one person for something only that person can decide, the assistant can pass the request on to that person as a message from a third party, clearly marked as not coming from them and carrying no authority. Nothing from the person's side is sent back to the requester, and the number of requests is bounded. **OCTOBER 2026** — When your assistant answers a scheduling or calendar question in a Slack channel or group conversation, it shares your meeting details there only if everyone who can read that conversation is a verified coworker of yours. If anyone else could read it, including in channels open to your whole workspace or shared with another company, or if we can't confirm who can read it, the conversation sees only when you're free or busy, and your assistant sends the details to you privately instead. Events marked private in your calendar are shown only as busy to anyone but you. **OCTOBER 2026** — When a workflow is set to start once a condition you describe becomes true (for example, a particular email or calendar change), the check looks only at the calendar and email of the person the workflow runs for, within the access they have granted. If the check can't be completed, the workflow is not started on that check. **OCTOBER 2026** — The controls that run an application (its build and release settings, its connections and delivery settings, its audience, and its analytics) are now available only to the application's own developer team. People who sign in to an application as its users cannot reach them, whatever else they can do inside it. **OCTOBER 2026** — When someone who doesn't use OpenAssistant messages an assistant with a published profile, they reach a limited version of it that can talk with them and look things up on the public web, but cannot see any user's information, take actions on anyone's behalf, or reveal who uses the assistant. This holds for an assistant that belongs to one person as well: a stranger who messages it reaches the same limited version, and someone who has an account but not that assistant gains no access to anyone's information. **OCTOBER 2026** — Your assistant checks who is writing on every text and WhatsApp message, not just the first one in a conversation. When you turn off talking to people you don't know, their texts and WhatsApp messages don't trigger your assistant or your automations. **OCTOBER 2026** — Team plans can share one pool of credits. Administrators can set a monthly credit limit for a team and for each member, and new work stops once a limit is reached until an administrator changes it or a new month begins. A team plan whose subscription is not active stops work for every member. Members see only their own limit and usage. **OCTOBER 2026 — STAGING VALIDATION** — We are preparing an opt-in way for your assistant to read a tab in your own Chrome browser. You link a browser to your account yourself while signed in, and each task needs your separate approval, which expires quickly. Your assistant can only read the page you chose: it cannot click, type or navigate, and taking over the tab or entering private details pauses it. You can remove a linked browser at any time. This remains off by default and requires validation before activation. **OCTOBER 2026 — STAGING VALIDATION** — We have staged an opt-in worker contract limited to JSON canonicalization (json.canonicalize), with task-owned artifact checks and no fallback to unrestricted workspace commands. Execution remains unavailable until a separate worker deployment and its isolation have been verified; this is not a production-wide rollout. **OCTOBER 2026 — STAGING VALIDATION** — Staged native window observations are bound to the authenticated task and its active execution, helping prevent supplied parameters from switching to another user's or task's window. Current administrator permissions are checked before each observation call; unavailable permission information prevents the call. Captured images remain private to the user, including on shared tasks. This capability defaults off and supports observation only; native input and accessibility remain unsupported, with full workflow validation required before activation. **OCTOBER 2026 — STAGING VALIDATION** — We are preparing an opt-in Watch view of the selected task browser tab, separate from taking control. Owner and active-task checks, current administrator permissions and expiring surface bindings limit which snapshots can be shown. User control, private credential entry and changed capture state withhold frames. Watch does not send input, navigate, start a computer or change who controls it. Snapshots show their capture age; they do not prove the desktop foreground or task success. This remains off by default and requires runtime validation before activation. **OCTOBER 2026 — STAGING VALIDATION** — We have staged bounded browser progress updates tied to the authenticated task and its active execution, with updates from inactive or superseded runs withheld and private application details omitted. These updates describe observed stages; they do not prove task success, current computer ownership or permission to act, and no production-wide rollout is claimed. **OCTOBER 2026 — STAGING VALIDATION** — We are validating opt-in protections for computer handoffs and credential entry in staging: outdated requests are rejected, and uncertain input or control returns require an explicit status check and recovery action. These protections are not yet a production-wide rollout, and sending details or returning control does not prove successful sign-in or task completion. **OCTOBER 2026 — STAGING VALIDATION** — Browser tasks now track their own pages and reject stale targeting and overlapping commands. We are validating these controls in staging to reduce actions on the wrong page before a production rollout. **SEPTEMBER 2026** — Before your assistant places a phone call on your behalf, what it tells the other party about having your payment or account details is checked against what you actually gave it for that call. A call that would promise details it cannot really provide is not placed, and you're told why. **SEPTEMBER 2026** — In a shared task, the checks and approvals applied when something goes out to someone outside the task follow the task owner's own settings, including the owner's blocked contacts and any administrator locks. The connection-permission backstop still uses each participant's own settings. An assistant also adds a colleague to a task only after you have asked for or agreed to it, confirmed by a separate verification step, and that colleague is told who added them. **SEPTEMBER 2026** — Files your assistant attaches to outgoing messages are now checked against what you asked for before the message is sent, and every item in a batch of actions is reviewed rather than only the first, so a document that does not deliver what you requested is caught before it leaves. **SEPTEMBER 2026** — Your assistant now recognises you only by your verified contact details when deciding whether a message really came from you. **SEPTEMBER 2026** — In a shared task where several people's assistants work together in one room, a server-side check decides which assistants should be started to respond to what just arrived, rather than leaving that open-ended — and is capped in how many it starts at once and how many times they can hand the conversation to each other before a person is brought back in. **SEPTEMBER 2026** — Your assistant now keeps track of where content came from: what you told it directly, versus what it read from a web page, a search result, someone else's email, a file, or another person's calendar invite. That distinction lets it reason more carefully about content that didn't originate with you. **SEPTEMBER 2026** — Conversations involving disclosures of abuse, exploitation, or self-harm are now flagged for the developer's own team to review, and that conversation permanently shifts into a more careful, supportive tone from that point on. **SEPTEMBER 2026** — An account in the same application no longer, on its own, makes someone a trusted contact of your assistant: on inbound email, another user of the same application is now handled as an outside sender unless they have a real relationship with you. **SEPTEMBER 2026** — Fixed a defect in the automated review step that stages outgoing messages before they send: a correctly written message could be held for your approval instead of going out. Also refined how that step decides between holding a message for your approval and sending it automatically — genuine safety and identity concerns are always held, while a minor presentation issue no longer blocks a message that only you would have seen. **AUGUST 2026** — Assistants working on someone else's behalf can now be given work by another assistant without gaining a voice of their own: they can carry out the task, but cannot contact anyone under their own name — colleagues inside your organization included. Anything that needs sending comes back to the assistant you chose to speak for you. **AUGUST 2026** — Administrators can now turn off assistant-to-assistant collaboration for their whole organization. With it off, assistants reach colleagues directly rather than coordinating between themselves, and the setting cannot be overridden further down. **AUGUST 2026** — Documented administrative controls for skills, MCP tool connections, and API/CLI access — tiering and allow/block lists for skills, an organization-wide cap on MCP connections, and account-, organization-, or user-scoped API keys that can be revoked immediately. Also added single sign-on and SCIM provisioning to the published controls list, and workspace sandbox isolation to the infrastructure section. **AUGUST 2026** — Shipped administrative controls that let an organization cap or disable third-party tool connections for its users, lock that setting so it cannot be overridden individually, and permit or block specific services. Users cannot add their own third-party connections unless an administrator opts in. **AUGUST 2026** — Completed an authorization hardening review across our administrative and API surfaces, tightening the boundaries between account, organization, and team scopes. **AUGUST 2026** — Narrowed the permissions requested when connecting a service, so each connection asks for what it needs rather than a standing maximum. **JULY 2026** — Completed a tenant isolation programme verifying that every path to customer data is bounded to a single account, and established it as ongoing rather than one-off work. **JULY 2026** — Extended supervision enforcement to the delivery boundary, so a user's oversight settings apply consistently on every channel their assistant communicates through. **JULY 2026** — Closed access gaps that could persist after a person's role changed, so reassignment now ends an assistant's access across every channel at once. **JULY 2026** — Reduced data retention by removing an archival store that was no longer required. **MARCH 2026** — Completed a review and update of our security policies to ensure alignment with current infrastructure, systems, and operational practices.