Applied Work · Research

Field record · AW-RS-2026-07-001

The Beyond Work security whitepaper

How Beyond Work engineers, secures, and operates its platform: layered, defence-in-depth controls across authentication, authorization, auditing, and tenant isolation, backed by completed SOC 2 Type 2 certification and ISO 27001/HDS audits underway.

Beyond Work

About 30 minutes · 5 Jul 2026 · v1 Research

Beyond Work prioritises the security of our solutions as a top priority of critical importance. This focus can be found in the continual investments toward enhancing the security of the platform and underlying infrastructure. This includes multi-layered controls covering authentication, authorisation, auditing, and tenant-isolating data confidentiality features within our platform.

The technical safeguards are vital, but we place equal emphasis on the robust processes and skilled team members tasked with safeguarding the platform and ensuring the protection of your data.

Beyond Work's security approach is rooted in an architecture of layered security measures. Our belief in a defence-in-depth strategy is manifested through a blend of logical and physical safeguards, such as access management, the application of least privilege principles, robust authentication, rigorous logging and monitoring, and comprehensive vulnerability management as well as a responsible vulnerability disclosure program.

Our information security program involves proactive oversight and management to identify and address critical security challenges. When issues as such arise, our engineering team is always available to respond quickly, leading to swift resolutions and improved outcomes. Beyond Work aligns with industry-standard information security protocols and compliance frameworks to instil confidence in our customers, enabling them to leverage our services for even their most sensitive tasks.

We firmly advocate for transparency concerning our control environment and adherence to rigorous standards and processes. We've completed SOC 2 Type 2, and ISO 27001 and HDS audits are expected to be finalized mid 2026. Policies and reports are available on request.

"LLMs propose. The platform decides. Audit records both."

The Beyond Work Platform

Beyond Work is a human + AI collaboration platform that lets anyone solve repetitive work.

Users interact with the platform via our dynamically generated interface which surfaces only what a user needs at that very moment. Systems integrations include file transfers via standard protocols such as SFTP as well as through API calls to external systems and supports common file transfer services such as Google Drive and Box.

Beyond Work offers:

— High availability and redundancy via services running in multiple availability zones simultaneously

— Compliance with privacy standards such as GDPR and HDS

— Human-in-the-loop validation and feedback on critical decisions

— Full transparency to AI decision-making points

— Extensibility through a library of "skills" that enable support for new tasks

— SAML SSO for enterprise-grade user authentication

Internal Infrastructure Security

Data security covers your data from the moment it's transferred across the internet to our platform and includes while it persists within our platform written to disk. Beyond Work follows state-of-the-art industry standards for securing the data you've entrusted us with so you can confidently store data in the Beyond Work Platform.

AWS provides a large number of physical and information security controls; you can read more about AWS security via their security documentation portal and request their compliance reports via their artefact service.

The platform is designed to be easily replicated to provide each customer their own private instance ensuring easy compliance with data sovereignty requirements. This gives customers the flexibility to choose the region that best accommodates latency and legal requirements.

The AWS datacenter security provides a solid foundation for the Beyond Work Platform to build infrastructure controls that we'll dive deeper into below.

— tcp/443 for TLS connections used for API integrations or accessing the web-based dynamic, natural-language interface

Beyond Work utilises Certificate Authority Authorisation (CAA) to ensure that beyondwork.com certificates are only issued by Certificate Authorities with which we have accounts. We use Let's Encrypt certificates that are dynamically updated every three months to ensure the highest levels of security in transit.

HTTP Strict Transport Security (HSTS) is also enabled to ensure that all traffic to our domains is encrypted in transit; with HSTS enabled, browsers are forbidden from connecting without TLS.

We strive to continually improve the security of our platform and benchmark our in-transit security with tools like SSL Labs to ensure we're always up to date.

For customer environments that require specific outbound connection allow lists, we recommend using a customer-managed proxy that can inspect the traffic and allow based on the destination domains of *.beyondwork.ai and *.bworker.ai.

