Security and compliance at Willow

Willow runs on Amazon EKS with managed Postgres and Redis, in AWS regions us-east-2 (United States) and eu-central-1 (Germany). We inherit AWS's physical and environmental controls, and review their audit reports annually.

Production, staging, and development run in separate clusters with separate credentials. The production environment is separated from the corporate environment, and production data is never copied into lower environments.

Clusters and their add-ons are declared in version-controlled configuration and reconciled continuously, so drift is detected rather than discovered. Infrastructure changes follow the same review and approval path as code.

Every record is scoped to an organization, and requests carry the resolved organization identity from authentication through to storage. Our penetration tests exercise this directly by replaying one organization's resources against another's session.

Public entry points sit behind a WAF, and servers are protected by restricted security group rules that only authorized personnel can change.

The managed production database is not publicly accessible and sits in the same VPC as the cluster that uses it, so application traffic to it stays within a single VPC. Its Postgres port accepts connections only from the cluster's node and control-plane security groups and from the bastion used for operator port-forwarding over AWS Systems Manager.

TLS on every public endpoint, including the MCP gateway, the admin console, and the end-user portal, with weak cipher suites disabled.

Credentials and secrets are encrypted with AES-256-GCM using envelope encryption. Data encryption keys are wrapped by AWS KMS with automatic annual key rotation enabled, so a database copy alone cannot decrypt anything. Storage volumes and backups are encrypted independently of that.

In hybrid deployments the wrapping key lives in the customer's own KMS, and Willow holds encrypt but not decrypt permission on it. Willow can write credentials but cannot read them back, so upstream secrets stay under customer control.

Upstream credentials live in an org-scoped vault, are never returned to the browser after being stored, and every access is recorded in the audit log.

Where local credentials are used at all, passwords are hashed with scrypt. Most customers disable local credentials entirely in favour of SSO.

Audit log retention is configurable per organization, and logs can be streamed to your own SIEM or S3 bucket so your retention policy governs rather than ours.

Production components and employee devices are inventoried with a named owner, and are securely destroyed at end of life so data is not recoverable.

SAML and OIDC single sign-on against Okta, Microsoft Entra ID, Google Workspace, Auth0, Keycloak, JumpCloud, OneLogin, ADFS, and GitHub.

SCIM 2.0 provisioning and deprovisioning, so revoking a user in your directory revokes their access to every tool Willow fronts.

Administrative permissions are scope-based, with built-in owner, security, IT, and read-only roles plus customer-defined custom roles.

Sessions carry an idle timeout and a maximum lifetime, and API tokens are scoped and expiring rather than perpetual. All three were introduced in response to findings in the August 2026 penetration test and validated in its retest, so they postdate our SOC 2 observation period and were not part of that examination.

Optional IP allowlisting on both the end-user portal and the MCP gateway.

Access to production is granted by role on a need-to-work basis, requires multi-factor authentication through AWS IAM, and is audited. Permissions are recertified periodically and revoked as part of a documented termination checklist.

Support access to a customer tenant is a distinct, time-bounded identity that appears in that customer's own audit log, so you can see when we were there.

Every change is peer reviewed before merge, with automated tests and type checks required to pass in CI. Infrastructure changes follow the same path, with senior approval.

A release does not ship until peer review is complete and the automated tests and type checks pass in CI, enforced by a branch ruleset rather than by convention. Dependency vulnerabilities are monitored continuously outside the pipeline and triaged by severity; an automated security scan as a CI exit criterion is on our roadmap.

Dependencies are monitored continuously for known vulnerabilities and patched on a risk-based schedule, and every update passes the automated tests and a staging deployment before production.

An independent firm penetration tests the platform annually with full source access, and findings are remediated and retested before the engagement closes. Our most recent test closed with zero open findings.

Engineers are trained in secure coding against the OWASP Top 10, and penetration test findings are reviewed as lessons learned rather than closed silently.

Willow can inspect and block tool calls in-line for prompt injection, secret exfiltration, and PII exposure before they reach an upstream system. Our SOC 2 auditor did not examine the performance or integrity of our AI features, and says so in the report.

The optional sensor runs as a system service — a LaunchDaemon on macOS, a SYSTEM scheduled task on Windows, a systemd unit on Linux — so it can inventory AI tooling across every user profile on the device. It accepts no connections from the network: its only listener is bound to the loopback address and serves the notice an AI client sees in place of an MCP server your policy blocked. It reads the configuration, skill, plugin, hook, and agent files of AI tools, and redacts credentials on the device before anything is uploaded. It writes only its own state and logs, and the AI tool files where it applies your policy or installs Willow's hooks. It has been independently code reviewed with zero findings.

Every tool call, credential access, and administrative change is recorded with the acting identity, and is queryable and exportable.

Audit events can be forwarded to Splunk, Panther, CrowdStrike, Google SecOps, Coralogix, Loki, S3, or any webhook, with optional redaction of payload contents.

Application performance, error, and uptime monitoring with rule-based alerting to an on-call owner. Current status is published at status.withwillow.ai.

Employees are background checked as part of hiring where local law permits, with reference checks where it does not, and sign confidentiality agreements at hire.

All employees complete security awareness training at onboarding and periodically thereafter, tailored to the technical depth their role needs.

Company devices are centrally managed through a unified endpoint management agent, with disk encryption, screen lock, patch level, and malware protection enforced.

Security policies have named owners, are reviewed and approved by management annually, and are published internally where employees actually work.

Access to internal systems is granted by role from an onboarding template, reviewed periodically, and revoked through a documented offboarding checklist.

Vendors and subprocessors are risk-assessed before onboarding and reviewed periodically, including an annual review of our infrastructure provider's own audit report.

Application workloads run across multiple availability zones behind managed load balancing, with autoscaling to absorb demand spikes. The managed database runs in a multi-AZ, with a standby in a second availability zone and managed failover, on top of automated backups and point-in-time recovery.

Automated encrypted database backups with point-in-time recovery, on a rolling seven-day window, held in the same region as the tenant. The Disaster Recovery Policy states a 24-hour recovery time objective and a 24-hour recovery point objective. Recovery was exercised on November 3, 2025, in a tabletop of an EKS outage, and on February 8, 2026, when an environment was destroyed and rebuilt from declared configuration and backups with no data loss. Those exercises validated recovery rather than the stated objectives, and a documented test validating them is scheduled. The next tabletop is November 3, 2026. The annual disaster recovery test was inspected in our SOC 2 Type II examination, with no deviations noted.

A documented incident response plan with defined severities, a ticketed workflow with assigned steps, on-call ownership, executive escalation for critical incidents, and a root cause analysis within 48 hours of resolution.

Across 2026 the plan was exercised through real incidents and closed with a retained review in February, May, June, and August. These were operational incidents, not scheduled tabletops, and a scheduled tabletop of the incident response plan has not been run. The first one is scheduled within the current annual cycle. The November 3, 2025 tabletop covered business continuity and recovery rather than incident response.

We notify affected customers without undue delay, and within the timelines our DPA commits to, along with any notification the applicable privacy regulation requires.

The gateway confirms against the Willow control plane that every call is permitted before it runs. If it cannot, including when a hybrid gateway loses its connection to the control plane, the call is refused rather than let through. Guards run after that check and are additive: a detector that is unreachable returns no finding rather than blocking work, so a check that must never be skipped belongs in a condition, which fails closed by default.