Information Security Policy

Identity Provider and Session Authentication

Servo uses WorkOS as our identity provider. All user sessions are authenticated through industry-standard OAuth 2.0 / OIDC flows. We do not store user passwords — password management is delegated entirely to WorkOS and the identity providers it supports (SSO, social login, etc.).

Token Lifecycle

Sessions are granted via short-lived signed tokens. Revoking a session takes effect immediately. Tokens are transmitted exclusively over HTTPS.

Capability Links

For certain invitation and onboarding flows, Servo issues short-lived, single-use capability links. These are high-entropy tokens that grant access by virtue of being functionally unguessable — not by requiring a password. They grant narrowly scoped access and are invalidated immediately upon use.

API Key Authentication

API keys issued to customers are scoped, logged, and tied to the requesting identity in the audit trail.

Tiered Authorization Model

Every route in the Servo API is assigned an explicit authorization level. The tiers are:

• Public — No authentication required (health checks, webhooks)
• Capability Link — High-entropy single-use access, narrowly scoped
• Full Auth — Standard session token, required for all customer-facing routes
• Platform Admin — Elevated internal access, cross-tenant operations
• Blocked — Deprecated or unsafe routes explicitly denied

Authorization is enforced uniformly across all routes — there are no per-handler exceptions.

Enforcement at Every Layer

Tenant identity is derived exclusively from the authenticated session — clients cannot supply or override it. All database queries automatically enforce tenant scope, making cross-tenant data leakage structurally impossible at the application layer.

Cross-Tenant Access Controls

Cross-tenant operations are restricted exclusively to Servo platform administrators with elevated internal permissions. Any cross-tenant access is validated, explicitly flagged, and captured in the audit log. No customer user can access another tenant's data.

Data in Transit

All communication between clients and the Servo platform is encrypted using TLS. HTTPS is enforced at the network edge before traffic reaches the application. Internal service communication is isolated by network controls. Database connections are encrypted in transit.

Data at Rest

Sensitive third-party API credentials and connection keys stored in the database are encrypted at rest using AES-256. Database volumes and S3 buckets are encrypted using AWS-managed encryption at rest. No plaintext credentials are stored in application data.

Secret Management

All application secrets — database credentials, API keys, signing keys, encryption keys — are encrypted at rest and never stored in plaintext. Secrets are version-controlled in encrypted form; decryption keys are distributed out-of-band and never committed to the repository. Automated tooling prevents unencrypted secrets from reaching version control. CI/CD pipelines use environment-scoped secrets isolated from the application repository.

Automatic and Complete Coverage

All data changes are captured automatically — no application code needs to opt in. Coverage is validated continuously; gaps are treated as a hard failure. The audit log cannot be modified or bypassed.

What Is Logged

Each audit entry captures:

• Who made the change: user identity and actor type (human, AI agent, system, API key)
• If an AI agent acted on behalf of a user, both identities are recorded
• What changed: the affected record and its previous and current state
• When it happened, in UTC
• Where the request originated: client IP address
• A correlation ID linking all changes made within a single operation
• Whether the action was performed by a Servo administrator

Non-Destructive by Default

Records are never permanently deleted by default. Deletions preserve the full audit trail and enable data recovery. Permanent removal requires explicit administrative action.

Rate Limiting

All API endpoints are rate-limited per client to defend against abuse and credential stuffing. Clients that exceed the limit receive a standard retry response. Failed authentication attempts count toward the limit.

Input Validation and SQL Injection Prevention

All database queries use parameterized statements — user-supplied values are never interpolated into query strings. Dynamic query components are validated against an allowlist before use.

Type-Safe API Responses

All API responses are required to use explicitly typed structures. Untyped or catch-all response shapes are blocked by automated tooling in the pre-commit and CI pipeline. This prevents accidental data leakage and ensures all response fields are intentional.

Request Field Stripping

System-managed fields are stripped from all incoming request bodies before processing. Clients cannot set or override these values.

CORS Policy

Cross-Origin Resource Sharing is configured with an explicit allowlist of permitted origins. Requests from unlisted origins are rejected. Wildcards are not used.

Client-Provided ID Validation

Servo supports client-generated record IDs for optimistic UI patterns. All client-supplied IDs are validated server-side before use.

Fault Isolation

Unhandled application errors are caught globally, logged internally, and return a safe response to the client. Internal state and stack traces are never exposed in API responses.

Cloud Provider and Compute Isolation

Servo runs on AWS using Amazon ECS Fargate. Each container runs in its own isolated execution environment with no shared compute resources between tenants. Network traffic is controlled via VPC security groups. Container images are pulled from a private ECR registry.

Least-Privilege IAM

ECS tasks are assigned IAM roles with least-privilege access. The execution role grants only ECR image pull and CloudWatch log write permissions. The task role grants only the specific S3 and database access the application requires — no administrative AWS permissions are granted to running application containers.

Database Security

The production database uses connection pooling to prevent resource exhaustion. Schema migrations are managed with automated tooling and tracked in version control. Credentials are never hardcoded — they are loaded from encrypted environment configuration at runtime.

Session Store

Session and temporary authentication state is held in an isolated, authenticated store per environment. Temporary tokens expire automatically and are invalidated immediately upon use.

Automated Pre-Commit Enforcement

A suite of automated checks runs before every commit, catching security-relevant issues before they reach the repository. Commits that violate these rules are rejected locally without requiring a CI round-trip.

Protected Code History

The repository enforces a merge-only workflow. History rewrites are blocked and cannot be bypassed, protecting the integrity of the code change audit trail.

Dependency Pinning

All dependencies are pinned to exact versions, ensuring reproducible builds and preventing unintended dependency drift.

Observability and Anomaly Detection

All application activity is instrumented with distributed tracing. Every request is tagged with a correlation ID, tenant context, and user identity throughout the full trace. This provides complete observability into system behavior and enables detection of anomalous activity patterns.

Sensitive Data

Servo handles personally identifiable information (PII) including names, email addresses, phone numbers, and IP addresses as part of normal platform operation. Passwords are never stored — authentication is delegated to WorkOS. Third-party credentials (API keys, tokens) are encrypted at rest using AES-256 before storage.

Data Residency

Customer data is stored in AWS infrastructure in the United States (us-east-1 region). Data is not transferred to other regions without explicit configuration.

Timestamps

All timestamps are stored and returned in UTC, ensuring consistent time representation across the system.