Datacentres
The Beyond Work Platform runs on Amazon Web Services (AWS), the market leader in cloud infrastructure. The platform was built from the ground up to be a single-tenant, cloud-hosted solution and takes full advantage of the security functionalities and best-in-class controls that this brings.
Network ports
The Beyond Work platform uses a small number of basic ports for most communication. Additional ports may be used to support custom integrations with other customer systems that rely on specific protocols. The most common ports used to connect outbound to Beyond Work are below and are all using encrypted traffic.
Encryption in transit
TLS 1.3 or 1.2 are required for connections; 1.1 and 1.0 are disabled.
IP address allowlisting
While we use static IP addresses for the platform the users connect to, we highly recommend the use of authentication technologies such as SAML and OAuth to restrict access rather than blocking at the IP layer. Some resources are served from IP addresses, which may change and can lead to intermittent and difficult-to-diagnose connectivity issues to the platform.
Denial of Service (DoS) Protection
Denial of Service prevention is provided by the underlying AWS infrastructure via their AWS WAF and Shield service, which automatically detects and mitigates network and transport layer attacks that attempt to affect the availability of the platform.

Beyond Work Platform Architecture

The Beyond Work platform architecture utilises an industry-standard and modern cloud technology stack to provide services to end customers. The underlying infrastructure relies on the robust offerings from best-of-breed providers such as Amazon Web Services (AWS) and Microsoft Azure as well as Large Language Model (LLM) providers such as OpenAI and Anthropic. This ensures that the foundational layers of the platform are designed, operated and tested to the highest possible standards. The exact models and providers can be configured per tenant according to customer requirements.

Users interact with the Beyond Work platform via our unique interface that combines chat with dynamically generated interfaces, enabling users to rapidly and easily harness the power of the underlying components.

The Beyond Work platform provides access to an ever-expanding library of skills that enable specific tasks such as text extraction, drafting or analysing messages, pushing and pulling files and interacting with external APIs. These run in the context of the user who called them, enabling existing security authorizations to be used within the Beyond Work platform. This ensures that LLMs are never part of any authentication or authorization checks or decisions, providing a clear security and trust boundary and minimising novel attack vectors such as prompt injection.

Document and object storage is provided via Amazon S3 with permissions set both per customer as well as tied to user roles/accounts to ensure granular access controls. All documents and objects are encrypted at rest at all times. Documents may be processed into vectors which enable fast, contextual lookup via per-tenant Qdrant clusters.

Feedback from users on the quality of responses is part of the learning loop used to train platform models. Any PII or customer-specific data is stripped or anonymized before training to ensure confidentiality.

Tenant Isolation

Beyond Work's platform is built on a single-tenancy architecture, providing each customer with a dedicated environment. This approach offers significant benefits in terms of data isolation, security, and resource allocation. In this section, we'll explore what single-tenancy means in the context of our platform, its advantages, and how we've implemented it.

By carefully balancing dedicated resources with efficiently partitioned shared infrastructure, we offer the benefits of single-tenancy without compromising on cost-effectiveness or scalability. This approach underscores our commitment to a secure, flexible, and powerful platform for enterprise AI automation.

— Each customer has dedicated application servers and services.

— Critical components, such as vector databases, are entirely separate for each tenant.

— Some underlying infrastructure at the hardware level is shared but strictly partitioned to maintain isolation.

This approach allows us to provide the benefits of single-tenancy while providing the scalability necessary to operate on-demand, enterprise-grade services.

— Enhanced data isolation. Each customer's data is separated from others, preventing data leakage between tenants.

— Improved security. The isolation between tenants minimizes the impact of potential security incidents, containing them within a single customer environment if they occur.

— Dedicated resources. Customers benefit from dedicated computational resources, ensuring consistent performance regardless of other tenants' activities.

