Security Audit: Validating Our Claims Against the Codebase (February 2026)

Why we audit our own security claims

We have published 11 blog posts detailing Alpha Agent’s security architecture. Each one makes specific claims: secrets are KMS-encrypted, containers run read-only, there are zero inbound ports, authentication uses HMAC-SHA256 with timing-safe comparison.

Claims are only as good as their accuracy. This post documents a line-by-line audit of every security claim in our blog posts, validated against the actual codebase. We found that the vast majority of claims are accurate, identified corrections needed in resource limit documentation, and documented the rapidly evolving OpenClaw security landscape.

Audit methodology

We read all 11 security-related blog posts and extracted every specific technical claim. We then traced each claim to the implementing code: the management Lambda (management/lambda/index.mjs), Docker Compose template (docker/docker-compose.template.yaml), Dockerfile, CloudFormation template, Nginx configuration, instance setup scripts, dashboard authentication code, and desktop keychain module.

For OpenClaw platform changes, we cross-referenced CVE databases, security advisories, and the OpenClaw release changelog.

Verified claims (accurate as published)

The following claims were validated against the implementing code:

KMS encryption — Secrets are encrypted with AWS KMS before DynamoDB storage, stored in the encrypted_secrets map field, with IAM policy scoped to exactly one KMS key granting only kms:Encrypt, kms:Decrypt, and kms:GenerateDataKey. S3 .env files use server-side KMS encryption. All confirmed.

Container isolation — Read-only root filesystem (read_only: true), no-new-privileges enforcement, tmpfs at /tmp with 256MB limit, isolated bridge network per user, 127.0.0.1-only port binding, CloudWatch logging via awslogs driver. All confirmed.

Authentication — HMAC-SHA256 session verification with timingSafeEqual in both the dashboard server and management Lambda. Stripe webhook signature verification using HMAC-SHA256 with timingSafeEqual. All confirmed.

Nginx — Subdomain routing via regex, security headers (X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Strict-Transport-Security) set at both Nginx and application layers. Confirmed.

Backup sync — inotifywait-based daemon syncing workspace directories to S3 with exclusions for .env, openclaw.json, *.key, *.pem, .git/, node_modules/, .cache/. Confirmed.

Desktop secrets — Keychain storage via keytar library (macOS Keychain, Windows Credential Vault). Not plaintext files. Confirmed.

Non-root execution — Agent user (UID 1001) created in Dockerfile. Services run as agent user via privilege dropping with gosu at startup. Confirmed with clarification: the entrypoint runs as root for directory setup, then drops to agent for all services. This is standard practice for bind mount permissions.

Corrections

Container resource limits (7 blog posts affected)

The actual resource configuration in our Docker Compose template is:

deploy:
  resources:
    limits:
      memory: 3072M
      cpus: '1.0'
    reservations:
      memory: 512M
      cpus: '0.25'

Several blog posts stated “0.5 CPU cores, 1.5 GB of memory” as the container limits. One post stated “1 CPU, 512MB.” The actual limits are 1.0 CPU and 3 GB memory — more generous than published. The reservation (minimum guaranteed) is 0.25 CPU and 512 MB.

The corrected values are being updated across all affected posts.

IMDS v1 language

Our blog posts state “Instance Metadata Service v1 is disabled.” The actual implementation blocks all IMDS access from Docker containers via iptables (iptables -I DOCKER-USER -d 169.254.169.254 -j DROP), which is a stronger control than simply requiring IMDSv2. However, the EC2 launch code does not explicitly set HttpTokens: required on instance launch. The host uses IMDSv2 tokens for its own metadata requests, but IMDSv1 is not formally disabled at the instance level.

We are adding MetadataOptions: { HttpTokens: 'required' } to the EC2 launch configuration to make the published claim fully accurate.

OpenClaw security changelog

The OpenClaw platform has made significant security improvements since our blog posts were published. This section documents the changes that affect claims made in our posts.

v2026.2.19 (February 19, 2026)

• Runtime and package path containment via realpath checks
• ACP bridge session hardening with burst rate limiting
• Session refresh and idle-session reaping

v2026.2.12 (February 12, 2026) — Major security release

• 40+ security vulnerabilities patched
• SSRF protection added to gateway and OpenResponses
• Prompt injection mitigation: browser/web tool outputs treated as untrusted data
• Cron scheduler reliability fixes

v2026.1.30 (January 30, 2026)

• CVE-2026-24763 patched: command injection via PATH variable in Docker sandbox
• CVE-2026-25593 and CVE-2026-25475 patched: additional sandbox bypass vectors

v2026.1.29 (January 29, 2026)

• CVE-2026-25253 patched (CVSS 8.8): WebSocket origin validation added
• CVE-2026-25157 patched: command injection in SSH target handling
• Gateway authentication now mandatory: auth: "none" permanently removed

Ecosystem updates (February 2026)

• VirusTotal skill scanning live on ClawHub (February 7)
• Publisher identity verification required on ClawHub
• SecureClaw open-source auditing tool released (February 18) with 55 automated checks
• Code signing for skills: NOT yet implemented

What these OpenClaw fixes mean for our blog posts

Several blog posts describe OpenClaw security weaknesses that have since been addressed:

CVE-2026-25253 analysis — Our post explains that the gateway “does not validate the Origin header.” This was fixed in v2026.1.29 with origin validation. Alpha Agent’s structural protections (zero inbound gateway ports, Nginx-controlled routing, no user-facing gateway URL) remain relevant as defense-in-depth layers.

Exposed instances post — Our post notes that OpenClaw “does not require authentication by default.” This was fixed in v2026.1.29 with mandatory gateway authentication. The 135,000+ exposed instances identified by SecurityScorecard will still be at risk if operators have not updated.

Supply chain risks post — Our post states that “ClawHub skills are unsigned and unaudited.” VirusTotal scanning is now live, and identity verification is required, but cryptographic code signing is still absent. The claim requires nuancing.

We are adding update notes to each affected post acknowledging the fixes while explaining why structural mitigations remain valuable.

Desktop app version status

Alpha Agent Desktop currently ships OpenClaw 2026.2.15. The latest stable release is v2026.2.19-2. The desktop version includes all major CVE patches and the 40+ security fixes from v2026.2.12, but is missing runtime path containment and ACP bridge hardening from later releases. We are updating the desktop dependency to the latest version.

Action items from this audit

Completed:

• Identified and documented all discrepancies
• Created this transparency report

In progress:

• Updating resource limit numbers across 7 blog posts
• Adding update notes to posts describing now-fixed OpenClaw issues

Planned:

• Add MetadataOptions: { HttpTokens: 'required' } to EC2 launch code
• Add Stripe webhook timestamp staleness check (replay protection)
• Update desktop OpenClaw to v2026.2.19+
• Pin OpenClaw version in cloud Dockerfile for reproducibility
• Define security group in CloudFormation (currently referenced by external ID)
• Establish monthly security claim review cadence

The principle

Security is a practice, not a state. We will continue auditing our published claims against our actual implementation, and we will continue publishing what we find. If something is wrong, we fix both the code and the documentation. Transparency is not optional when your platform holds other people’s credentials.