Platform Documentation
Platform Documentation
Breadcrumbs

Security Model Overview

This page provides an overview of RunWhen's security architecture for teams evaluating the platform. For specific compliance policies, see the child pages under this section.

Security Architecture

RunWhen's security model is built on least privilege and data minimization. The platform is designed so that sensitive credentials and data remain in your environment while only necessary metadata flows to the RunWhen Platform for coordination.

Trust Boundary

The fundamental security boundary separates your environment (where RunWhen Local runs) from the RunWhen Platform (where coordination happens):

Your Environment (Full Control):

  • RunWhen Local agent pods

  • Kubernetes credentials and service accounts

  • Cloud provider credentials

  • Database passwords and connection strings

  • Application secrets and configuration

  • Raw application logs

RunWhen Platform (Coordination Only):

  • Workspace configurations and task definitions

  • Task execution metadata (task ID, status, duration)

  • Structured task results (summaries, issues, next steps)

  • User access patterns and audit logs

Key principle: Credentials never cross the trust boundary. RunWhen Local uses credentials locally to execute tasks, and only sends metadata and structured results back to the Platform.

Data Classification

Data That Stays in Your Environment

Never transmitted to the Platform:

  • Kubernetes credentials (kubeconfig, service accounts)

  • Cloud provider credentials (AWS keys, Azure tokens, GCP service accounts)

  • Database passwords and connection strings

  • API keys and access tokens

  • Application secrets

  • Raw application logs (unless explicitly configured)

  • Source code and proprietary data

  • Customer PII

Data Transmitted to the Platform

Task metadata:

  • Task ID, name, status, timing, exit code

Task results (configurable):

  • Structured summaries of findings

  • Issue details (severity, affected resource, message)

  • Suggested next steps

Workspace configuration:

  • Resource names and types (sanitized)

  • Discovery metadata

Authentication

Platform Authentication

  • SAML 2.0 (Okta, Azure AD, Google Workspace)

  • OAuth 2.0 / OIDC

  • Username/Password with mandatory MFA

  • API Tokens for automation

RunWhen Local Authentication

  • To Platform: Workspace token stored as Kubernetes Secret

  • To Kubernetes: Service account with RBAC permissions

  • To External Systems: Credentials from Kubernetes Secrets or external vaults

Role-Based Access Control

Workspace access is role-based:

  • Owner: Full workspace management, user management, task execution

  • Operator: Task execution and result viewing

  • Viewer: Read-only access to results

Encryption

In Transit:

  • TLS 1.3 minimum (TLS 1.2 accepted)

  • Strong cipher suites only (AES-256-GCM, CHACHA20-POLY1305)

  • Certificate pinning available

At Rest:

  • Platform database: AES-256 encryption

  • Backups: Encrypted with separate key management

  • Your environment: Follows your existing encryption policies

Network Security

Required outbound from RunWhen Local:

No inbound connections required. All communication is agent-initiated. No ports need to be opened on your infrastructure. No VPN or direct connectivity needed.

Audit and Compliance

Audit logging captures:

  • User authentication and authorization

  • Workspace access and modifications

  • Task execution requests and results

  • Configuration changes

  • Failed access attempts

  • API token usage

Compliance certifications:

  • SOC 2 Type II (annual external audit)

  • GDPR compliance (DPA available, right to deletion, data export)

  • Data residency options (US, EU, or self-hosted for any location)

Contact info@runwhen.com for specific compliance documentation (BAA, DPA, SOC 2 reports).

Credential Management

Recommended: Store credentials in Kubernetes Secrets or external vaults (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager).

RunWhen platform components use HashiCorp Vault with strict policies -- platform services can write and list secrets but cannot read secret contents. Only the task execution pods have read access to the specific secrets they need.

Detailed Policies

The child pages under Security / Compliance / Responsible AI contain the specific policies including:

  • End User Accounts and Device Policy

  • Customer Data Protection Policy

  • Risk Assessment

  • And additional compliance documentation

For materials not covered here, contact security-and-compliance@runwhen.com.