— Customization flexibility. The isolated environment allows for greater customization options to meet specific customer needs without affecting other tenants.

— Simplified compliance. Single-tenancy can make it easier to meet certain regulatory requirements, especially those concerning data isolation and privacy.

— Application layer: Each customer has their own set of application servers running in dedicated containers within isolated Kubernetes namespaces. This ensures separation of application logic and processing.

— Vector database: We provide a unique Qdrant vector database instance for each tenant, ensuring that this critical component for AI operations is entirely isolated per customer.

— Object storage: While we use a shared Amazon S3 infrastructure, each customer's data is stored in its own keyspace providing logical separation of data.

— Relational database: Our AWS RDS (Relational Database Service) setup assigns each customer their own database within a shared instance, maintaining data isolation while optimizing resource usage.

This architecture allows us to maintain a high degree of isolation where it matters most — in application logic, AI operations, and data storage — while leveraging the efficiencies of shared infrastructure for underlying systems.

Our single-tenancy model
In a single-tenancy model, each customer operates within their own isolated environment. This is in contrast to multi-tenant systems where multiple customers share the same application instance. Our implementation of single-tenancy strikes a balance between complete isolation and efficient resource utilization:
Benefits for customers
Our single-tenancy architecture offers several key advantages:
Implementation details
Our single-tenancy architecture is implemented through a combination of dedicated and shared-but-partitioned resources:

Workblock Architecture

The main artifact in Beyond Work is a Workblock. Workblocks are composable units of work that can be created (authored) and executed on the platform.

Users can build workblocks via the platform using natural language. This generates a workblock that consists of modules and tasks, which can then be executed on the platform.

Workblocks are versioned, and only owners and editors can change the workblocks. Depending on customer requirements, the platform allows customers to store workblock definitions in Git repositories and use them for code reviews in order to implement a full software development lifecycle with change management.

By default, the platform tracks all changes and who made them. Workblocks can be tagged, and starting workblocks can be based on tagging so that for example a workblock can have a production tag on a specific version. Even if there is a later version, the production version will be used when starting. This can be used to implement phased rollouts.

— Pull data from an API: the generated Python code can issue API requests to fetch data. In most cases, this requires authentication, see the credentials section for more on that.

— Push data to an API: the generated Python code can use any API to push data. This might be a HTTP/REST based API; it could also be SFTP or similar. See the credentials section for information on how to authenticate.

— Receive data from other systems: the platform currently supports two ingress options:

— Email — it's possible to set up special email addresses that will trigger workblocks to run with the email content.

— HTTP — you can generate a secret token that can be used in HTTP requests against the Beyond Work HTTP API. This API will receive any request and any body. The request will then trigger the workblock to run and to receive the request as input. The generated Python code can then determine how to proceed.

— User triggered via the UI

— An API integration to start a workblock

— An email or HTTP trigger

— Scheduled executions, for example run a workblock every day

— As a child of another workblock

In all cases, the execution happens in a secure sandbox environment where the code cannot directly touch any of the platform, only by issuing requests via the Beyond Work SDK. These requests travel over a secure channel that's tied to a specific execution and user, making it impossible for the sandbox to impersonate other users. Depending on the security policy of the workblock, the sandbox environment might or might not be able to establish outgoing connections.

For access control, an execution has an audience. The audience is configured when the workblock is started, and is the list of users who should have access to the execution (to see it and to interact with it).

Once an execution is complete, a full trace of the execution is stored. This trace contains a full audit trace of who did what during the execution as well as what data was processed.

— Rowstore — tables, primary keys, indexes. Used for workblock-defined schemas; shareable with permissions. Mutable; no joins.

— Blob store — opaque blob keyed by string. Used for documents and similar; no search/index. Mutable.

— Vector store — embeddings + metadata. Used for similarity search. Mutable.

— Run data — append-only, SQL-readable. Used for workblock execution outputs and ad-hoc data. Append-only.

