Security / Compliance / Responsible AI
Overview
RunWhen provides a platform for executing operational automation within customer-controlled environments. The platform is designed such that automation executes locally within the customer’s infrastructure, and customer credentials and system access remain under customer control.
RunWhen may be deployed either as a SaaS offering or as a self-hosted solution within the customer’s VPC or data center. This flexibility enables customers to align deployment with internal security, compliance, and data residency requirements.
Architecture and Data Flow
The RunWhen platform consists of three primary components: the RunWhen Local Runner, the RunWhen Backend, and the LLM endpoint (provided by the customer). See Architecture & Overview.
The RunWhen Local Runner is deployed within the customer environment and executes all automation tasks locally against customer systems. The Backend provides orchestration, coordination, and user interface functionality. The Backend does not require direct access to customer infrastructure, but it does require access to the LLM endpoint.
Only task output, referred to as operational metadata, is transmitted from the Runner to the Backend. Raw system data, credentials, and execution context remain within the customer environment unless explicitly configured otherwise.
Data Handling and Customer Controls
RunWhen applies a data minimization approach. The tasks installed that produce operational metadata transmitted to the Backend are intended to be configured during initial deployment to align with the customer’s security posture.
Customers may control the scope and content of transmitted data through configuration, including:
- Resource metadata anonymization to remove or obfuscate sensitive cloud resource identifiers prior to transmission; and
- Allow-list and deny-list controls based on task tags, which govern which automation tasks are imported and executed.
Because task output defines the operational metadata transmitted to the platform, restricting task availability directly limits data exposure.
All data in transit is encrypted using TLS 1.2 or higher. Data stored by the Backend is encrypted at rest.
RunWhen does not use customer data for model training.
Identity and Access Management
User authentication is supported through integration with enterprise identity providers using SAML 2.0. Customers may enforce authentication policies, including multi-factor authentication, through their identity provider.
The Runner accesses customer infrastructure using customer-controlled identity mechanisms, including Workload Identity Federation where supported, avoiding reliance on long-lived credentials.
Access within the platform is governed through role-based access control.
AI and External Services
RunWhen may use external large language model services, such as Azure OpenAI, OpenAI Enterprise, Anthropic Enterprise, or Google Vertex AI, to support reasoning and summarization. Data transmitted to such services is minimized and processed to remove or redact sensitive information prior to transmission.
Automation Control and Supply Chain
Automation is delivered through versioned, immutable Task CodeBundles. Customers control which Task CodeBundles are available for execution through allow-listing mechanisms mentioned above.
Task CodeBundles are retrieved from trusted container registries. Customers may restrict or disable Tasks using the tags mechanism above at any time in accordance with internal governance requirements.
Network Security
The Runner operates without requiring inbound network connectivity. Communication is initiated outbound from the customer environment to the Backend, approved external services, and container registries.
Customers may apply network controls, including egress allow-listing, NAT-based outbound access, and private service access, consistent with their security policies.
Logging and Auditability
RunWhen generates audit logs that include task execution activity, user actions, and configuration changes. Customers may retain detailed logs within their own environment and export relevant logs to centralized monitoring or SIEM systems.
Incident Response and Resilience
RunWhen maintains an internal incident response process for the identification, containment, and remediation of security incidents. Customers are notified of relevant incidents in accordance with applicable procedures and contractual obligations.
The platform is designed with separation between execution and control planes. In the event of a Backend or network disruption, no new centrally coordinated automation is initiated, and existing tasks complete within the customer environment.
Data Residency
RunWhen supports region-specific deployment options for both SaaS and self-hosted configurations. Data is processed and stored within the selected region unless otherwise configured by the customer.
Compliance Posture
RunWhen implements security controls aligned with generally accepted industry practices, including least privilege access, encryption, audit logging, and secure software delivery.
RunWhen is currently in process for SOC 2 compliance. Internal controls are reviewed on a periodic basis. RunWhen supports customer security reviews and vendor risk assessments upon request.
This section includes the subset of the corporate and compliance related material that the RunWhen team has chosen to make public.
Contents
- Overview — This page; security overview, introduction to the section, and contact.
- Security Model Overview — Security architecture, trust boundary, data classification, authentication, encryption.
- Data Security Framework — Data types, enterprise configuration, automation output handling.
- Data Security and Privacy — Privacy approach, data we handle, data deletion, compliance.
- Secure-By-Design Principles — Encryption, least privilege, no long-lived credentials, audit logging.
- Compliance — Compliance posture, monitoring, and audits.
- Responsible AI — How RunWhen uses AI responsibly and how you can configure and govern it.
- Security Contact — Report security concerns or bugs.
- Security Incident Response — Data incident definition, breach types, communications, disclosure.
Policies and Procedures
- Annual Security Policy Review
- Business Continuity and Operational Resilience
- Change Management Policy
- Code of Conduct Policy
- Cryptographic Key Policy
- Data Loss Prevention
- End User Accounts and Device Policy
- Logging Controls Summary
- Risk Assessment
- Segregation of Duties Policy
- Software Patching and Update Management Policy
- Software Testing Data Policy
- Threat Intelligence Process
If your organization requires materials you do not see addressed here, please inquire at security-and-compliance@runwhen.com.