Security and Privacy

How IronWorks protects your data, isolates tenants, and secures AI operations.

Tenant Isolation

Every database query in IronWorks is scoped by company_id. This is the fundamental isolation boundary. There is no shared namespace between companies — agents, issues, projects, secrets, KB pages, and budget data are all partitioned by company.

This isolation is enforced at multiple levels:

Database layer — foreign key constraints and indexes include company_id
API layer — every authenticated request resolves the company from the session and scopes all queries
Agent layer — agents receive a company-scoped JWT that restricts their API access to their own company's data

Tenant isolation is verified by 122 automated HTTP tests that run on every code change. These tests create two companies and verify that company A's agents, issues, secrets, and data are invisible to company B's API calls.

Secret Encryption

API keys and other sensitive values stored in company secrets are encrypted with AES-256-GCM:

Each company has its own master encryption key
Each secret version gets a unique initialization vector (IV)
The GCM authentication tag prevents tampering
Secrets are decrypted only at the moment of use (e.g., when the heartbeat needs to call the Anthropic API) and never cached in plaintext

Secrets are never logged, never included in agent prompts, and never returned in API responses after storage. The UI shows only the secret name and creation date, never the value.

Authentication

IronWorks uses Better Auth for human user authentication with session-based management:

Email/password registration with secure password hashing
Session tokens with configurable expiration
CSRF protection on state-changing endpoints

Agents authenticate using short-lived JWTs issued by the heartbeat service. These tokens are scoped to a specific company and agent, and expire after the execution run completes.

Role-Based Access Control (RBAC)

Human users have one of four roles per company:

Role	Can Do
Owner	Full access. Manage billing, delete company, manage all members.
Admin	Manage agents, projects, secrets. Cannot delete company or manage billing.
Member	Create issues, run playbooks, view dashboards. Cannot manage agents or secrets.
Viewer	Read-only access. Can view dashboards, issues, and KB but cannot create or modify anything.

AI Security

IronWorks includes built-in protections against common AI security risks:

Prompt Injection Protection (SEC-LLM-001)

All user-supplied text is sanitized before being interpolated into LLM prompts:

Hard maximum of 2,000 characters per input field (truncated, not rejected)
Known injection patterns are detected and stripped: "ignore previous", "ignore all", "system:", "you are now", "forget your instructions"
Sanitization is applied to issue titles, descriptions, KB page content, and any other text that enters an agent's context

Output Validation (SEC-LLM-002)

When agents generate structured output (e.g., AI-generated playbooks or goal breakdowns), the output is validated against strict Zod schemas:

Playbooks: 1-20 steps, each with required title (max 200 chars), instructions (max 2000 chars), assignee role, and dependency list
Goal breakdowns: 1-20 issues, each with title, description, priority, assignee role, and order
Prototype-poisoning keys (__proto__, constructor, prototype) are stripped from all parsed objects

Webhook Security

Polar billing webhooks are verified using HMAC-SHA256 signatures (Standard Webhooks / Svix format):

Timestamp staleness check — webhooks older than 5 minutes are rejected (replay attack prevention)
Timing-safe signature comparison to prevent timing attacks
DB-backed idempotency — each webhook event ID is stored; duplicate events are silently dropped

Data Retention and GDPR

Data processor model — IronWorks acts as a data processor. You (the customer) are the data controller.
GDPR erasure — company deletion removes all associated data: agents, issues, secrets, KB pages, run transcripts, cost records
No data sharing — your data is never used to train models, shared with third parties, or accessed by other tenants
Data Processing Agreement — available at /dpa

Infrastructure

Dedicated VDS — IronWorks runs on dedicated virtual servers (Contabo VDS), not shared cloud functions
Firewall — UFW with default-deny policy, only HTTP/HTTPS/SSH open
Fail2ban — automated IP banning for brute-force SSH and HTTP attacks
Automated backups — PostgreSQL database backups on a regular schedule
TLS everywhere — all traffic is encrypted in transit via HTTPS

Compliance Director Agent (Enterprise)

Enterprise customers get a dedicated Compliance Director AI agent that monitors data handling, tracks regulatory requirements, and creates compliance reports. The Compliance Director operates as a cross-departmental oversight role — it has read access to all agent activity, issues, goals, run transcripts, and KB pages, but cannot modify configurations or delete data.

The Compliance Director tracks these regulatory frameworks continuously:

GDPR — data subject rights, lawful processing bases, data minimization, breach notification timelines
CCPA — consumer opt-out mechanisms, sale of personal information, privacy notice requirements
SOC 2 — Security, Availability, Confidentiality, Processing Integrity, and Privacy trust service criteria
HIPAA — PHI handling obligations, covered entity and business associate requirements
PCI-DSS — cardholder data environment controls, access management, and network segmentation requirements

When the Compliance Director identifies a gap — for example, a playbook that processes data without logging it, or an agent configuration that grants permissions beyond what is needed — it creates a compliance-tagged issue and assigns it to the appropriate owner. It does not make changes itself. The separation between detection and remediation is intentional.

For a full breakdown of the Compliance Director's capabilities and permission set, see Agents and Roles.