The platform does not provide a general-purpose SQL database. It is possible to connect to an external database from a workblock if such a database is needed.

"There is no general SQL surface. If you need one, you bring one."

Integrations
The platform provides full flexibility for integrating with other systems and platforms in a number of ways:
Integration credentials
Most integrations require some form of authentication. The Beyond Work platform natively supports static key credentials as well as OAuth2 client credentials and token exchange. All credentials are stored in AWS' secure Secrets Manager and are subject to customer-defined access controls.
Execution environment
Workblocks can be started in a number of ways:
Data storage
Workblocks can choose to store data on the platform itself using one of four mechanisms, all of them subject to customer-defined access controls:
Data retention for workblocks
The platform stores full traces of all workblock executions. These are used for cost calculations and auditing, as well as debugging and replays. The traces are stored online for 30 days and for a configurable amount of time in cold storage. The default is to store for 3 years.

Beyond Work Employee Access Methods

Beyond Work follows the practices of least privilege, need-to-know, and segregation of duties for access to systems containing customer data. We review access rights for systems when new employees start and leave the company, when they change roles, as well as multiple times throughout the year.

Access to Beyond Work systems utilises multi-factor authentication both at the infrastructure and the application level to prevent attacks that rely on compromised credentials.

Employees are additionally required to use Beyond Work-managed computers that comply with our internal standards to have the latest security patches applied along with strong passwords and encrypted storage.

Engineer access to underlying infrastructure is similarly secured, with access to systems requiring the same technical controls described above.

When an employee with access leaves the company, they are disconnected from their accounts on the same business day.

Internal Platform Security

Our Configuration Management Standard encompasses hardening measures such as modifying default passwords, applying security patches, restricting administrative privileges, and eliminating redundant accounts or services. Additionally, we limit network access, exposing only essential network protocol ports to both internal and external services.

Access to our production environments is limited to authorised personnel only in line with segregation of duty and least privilege principles.

Security policies
Beyond Work maintains an internal Information Security Management System which covers the operation of the platform as well as day-to-day operations of the business. This covers topics such as Business Continuity, Disaster Recovery, Patching, Vulnerability Management, Acceptable Use, Data Protection and Encryption among others.
Configuration management
The Beyond Work engineering team utilises infrastructure-as-code solutions to configure every facet of our cloud architecture. This employs the identical code review and release procedure that we apply for building the applications that make up the Beyond Work Platform. Prior to implementation, all changes undergo a collaborative peer review process, ensuring their validity and fitness for purpose. This is followed by a phased rollout: initially in the developmental pre-production environments for extensive functionality testing, then progressing to our Production environments.
Separation of production environment
Beyond Work maintains separate production and non-production environments. Data from production is never allowed to be transferred to a non-production environment, although we do have methods for moving configurations from the testing environment into production once they are validated.
Network access controls and bastion hosts
Our underlying infrastructure requires multi-factor authentication (MFA) coming from a Beyond Work-managed workstation.
Logging and alerting
Beyond Work collects logs from the platform itself as well as the underlying infrastructure and associated applications. Beyond Work has a 24×7 on-call rotation to respond in the event of critical and high-severity incidents.
Log retention
Internal security logs are stored for easy retrieval for three months and kept in warm storage for 12 months.

Customer Security Controls

The Beyond Work Platform provides a wide range of security-based controls to enable you to effectively manage your users, groups and permissions.

While onboarding, Beyond Work provides a test IdP based on FusionAuth.io, but Beyond Work does not support username/password authentication on the platform itself.

The platform allows users to generate API keys for use with external integrations. These keys are stored in SHA-256 hashed format and only presented as plain text when they're created.

The platform tracks user logins, both from IdP and token requests, and sends user notifications if the user logs in from a new unknown location.

Users can be automatically provisioned, and user groups from your SSO platform can be used to control access within the platform.

