Beings Privacy Policy
Last Revised: May 2026 | Document Version: 2026.1
1. Introduction and Who We Are
This Privacy Policy explains how Beings Beam Ltd (“we,” “us,” or “our”) collects, uses, and safeguards information when you interact with our website, create an account, or utilise Beings.
Company Details
Beings Beam Ltd is a company registered in England and Wales.
- Registered Office: 7 Bell Yard, London, England, WC2A 2JR
- Company Registration Number: 13484197
- Contact Email: privacy@beings.com
- Data Protection Officer: Dave Johnstone (trust@beings.com)
Our Role: Data Controller vs. Data Processor
Under UK and European data protection frameworks, our relationship to your data depends entirely on how you use our software:
- As a Data Controller: For individual users, website visitors, and standard SMB/Mid-Market account administrators, we act as the Data Controller for the account infrastructure, billing information, and aggregate performance telemetry required to manage our relationship with you.
- As a Data Processor: For corporate data, custom workloads, and internal company content executed by digital agents inside our workspace, we operate strictly as a Data Processor acting on the instructions of your organisation.
The Scope of this Policy
Beings is built to be local-first by default. In standard local-first deployments, the majority of your agent configurations, vector memories, and local interaction histories remain encrypted on your local hardware and are not visible to us. Where you use a cloud or enterprise deployment, certain Customer Content (the data, prompts, files, and operational content you upload to or generate within the Services) is instead processed and stored in Beings-managed, isolated single-tenant cloud environments as described in your Data Processing Agreement (DPA). This policy governs the data plane that interacts with our central business systems, any Beings-managed cloud environments, and transient cloud-inference relays.
Enterprise Deployment Exception
For corporate users accessing Beings via an organisation-hosted cloud environment, or where administrative policies override local-first configurations, the data boundaries, compliance logging, and controller responsibilities are governed exclusively by your employer’s Master Services Agreement (MSA), corporate Data Processing Agreement (DPA), and internal company privacy disclosures. This baseline policy does not supersede those corporate legal agreements.
2. What Personal Data We Collect
As a local-first platform, we strictly limit the collection of personal information in accordance with the principle of data minimisation. In standard deployments, our systems are engineered so that your primary data remains under your control on your own hardware; in cloud or enterprise deployments, it is held in isolated, single-tenant environments managed by Beings as described in your Data Processing Agreement (DPA).
Categories of Data We Collect
A. Account and Billing Information
To establish your licence and maintain your commercial relationship with us, we collect:
- Identity Data: First name, last name, and professional email address.
- Organisational Data: Company name and team size (for SMB and Mid-Market clients).
- Financial Data: Billing addresses, tax identifiers, and payment card tokens (processed securely via our third-party payment gateways; we do not store raw credit card details).
B. Operational Telemetry (Application Performance & Technical Data)
To maintain the stability of the local hypervisor and optimise agent processing routing, our application can transmit technical diagnostics (“Operational Telemetry“, as defined in our Data Processing Agreement). This is explicitly governed by the Telemetry Toggle in your application settings and includes:
- Device Metadata: Operating system version (e.g., macOS Sonoma, Windows 11), hardware architecture class (e.g., Apple M-Series, Intel x86), and application build versions.
- Performance Metrics: Hypervisor memory utilisation, processing latency, active connection status, and software crash dumps.
- Usage Statistics: Aggregated logs showing which digital agent classes are executed (e.g., calendar automation, spreadsheet parsing) without exposing the contents of those tasks.
Data Excluded from Centralised Collection in Standard Deployments
In local-first deployments, because Beings operates as a sandboxed desktop environment, Beings Beam Ltd does not see, store, or have access to your operational data. Except where you explicitly choose to route a transient request through a cloud-inference provider, the following data categories are structurally isolated on your local hardware and are excluded from our data plane:
- Agent Prompts: The raw text, files, credentials, or instructions you provide to program your agents.
- Agent Memories: Your persistent, local vector databases and relational stores (
memory.sqlite). - API Tokens: Your individual workspace credentials and authentication keys (which remain securely isolated in your local native OS keychain).
In cloud or enterprise deployments, the Agent Prompts, Agent Memories, and related embeddings described above are not excluded from our data plane: they are processed and stored within your Beings-managed, isolated single-tenant environment by our hosting and vector-database sub-processors (set out in our sub-processor list, available on request), under the safeguards set out in your Data Processing Agreement (DPA).
Enterprise Deployment Exception
Where an organisation opts for a custom cloud environment or utilises centralised device management (MDM) to lock compliance logging to “On,” the scope of data capture shifts. Under these configurations, your organisation’s IT policies may centrally record agent execution logs, prompt meta-tags, and administrative audit trails. The collection, accessibility, and retention of this centralised data are governed strictly by your employer’s Master Services Agreement (MSA) and corporate data governance policies.
3. How and Why We Use Your Data (Lawful Bases)
We only process your personal data when we have a valid legal framework to do so under UK data protection law (including the UK GDPR and the Data (Use and Access) Act 2025).
The table below outlines exactly how and why we handle your information, alongside the specific lawful bases we rely upon:
| Purpose / Processing Activity | Categories of Data Involved | Lawful Basis for Processing |
|---|---|---|
| Account Creation & Licensing: Managing your subscription, authenticating your login credentials, and delivering the software. | Account and Billing Information | Performance of a Contract: Necessary to fulfil our obligations under the Beings Terms of Service (for self-serve / SMB users) or the Master Services Agreement (MSA) (for enterprise customers). |
| Payment Processing: Securely handling transaction routing, tax collection, and billing renewals via payment gateways. | Financial Data | Performance of a Contract: Necessary to execute your commercial subscription. |
| System Security & Integrity: Debugging local hypervisor crashes, preventing malicious exploits, and maintaining core platform stability. | Operational Telemetry / Crash Logs | Recognised Legitimate Interests: Aligns with the statutory categories for network, information security, and technical fault prevention. |
| Product Optimisation: Aggregating completely anonymised feature usage to guide our engineering roadmap. | Operational Telemetry (Performance Metrics) | Legitimate Interests: Based on our business interest to improve product efficiency, provided it does not override your right to object. |
The Zero-Training Guarantee
We fundamentally reject the model-vendor practice of leveraging user activity for product development. Beings Beam Ltd guarantees that your inputs, prompts, system execution context, and local vector memories are never used to train, tune, or refine any foundational, public, or cross-tenant AI models—whether ours or a third party’s—unless you explicitly opt in via a platform capability. Your interaction data remains localised or strictly transient during cloud routing.
The only exception is fully anonymised and aggregated data. To qualify, the data is subjected to an irreversible anonymisation process at the point of ingestion—removing account identifiers, workspace tokens, IP addresses, and any other field that could single you out—such that it can no longer identify you and cannot be re-linked to you. Once irreversibly anonymised, this data is no longer personal data and is never re-identified, and we may use it to improve and validate our own orchestration and routing logic. This is distinct from the transient, pseudonymous inference routing described in Section 4(C), which remains personal data and is never used for this purpose.
Exercising Your Right to Object (The Telemetry Switch)
For any data processed under our Legitimate Interests (such as application optimisation telemetry), you maintain an absolute right to object. You can instantly exercise this right at any time by toggling Telemetry to “Off” in the Beings app settings. Once deactivated, all outbound performance pings to our servers are terminated in real-time.
Enterprise Deployment Exception
Where Beings is centrally provisioned within a corporate environment and telemetry or audit trails are forced by administrative policy, the lawful bases for that employee processing are established independently by your employer (e.g., for corporate data governance, operational auditing, or workforce management). In these configurations, Beings Beam Ltd acts strictly as a data processor executing processing activities dictated by the enterprise’s Master Services Agreement (MSA).
4. Data Storage, Location, and Retention
We believe the cloud should be a relay, not a default custodian. Our technical substrate is engineered to respect your data ownership by prioritising local containment where possible; where Customer Content must be hosted (in cloud or enterprise deployments), it is held in isolated, single-tenant environments rather than pooled across customers.
Where Your Data Lives
A. Agent Memory and Operational State (Local Hardware)
In standard local-first deployments, all core operational data—including your persistent agent memories, contextual embeddings, local silos, and relational databases (memory.sqlite)—resides on your own physical devices (e.g., your laptop, desktop, or private peer network), encrypted under keys that you control natively via your hardware’s secure enclave. In these deployments, there is no central Beings cloud database holding your second brain. Where you use a cloud or enterprise deployment, this persistent state is instead held in Beings-managed, isolated single-tenant cloud silos—hosted within the United Kingdom and/or the European Economic Area (EEA) by default, unless a different region is agreed in your Order Form or Data Processing Agreement—with the technical and organisational safeguards described in your Data Processing Agreement.
B. Account, Licensing, and Billing Data (UK / EEA)
The minimal administrative data required to manage your subscription (such as your account profile, licence tokens, and billing records) is stored securely on isolated servers located within the United Kingdom and the European Economic Area (EEA).
C. Transient Inference Data (Zero-Retention Routing)
When your local agents use cloud-routed inference capabilities (such as our managed cloud-inference tier running external models), the prompt payloads transit through our secure egress proxy as transient, pseudonymous streams.
- This data is encrypted in transit using TLS 1.3.
- It is processed transiently to complete your request and is not persistently retained by Beings Beam Ltd post-inference.
- It is passed to upstream model infrastructure engaged under enterprise agreements that include contractual “zero-training” protections. Where an approved zero-retention (abuse-logging opt-out) is in place with the relevant provider, no copy is retained; otherwise the payload remains subject to that provider’s standard anti-abuse caching window (typically up to 90 days, as specified in our sub-processor list).
How Long We Retain Your Data
We only keep administrative personal data for as long as necessary to fulfil the purposes outlined in this policy or to satisfy statutory UK legal obligations.
- Active Account Data: Maintained for the exact duration of your active subscription. Following account closure or termination, your account metadata and profile records are permanently purged or anonymised within 30 days.
- Financial and Transaction Records: Retained for a mandatory period of 6 years following the end of the financial year in which the transaction occurred, satisfying statutory UK tax, audit, and corporate record-keeping laws.
- Aggregated Telemetry Data: Performance and crash diagnostic logs transmitted via the opt-in toggle are stripped of system markers and anonymised upon receipt. Once anonymised, this data no longer identifies you and may be retained on an aggregated basis for long-term platform and hypervisor optimisation. Any telemetry held in an identifiable form is deleted within 12 months.
Enterprise Deployment Exception
For organisations utilising custom cloud topologies or dedicated single-tenant infrastructure managed by Beings, the rules of data residency and retention change. In these scenarios, the enterprise customer designates the precise cloud regions (e.g., AWS UK or EU regions) where containerised data stores reside. Furthermore, automated data purging timelines, employee audit trail retention scales, and snapshot backup windows are governed explicitly by the corporate Master Services Agreement (MSA) and customised system configurations.
5. Third-Party Sharing and Sub-processors
To deliver our services—specifically subscription infrastructure, automated billing, and cloud-routed AI capabilities—we share certain limited datasets with trusted third-party service providers.
We require all third-party processors to enter into legally binding Data Processing Agreements (DPAs) that satisfy Article 28 of the UK GDPR, ensuring they maintain technical and organisational safeguards that match or exceed our security standards.
Categories of Third Parties We Share Data With
- Payment Gateways & Subscription Management: We utilise enterprise payment processors (such as Stripe) to manage your billing lifecycle. Your identity and payment details are handled by these providers, who tokenise card data so that we never receive or store raw card numbers.
- Vendor-Provisioned Models (The Inference Sub-processors): For users utilising our managed cloud-inference tiers, transient prompt data is securely routed via encrypted pipelines to upstream foundation model providers. These providers act as sub-processors and are engaged under enterprise agreements that include a contractual prohibition on training their models with our users’ payloads. Where supported, we enable zero-retention processing; otherwise data remains subject to the provider’s standard anti-abuse caching window (typically up to 90 days, as specified in our sub-processor list). The authoritative list of current providers is available on request (see below).
- Our Sub-processor List: Because our orchestration layer remains model-agnostic, our technical integrations evolve. We maintain a current list of all third-party sub-processors — their processing activity and data-centre locations — which is available to customers on request (and to enterprise customers under their Data Processing Agreement). The list also indicates, for each inference provider, whether it operates on an approved zero-retention basis or remains subject to that provider’s anti-abuse caching window.
The “BYOK” (Bring Your Own Key) Firewall
For advanced configurations, Beings allows users to bypass our native cloud-inference routing entirely by inputting their own independent AI foundation model credentials (e.g., your personal OpenAI, Anthropic, or Groq API keys).
Where you utilise Customer-Provisioned Models (BYOK):
- Beings operates purely as a localised technical conduit.
- Your credentials and prompt streams bypass our network routing entirely, executing directly between your local machine and your chosen model vendor.
- These downstream third parties are not sub-processors of Beings Beam Ltd. We hold zero visibility into, and zero liability for, the data processing terms enforced by your personal API providers.
Enterprise Deployment Exception
Where an organisation hosts its own custom cloud instances of Beings or mandates internal network gateways, the sub-processor map shifts completely. The selection of cloud hosting infrastructure (e.g., AWS, Azure, or private hardware configurations), enterprise model endpoint instances, and data routing proxies is controlled entirely by the corporate entity. All downstream third-party processors utilised under these custom deployments are governed explicitly under the organisation’s corporate Master Services Agreement (MSA) and negotiated DPAs, completely independent of Beings Beam Ltd’s standard sub-processor list.
6. User Control and Your Rights
You own your data, your memory, and your identity. Under UK data protection laws, you possess robust statutory rights regarding your personal information. Because Beings is engineered as a local-first application, the way you exercise these rights is fundamentally different—and often much simpler—than with traditional cloud-based SaaS products.
Your Statutory Rights and How They Apply to Beings
- The Right of Access (Data Subject Access Requests): You have the right to request a copy of the personal data we hold about you. For standard users, this is limited strictly to your core account profile, subscription tier, and billing history.
- The Local-First Reality: In local-first deployments, we cannot provide you with a copy of your agent prompts, transaction histories, or vector databases because we do not have them — you can access 100% of this data locally at any time by inspecting your local workspace files. In cloud or enterprise deployments, this data resides in your Beings-managed single-tenant environment and access requests are handled as set out in your DPA.
- The Right to Erasure (The “Right to be Forgotten”): You can request that we permanently delete your personal data. If you close your account, we automatically purge your administrative profile and billing identifiers from our cloud servers within 30 days.
- Wiping Your Second Brain: To erase your agentic memory in a local-first deployment, you do not need our permission or intervention. You can instantly wipe any agent’s memory silo or completely delete your local
memory.sqlitedatabase directly through the application settings on your desktop. For cloud or enterprise deployments, erasure from your single-tenant silo is executed without undue delay and within applicable statutory timelines, as operationalised in your organisation’s DPA.
- Wiping Your Second Brain: To erase your agentic memory in a local-first deployment, you do not need our permission or intervention. You can instantly wipe any agent’s memory silo or completely delete your local
- The Right to Rectification: If any administrative information we hold about you is inaccurate or incomplete, you have the right to demand its correction. You can update your account profile directly via the Beings user dashboard.
- The Right to Object to Processing (The Telemetry Switch): You have an absolute right to object to the processing of your technical metadata for product optimisation. You can execute this right instantly, with zero friction, by flipping the Telemetry Toggle to “Off” in your application settings.
To exercise any of your administrative account rights, or if you have questions about your local data architecture, you can contact our privacy team directly at privacy@beings.com.
Enterprise Deployment Exception
Where Beings is deployed by an enterprise customer, the organisation acts as the primary Data Controller, and Beings Beam Ltd acts strictly as a data processor. If you are an employee utilising an enterprise-managed instance, you must submit any formal Data Subject Access Requests (DSARs) or erasure requests directly to your organisation’s IT or compliance department. We cannot alter, delete, or export data from a centrally managed enterprise cloud instance without direct authorisation from the corporate account administrator, as governed by the applicable Master Services Agreement (MSA).
7. Automated Decision-Making (ADM) Disclosures
Because Beings orchestrates autonomous digital agents capable of executing workflows (such as analysing documents, managing schedules, or interacting with third-party software tools), our platform utilises advanced algorithmic processing.
Under the UK Data (Use and Access) Act 2025, automated decisions that carry legal or similarly significant effects for individuals (within the meaning of Article 22 UK GDPR) are permitted, provided that strict, operational safeguards are embedded within the software runtime.
Our Approach: Meaningful Human Involvement
We design our local-first software to protect your agency. A decision or action is only considered “solely automated” under the law if it occurs without any meaningful human oversight.
To ensure you retain complete control over your data and workflows, Beings natively integrates the following foundational protections directly into the hypervisor layer:
- The Local Approval Gate: By default, our core product enforces a mandatory Human-in-the-Loop (HITL) verification gate. Before an agent can commit a mutating action—such as sending an email, editing a live CRM entry, or modifying an external database record—the Beings Hypervisor pauses the execution loop and prompts you for manual authorisation via a localised desktop notification.
- The Right to Genuine Human Intervention: You hold the ultimate kill-switch. At any stage of an agent’s execution sequence, you can intercept the automated process, alter the agent’s machine-readable state, overwrite its contextual inputs, or cancel the command entirely.
- The Right to Representations and Contestation: If an agent generates an automated draft, analytical evaluation, or operational output that you disagree with, the local-first architecture ensures the data remains sandboxed on your device, allowing you to manually rewrite, override, or delete the output before it ever leaves your local network perimeter.
Because of this native architectural design, standard operations inside the desktop version of Beings are not “solely automated” pipelines; they are assistive, human-verified executions.
Enterprise Deployment Exception
Where an organisation centrally configures Beings and establishes custom administrative overrides (for example, bypass rules that allow specific background agents to execute data-cleansing routines or route high-volume internal files autonomously without individual worker alerts), the Enterprise Customer acts as the sole Deployer and Data Controller of that automated decision-making workflow.
In these configurations, the legal obligation to comply with the statutory safeguards of the Data (Use and Access) Act 2025—including informing affected data subjects, processing representations, and facilitating corporate appeal pathways—rests entirely with your employer under the terms of our governing Master Services Agreement (MSA). Beings Beam Ltd operates strictly as a technical platform provider.
8. International Data Transfers
Because Beings Beam Ltd is based in the United Kingdom and serves a global customer base, minimal administrative data (such as account licensing) or transient cloud-inference payloads may occasionally cross international borders.
The Data Protection Test
When we initiate an international data transfer outside the UK, we ensure compliance with the Data (Use and Access) Act 2025 framework. In accordance with UK law, we apply a strict “Data Protection Test” to confirm that any recipient destination or third-party processor ensures a standard of data privacy and security that is not materially lower than the protections guaranteed under the UK GDPR.
We secure international transfers utilising three primary legal pillars:
- UK Adequacy Regulations: We prioritise routing and operations within jurisdictions officially recognised by the UK Government as providing adequate data protection (such as the European Economic Area and countries covered by approved UK Data Bridges).
- Appropriate Safeguards: Where data must transit to a country without a native adequacy ruling (such as certain US cloud zones), we execute the UK International Data Transfer Agreement (IDTA) or the UK Addendum to the European Commission’s Standard Contractual Clauses (SCCs), backed by localised risk assessments.
- Transient Proxy Exemption: For global cloud inference streams, data transits strictly as an encrypted, transient stream under enterprise contracts that include zero-training protections and, where supported by the provider, zero-retention processing at the boundary endpoint.
- Swiss Transfers (FADP): For data subject to the Swiss Federal Act on Data Protection (FADP), we rely on Switzerland’s recognition of UK adequacy for transfers to our UK infrastructure, and on the EU SCCs with the FDPIC-mandated Swiss amendments for any onward transfer to a country without a Swiss adequacy decision, consistent with the Swiss module of our Data Processing Agreement.
Enterprise Deployment Exception
For enterprise clients utilising custom cloud architectures, the corporate entity acts as the primary exporter initiating cross-border data routing. The enterprise defines its own infrastructure regions, server clusters, and local regional proxies. Any required Transfer Risk Assessments (TRAs) or execution of localised Standard Contractual Clauses (SCCs) to govern corporate data movement are managed natively according to the infrastructure provisions of the governing corporate Master Services Agreement (MSA). Beings Beam Ltd holds no liability for cross-border paths configured directly by corporate administrators.
9. Complaints Procedure
If you have a concern or dispute regarding how Beings Beam Ltd handles your personal data, you have a statutory right under the UK Data (Use and Access) Act 2025 to lodge a formal data protection complaint directly with us.
We take your information rights seriously and handle all internal disputes through a formalized, transparent review process.
How to Submit a Data Protection Complaint
You may submit a complaint to our data protection team through any of the following channels:
- Electronic Form: Available securely within your Beings user dashboard.
- Email: privacy@beings.com
- Postal Mail: Data Protection Officer, Beings Beam Ltd, 7 Bell Yard, London, England, WC2A 2JR
To help us investigate efficiently, please provide your account details, a clear description of the data protection issue, and any relevant system timestamps.
Our Statutory Handling Timeline and Process
Once we receive your complaint, we execute our internal review according to the following legal standards:
- 30-Day Acknowledgement: We will log your dispute and issue an official acknowledgement of your complaint within 30 days of receipt.
- Proportionate Investigation: Our privacy and engineering teams will initiate an internal enquiry into our platform routing, infrastructure security, or billing tracks without undue delay.
- Outcome Communication: We will communicate the final findings of our investigation, alongside any corrective actions taken, in clear and accessible language as soon as the review is complete.
Escalation to the Regulatory Authority
Under active UK law, you are required to raise your data protection complaint directly with us first to allow for internal resolution. However, if you remain dissatisfied with our final response or if we fail to acknowledge your dispute within the mandatory 30-day window, you retain an absolute right to escalate the matter to the UK regulatory authority:
- Regulator: The Information Commissioner’s Office (ICO) / The Information Commission
- Website: ico.org.uk
Enterprise Deployment Exception
Where you are an employee utilising an instance of Beings managed by your employer, Beings Beam Ltd is not the Data Controller and cannot legally accept, process, or resolve your data protection complaint. Under these configurations, your organisation holds absolute administrative authority over your local or cloud deployment. You must lodge any data protection complaints or system tracking disputes directly with your organisation’s internal compliance officer or IT department, as governed by the corporate Master Services Agreement (MSA).
10. Data Security and Breach Notification
Our Security Measures
We maintain a written information security programme with technical and organisational measures appropriate to the risk. These include encryption of Customer Content in transit (TLS 1.3) and at rest (AES-256), logical single-tenant isolation of cloud-hosted environments, least-privilege and multi-factor access controls for production systems, and continuous monitoring and vulnerability management. The full technical and organisational measures applicable to cloud and enterprise deployments are set out in the Technical & Organisational Measures (TOMs) annex of your Data Processing Agreement (DPA).
Notifying You of a Personal Data Breach
Where we act as Data Controller (for example, for your account, billing, or Operational Telemetry data) and a confirmed personal data breach is likely to result in a high risk to your rights and freedoms, we will notify you without undue delay—and, where required, the Information Commission—describing the nature of the breach, its likely consequences, and the measures we have taken to address it, consistent with our obligations under the UK GDPR.
Where we act as Data Processor (for Customer Content in cloud or enterprise deployments), we notify the relevant Data Controller without undue delay in accordance with our Data Processing Agreement (DPA), and that Controller is responsible for notifying affected individuals.
Enterprise Deployment Exception
For cloud and enterprise deployments, the specific breach-notification timelines, communication protocols, and the allocation of notification duties between your organisation (as Data Controller) and Beings (as Data Processor) are governed by the corporate Data Processing Agreement (DPA) and Master Services Agreement (MSA).
11. Updates to This Policy
We keep this Privacy Policy under regular review to ensure it accurately reflects our technical substrate, engineering developments, and evolving data protection legislation.
When material changes are made, we will update the “Last Revised” date at the top of this document. If the modifications significantly alter how we handle your administrative account data or the physics of our transient cloud-inference proxies, we will provide a prominent notice within the Beings app dashboard or notify you directly via your registered account email before the changes take effect.
Enterprise Deployment Exception
Updates to this standard policy do not automatically alter or override custom privacy frameworks, data retention tables, or security commitments established under an active corporate Master Services Agreement (MSA) or bespoke Data Processing Agreement (DPA). Enterprise deployments remain bound to the versioned legal schedules negotiated directly between your organisation and Beings Beam Ltd.
This concludes the Beings Beam Ltd Privacy Policy.