WorkSwarm
Trust Center - Confidential
Version 1.0
Updated 2026-05-08
Securityv1.0 · Updated 2026-05-08 · 10 pages
Security Architecture Overview
Network topology, identity architecture, data flow, key management, and audit pipeline diagrams with detailed control descriptions.
Prepared by Chief Information Security Officer, WorkSwarm, Inc.
Contents
About This Document
This document provides detailed architectural diagrams and descriptions of WorkSwarm's security infrastructure. It covers network topology, identity and access management architecture, data flow and encryption, key management hierarchy, and audit logging pipeline.
This document is intended for security architects, infrastructure teams, and auditors who need to understand WorkSwarm's defense-in-depth architecture at a technical level.
1. Network Architecture
WorkSwarm's network architecture implements a zero-trust model with multiple isolation layers.
| Layer | Component | Security Control |
|---|---|---|
| Edge | CloudFront CDN + AWS WAF | DDoS mitigation (Shield Advanced), bot filtering, geo-blocking, rate limiting, TLS 1.3 termination |
| Load balancer | Application Load Balancer (internal) | Private subnet only, health checks, connection draining, SSL/TLS re-encryption |
| Application | ECS Fargate containers | No SSH access, immutable images, runtime security (Falco), network policy enforcement |
| Service mesh | Istio with mTLS | Service-to-service authentication, traffic encryption, circuit breaking, canary routing |
| Database | RDS (PostgreSQL) + ElastiCache (Redis) | Private subnet, no public endpoint, encryption at rest, automated backups, read replicas |
| Storage | S3 with Object Lock | SSE-KMS encryption, versioning, lifecycle policies, VPC endpoint access only |
| Secrets | AWS Secrets Manager + Parameter Store | Automatic rotation, IAM-based access, audit trail, cross-account isolation |
2. Identity Architecture
WorkSwarm implements a layered identity architecture separating human users, AI agents, and service accounts.
| Identity Type | Authentication | Authorization | Audit |
|---|---|---|---|
| Human users | SSO (SAML/OIDC) + MFA required | RBAC + ABAC, tenant-scoped, workspace-scoped | Full session audit, action-level logging |
| AI agents | Service tokens with tenant binding | Permission manifest per agent type, tool-level ACL | Every action logged with prompt context |
| Service accounts | IAM roles with assume-role | Least privilege per service, no cross-tenant access | CloudTrail, service mesh telemetry |
| API consumers | OAuth 2.0 + API key + IP allowlist | Scope-limited tokens, rate-limited | Request-level logging with correlation ID |
| Admin (break-glass) | Dual-approval + time-limited + MFA | JIT elevation, auto-expiry after 4 hours | All actions flagged, reviewed within 24h |
3. Data Flow Architecture
Data flows through WorkSwarm with encryption, validation, and access controls at every boundary.
- •Ingress: Customer data enters via TLS 1.3 encrypted HTTPS. WAF inspects for injection attacks. Request authenticated and authorized before processing.
- •Processing: Application layer processes in isolated containers. PII detected and redacted before LLM calls. Prompts sent to LLM provider over encrypted channel. Responses validated against schema and content policy.
- •Storage: Data encrypted with tenant-specific keys (AES-256-GCM) before write. Region-pinned storage prevents cross-region writes. Backup replication uses separate encryption keys.
- •Egress: Outbound data (webhooks, integrations, exports) encrypted in transit. Data loss prevention checks prevent ePHI/PII leakage. All egress logged and auditable.
- •AI pipeline: Prompts → PII redaction → encrypted transport → LLM provider → response validation → content filtering → output delivery. No customer data retained by LLM provider per DPA.
4. Key Management Hierarchy
WorkSwarm implements a hierarchical key management system with clear separation of duties.
| Key Level | Purpose | Storage | Rotation | Access |
|---|---|---|---|---|
| Master key (CMK) | Encrypts data encryption keys | AWS KMS (HSM-backed, FIPS 140-2 Level 3) | Annual automatic rotation | WorkSwarm infrastructure only (Cloud) / Customer KMS (BYOK) / Customer HSM (HYOK) |
| Data encryption key (DEK) | Encrypts tenant data at rest | Encrypted envelope stored with data | Per-write unique DEK (envelope encryption) | Decrypt requires CMK access |
| Transport key | TLS session keys | In-memory, ephemeral | Per-session (perfect forward secrecy) | Negotiated per connection |
| Signing key | Audit log signatures | HSM-backed, separate key hierarchy | 2-year rotation with overlap period | Sign-only access for audit service |
| API token key | Token signing and verification | Secrets Manager, rotated | 90-day rotation enforced | Auth service only |
5. Audit Logging Pipeline
Every security-relevant event flows through an immutable logging pipeline.
- •Event capture: Application, infrastructure, identity, and AI events captured at source. Structured JSON format with correlation IDs. Microsecond timestamps synchronized via NTP.
- •Hash chaining: Each event includes SHA-256 hash of the previous event. Chain integrity verified every 5 minutes. Break detection triggers P1 alert.
- •HSM signing: Event batches (every 1,000 events or 60 seconds) signed using HSM-backed RSA-4096 key. Signature provides non-repudiation.
- •Storage: Immutable S3 bucket with Object Lock (WORM). Cross-region replication for DR. 7-year retention (configurable per customer).
- •SIEM streaming: Real-time streaming to customer SIEM via Kinesis Firehose. Supported formats: CEF, OCSF, raw JSON. Supported targets: Splunk, Sentinel, Sumo Logic, Elastic, Datadog.
- •Legal admissibility: Export includes Indian Evidence Act Section 65B certificate (for Indian courts) and US FRE 901/902(13) self-authentication declaration.
6. Tenant Isolation Architecture
WorkSwarm enforces strict logical tenant isolation at every layer.
| Layer | Isolation Mechanism |
|---|---|
| Database | Row-level security (RLS) with tenant ID enforced at ORM layer. Cross-tenant queries architecturally impossible without bypassing ORM. |
| Application | Tenant context injected at request ingress, propagated via thread-local storage. All downstream queries scoped to tenant. |
| Encryption | Per-tenant encryption keys. Tenant A's key cannot decrypt Tenant B's data. |
| Network | Shared infrastructure with logical isolation. Private deployment option: dedicated VPC per tenant. |
| AI agents | Agent context bound to tenant at creation. Cross-tenant tool invocation blocked at permission layer. |
| Audit logs | Tenant-scoped log partitions. Customer can only export their own tenant's logs. |
| Backups | Tenant-scoped backup restoration. Cannot restore Tenant A's backup into Tenant B's namespace. |
7. Contact
For architecture-specific questions or to schedule a security architecture review:
Security Architecture: security@workswarm.ai
Trust Center: trust@workswarm.ai
Disclaimer:This document is provided for informational purposes and represents WorkSwarm's current security posture and planned controls. Legal templates are provided as starting points and should be reviewed by your legal counsel before execution. Certification timelines are targets and subject to change based on auditor availability and assessment outcomes.
© 2026 WorkSwarm, Inc. · Confidential · workswarm.ai/trust
Security Architecture Overview
10 pages · PDF