Authentication and user management
Beyond Work by default requires SAML 2.0 for enterprise user authentication, enabling you to manage user authentication controls such as multi-factor authentication with your own centrally managed Identity Provider. It is also possible to use Google and Azure SSO.

Business Continuity & Disaster Recovery

At the platform level, Beyond Work runs as a microservice architecture. This means that we have functionality broken into discrete services that run as multiple parallel instances in a distributed system across all interconnected AZs. This allows for additional benefits such as graceful failure and restarts, zero downtime deployments, and patching, all to take place transparently and without user interruption.

Backups are currently run with a schedule of monthly, weekly, daily, and hourly jobs that provide checkpoints back to various points in time.

Backups are platform-wide and designed for recovery from internal system failures. They are not able to recover individual customer data on an ad-hoc basis.

Availability
The platform is built with highly redundant functionality from the application all the way down to the underlying power delivery infrastructure. This starts with AWS Availability Zones (AZs), the foundational block of physical infrastructure we build on. The platform is at all times running simultaneously from 3 different AZs, which means services are running in at least three different physical data centres, geographically separated to prevent correlated failures but close enough to provide single-digit-millisecond latency. Each AZ has multiple levels of redundant power, networking, and connectivity to ensure single points of failure do not affect our ability to continue to deliver high levels of service availability. The geographic distribution of these data centres further takes into account shared-fate type scenarios such as utility power, water, and fibre disruptions, as well as natural disasters such as earthquakes, fires, tornadoes, and floods to provide maximum levels of confidence. These AZs are connected with high bandwidth, low latency links to enable us to deliver services from all AZs simultaneously and to, likewise, continue to deliver services in the event of the concurrent loss of one or even two full data centres. More information with specifics about AWS infrastructure can be found in their whitepaper here, and descriptions of their data centre principles can be found here.
Infrastructure service recovery
The Beyond Work system runs on cloud infrastructure provided by Amazon Web Services. The underlying infrastructure and associated recovery principles are managed wholly by AWS. More information about AWS' practices in this space can be found in their audit and certification reports available on the AWS website.
Continuous backups
Data is critical to the operation and success of today's businesses, and customer trust in the availability of data stored in the Beyond Work platform is paramount. Beyond Work maintains a robust backup and recovery strategy that ensures minimal data loss in the event of a catastrophic failure, as well as tests our ability to recover data in such scenarios.
Incident response
The Beyond Work engineering team has an incident response plan and exercises to ensure familiarity with internal processes and procedures in their respective spaces. This includes both technical response measures as well as ensuring points of contact and escalation are all communicated and validated.
Executive review
Our CISO, CEO and Engineering Leadership meet monthly to review and identify and discuss control deficiencies, incidents, and material changes to the overall program. This group also makes recommendations for new or improved controls and threat mitigation strategies to the broader executive management team.

Security Program Overview

Beyond Work maintains information security policies and standards based on best practices and standards such as NIST SP 800-53 and the ISO 27000 series. The policies and standards are reviewed and where necessary, updated at least annually and made available to employees. Security training is provided at least annually to all employees.

Risk assessments are conducted annually to understand and adapt to an ever-changing threat landscape.

Beyond Work utilises a Secure Software Development Lifecycle to ensure that the platform is developed with security best practices in mind to protect against common vulnerabilities such as those described in the OWASP Top 10 list.

We utilise vulnerability scanners to identify vulnerabilities in the platform and ensure priority is given to any critical and high-severity vulnerabilities in the platform code itself as well as to those in any third-party code with published exploits.

Beyond Work ensures that all software dependencies used are updated no less than twice a year to ensure that we are always in a position to be able to easily and quickly upgrade in the case of zero-day vulnerabilities in any underlying software.

As part of our commitment to work with both industry experts and security researchers, we operate a responsible disclosure program to ensure we are able to provide the most secure platform possible. Invitations to our program can be requested via security@beyondwork.ai.

This communication will summarise the known details of the breach and the status of our investigation. In the event of such a breach, Beyond Work will take appropriate actions to contain, investigate, and recover from any such breach and will provide a written root cause analysis, including improvements being implemented to prevent recurrence.

Security engineering
The engineering organisation is responsible for securing the platform itself as well as the underlying and associated infrastructure. This includes many different aspects of protecting the platform as well as detecting, responding to, and recovering from incidents.
Notifications and communications
Beyond Work will notify customers in writing within 72 hours of a confirmed unauthorised or unlawful breach of security that leads to the accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of or access to customer message data transmitted through the Beyond Work Platform.

Compliance

Beyond Work has been SOC 2 Type 2 certified for two years, with reports covering security, confidentiality and availability available upon request. ISO 27001 certification is in progress and expected to complete mid-2026; French HDS (Hébergeur de Données de Santé) certification is on the same track.

We're also registered participants in the EU-US, Swiss-US and UK-US Data Privacy Frameworks covering data transfers of PII to the United States.

Privacy

We prioritise the highest standards of data privacy and protection, aligning our practices with the stringent requirements of the General Data Protection Regulation (GDPR). Our unwavering commitment to GDPR compliance is evident in our comprehensive approach, which ensures your data remains secure and in compliance with this critical regulation.

Our compliance strategy encompasses various key elements:

By choosing Beyond Work, you entrust your data to a partner that prioritises your privacy and complies with GDPR regulations. Our commitment to transparency, security, and responsible data handling sets us apart as a trusted partner in your digital journey. Data Processing Agreements are available by reaching out to privacy@beyondwork.ai.

An architecture diagram appendix accompanies this paper.

Data security
As described in this document, we employ robust data security measures to safeguard your data both at rest and in transit. This ensures that your information remains confidential and protected against unauthorised access.
Data handling
Beyond Work adheres to GDPR principles when handling personal data. We implement stringent controls to ensure that data is processed lawfully, transparently, and for specified purposes. Data processed by the platform can be classified, and access can be managed based on the data classifications.
Data access control
Our access controls and user permissions are designed to limit access to personal data to only those who need it for legitimate purposes. This helps prevent unauthorised access and potential data breaches.
Data governance
Beyond Work has established clear data governance policies and procedures and provides tools to customers to manage and maintain data accuracy, completeness, and integrity in accordance with GDPR requirements.
Data transfers
Although data on the Beyond Work platform stays within the European Union, Beyond Work is a listed participant in the updated Data Privacy Framework (DPF) to provide additional assurances in cases where contracts are signed with a Beyond Work entity outside of the EU.
Subprocessors
We additionally ensure we have up-to-date Standard Contractual Clauses (SCCs) in place with all of our own subprocessors.

The record

The facts the editorial desk holds for this record.

Field	Value
Author	Beyond Work
Version	v1
Type	Research

Let's talk

The Beyond Work security whitepaper

The Beyond Work Platform

Internal Infrastructure Security

Datacentres

Network ports

Encryption in transit

IP address allowlisting

Denial of Service (DoS) Protection

Beyond Work Platform Architecture

Tenant Isolation

Our single-tenancy model

Benefits for customers

Implementation details

Workblock Architecture

Integrations

Integration credentials

Execution environment

Data storage

Data retention for workblocks

Beyond Work Employee Access Methods

Internal Platform Security

Security policies

Configuration management

Separation of production environment

Network access controls and bastion hosts

Logging and alerting

Log retention

Customer Security Controls

Authentication and user management

Business Continuity & Disaster Recovery

Availability

Infrastructure service recovery

Continuous backups

Incident response

Executive review

Security Program Overview

Security engineering

Notifications and communications

Compliance

Privacy

Data security

Data handling

Data access control

Data governance

Data transfers

Subprocessors

The record

Related records

Third-party risk decided with the evidence in view

Tail spend consolidated into one governed channel

Savings validated against their own baseline

Explore the platform