Pricing
Credits are deducted every 5 minutes while your instance is running. The total rate depends on two things: compute (always charged) and model API usage (only when using Tropic's API key).
Compute cost
| Instance type | Credits / hour |
|---|---|
| t3.micro | 5 cr/hr |
| t3.small | 15 cr/hr |
Charged regardless of whether you bring your own API key. Default instance is t3.micro. You can change this in Settings.
Model API cost (Tropic key only)
If you use Tropic's built-in API key instead of your own, the following model rate is added on top of compute:
| Model | Credits / hour | Total with t3.micro |
|---|---|---|
| Claude Opus 4.6 | 100 cr/hr | 105 cr/hr |
| Claude Sonnet 4.6 | 50 cr/hr | 55 cr/hr |
| Claude Haiku 4.5 | 20 cr/hr | 25 cr/hr |
Bring your own key
Add your own Anthropic API key in Settings → Credentials to pay only the compute cost (5 cr/hr). Model API usage goes directly to your Anthropic account at their standard rates.
Credit packages
1,000 credits = $25. Purchase from the Credits page. At the default rate (Sonnet + t3.micro = 55 cr/hr), 1,000 credits gives you roughly 18 hours of runtime. With your own key (5 cr/hr compute only), the same 1,000 credits lasts 200 hours.
Security
Every user gets their own EC2 instance. Your OpenClaw process, credentials, browser, and chat history are completely isolated from every other user. Nothing is shared.
No public ports
By default, no ports on your VM are exposed to the public internet. HTTP access is locked to Tropic's reverse proxy IPs. SSH is restricted to your detected IP at provision time.
18789 (the OpenClaw gateway) is never publicly accessible. All gateway traffic goes through Tropic's proxy with Clerk auth. If you see guides telling you to open 18789 to your own IP, don't.Referer validation
Nginx on your VM blocks direct requests to /chat. Only requests with a tropic.bot referer get through. Even if someone knows your VM's IP, they can't hit the gateway directly.
# Direct request — blocked with 403 curl http://your-vm-ip/chat # Request via Tropic — allowed curl -H "Referer: https://tropic.bot" http://your-vm-ip/chat
X-Frame-Options and Content-Security-Policy headers are stripped only on the proxied gateway path so the OpenClaw UI can load inside Tropic's iframe. All other responses keep their default headers.
Encrypted credentials
Credentials are encrypted at the application layer before being stored in Supabase. Nothing is stored in plaintext.
Sondera
Sondera is a pre-execution decision gate deployed automatically during VM provisioning as a native OpenClaw plugin. It intercepts every tool call before it runs, redacts secrets from output, and logs all executions for audit.
Cedar policy evaluation
Every tool call is evaluated against Cedar policies before execution. Tool name and parameters are mapped to principal/action/resource triples and checked against permit and forbid rules. If denied, the tool call is blocked with a policy reason. Fail-closed: evaluation errors result in deny.
Policy packs
Three Cedar policy packs ship with Sondera. The base pack is enabled by default; system and OWASP packs are opt-in via plugin config.
- Base pack (41 rules) — dangerous commands, sensitive file protection, network restrictions, secret redaction
- System pack (24 rules) — OpenClaw workspace files, credentials, sessions, plugin manifests, IDE config
- OWASP pack (38 rules) — OWASP Top 10 for Agentic Apps: goal hijack, tool misuse, supply chain, rogue agents
Output redaction
Tool results are scanned before persistence. API keys (AWS, GitHub, Anthropic, OpenAI, Stripe), private keys, JWTs, and bearer tokens are replaced with [REDACTED BY SONDERA POLICY]. Both Cedar policy-based and regex pattern-based redaction run as defense in depth.
Audit logging
All tool executions are logged to ~/.openclaw/.sondera/audit.log with timestamps, tool names, decision (ALLOW/DENY/REDACT), duration, and errors. Entries are JSON-lines format.
Example Cedar policy
// Block recursive force-delete
@id("sondera-deny-rm-rf")
forbid(
principal,
action == Action::"tool_call",
resource == Tool::"Bash"
) when {
context.command like "*rm *-rf*"
};
// Redact AWS keys from output
@id("sondera-redact-aws-keys")
forbid(
principal,
action == Action::"tool_result",
resource
) when {
context.output like "*AKIA*"
};Toggle Sondera
Enable or disable via the Skills Marketplace drawer on your machine card. Sondera is instance-wide — all agents on the machine share the same Sondera gate.
SecureClaw
SecureClaw provides baseline auditing and hardening for your VM. It tells you whether the box is safe to host an agent: 56 audit checks, 15 behavioral rules, 9 automation scripts, mapped to 7 security frameworks.
When it runs
| Trigger | What happens |
|---|---|
| VM provisioning | Auto-hardening + baseline audit |
| Agent deploy | Re-audit with timestamped results |
| Continuous | Daily audit (Rule 6) + 12h integrity check (Rule 7) |
What it checks
Gateway binding, authentication, file permissions, credential exposure, sandbox mode, supply chain scanning, memory integrity, browser relay exposure, DM policy, privacy directives, and kill switch availability.
Severity levels: CRIT / HIGH / MED / PASS with a posture score from 0–100.
Audit log locations
| Log | Path |
|---|---|
| Provision audit | ~/.openclaw/.secureclaw/provision-audit.txt |
| Deploy audits | ~/.openclaw/.secureclaw/deploy-audit-*.txt |
| Incident events | ~/.openclaw/.secureclaw/events.log |
| Integrity baselines | ~/.openclaw/.secureclaw/baselines/ |
Manual commands
SSH into your VM and run these directly:
# Run a manual audit bash ~/.openclaw/skills/secureclaw/scripts/quick-audit.sh # Emergency response (7-point diagnostic with auto-logging) bash ~/.openclaw/skills/secureclaw/scripts/emergency-response.sh
How Sondera + SecureClaw work together
SecureClaw answers “is the box safe?” — infrastructure baseline, hardening, and continuous audit. Sondera answers “is this action safe?” — runtime pre-execution gate. Together they cover deployment-time hardening and runtime enforcement.
Infrastructure
VM specs
| Instance | t3.micro (default) / t3.small |
| CPU / RAM | 2 vCPU, 1 GB + 2 GB swap |
| Storage | 20 GB gp3 EBS |
| OS | Ubuntu 22.04 + XFCE |
| Regions | us-east-1 · ap-southeast-1 · eu-west-1 · eu-west-2 |
VMs launch from a custom AMI built with Packer. OpenClaw, Node.js 22, Chrome (headed), Nginx, and the SSM Agent are pre-installed, so your instance is ready in under 2 minutes instead of 10+.
Nginx reverse proxy
Nginx listens on port 80 and proxies to the OpenClaw gateway on 18789. WebSocket connections are supported with a 1-hour read/write timeout for long-running sessions.
Systemd services
Core processes run as systemd services with automatic restart on failure. You shouldn't need to touch these directly, but if you SSH in:
# Check status sudo systemctl status openclaw-gateway sudo systemctl status chrome-headed sudo systemctl status nginx # Restart the gateway sudo systemctl restart openclaw-gateway
Disabled Ubuntu services
To maximise available RAM on t3.micro (914 MB), the following default Ubuntu services are disabled at provisioning time. None are required on a headless AI agent server:
| Service | Why disabled | RAM saved |
|---|---|---|
| apt-daily.timer | Automatic apt updates compete for CPU/RAM at boot | ~100 MB |
| unattended-upgrades | Background package upgrades | — |
| multipathd | SAN multipath storage — not needed for EBS | ~27 MB |
| pipewire / rtkit-daemon | Audio stack — headless server | ~20 MB |
| packagekit | GUI package manager daemon | ~6 MB |
| udisks2 | Desktop disk management | ~6 MB |
| avahi-daemon | mDNS/Bonjour discovery | ~2 MB |
Total: ~65 MB freed. The gateway needs ~600 MB heap to start, so every MB matters on a 1 GB box.
Tropic uses AWS Systems Manager (SSM) for management operations — syncing API keys, reading config, restarting services. No SSH tunnel is needed for any of this. SSH access is a separate thing, for your use.
Network rules
Inbound
| Port | Source | Why |
|---|---|---|
| 22 | Your IP only | SSH |
| 80 | Tropic proxy IPs | Nginx reverse proxy |
| 443 | Tropic proxy IPs | HTTPS |
| 18789 | Tropic proxy IPs | Gateway (proxied, never public) |
All outbound traffic is allowed. Your VM can reach any external API, website, or service — OpenClaw needs this to browse the web, call APIs, and send messages.
On every provision, Tropic revokes all existing ingress rules and re-applies the correct set from scratch. Stale rules don't accumulate.
Policies
Policies are security guardrails that control what an agent can and can't do. Each agent can have one policy attached. Policies use a simple plain-text rules format with three directives.
Rule directives
| Directive | Behavior |
|---|---|
| ALLOW | Agent can perform this action freely |
| REQUIRE CONFIRM | Action pauses and waits for your approval before executing |
| DENY | Action is blocked entirely |
ALLOW: browse any public website ALLOW: read files in workspace directory ALLOW: execute code in sandbox environment REQUIRE CONFIRM: download files larger than 10MB REQUIRE CONFIRM: send WhatsApp messages DENY: access /etc/passwd or system credentials DENY: run sudo or elevated commands DENY: outbound connections on port 22
How policies attach to agents
There are three ways a policy gets connected to an agent:
- At deploy time — select a policy when deploying from the marketplace
- After deployment — click the shield icon on any agent card to change its policy
- From scratch — create a new policy with custom ALLOW / REQUIRE CONFIRM / DENY rules
See the API Reference for full endpoint documentation with request/response examples.
Agents
Agents are AI assistants deployed from marketplace templates onto your VM. Each agent runs in its own isolated workspace with a configured model, skills, and optional security policy. You can run up to 5 agents concurrently.
Agent lifecycle
Deploy ──▶ [provisioning] ──▶ VM push via SSM ──▶ [ready]
│
Stop │
▼
[stopped]
If VM is offline when you deploy, the agent stays in
[provisioning] and auto-pushes when the VM starts.What gets deployed
When you deploy an agent, Tropic pushes these files to your VM via SSM:
- •
/home/ubuntu/.openclaw/workspace/<slug>/— workspace files (AGENTS.md, TOOLS.md, etc.) - •
/home/ubuntu/.openclaw/openclaw.json— agent registered in orchestrator config
Policy rules are embedded in the agent configuration and enforced at runtime.
See the API Reference for full endpoint documentation with request/response examples.
Settings
Command Blacklist
Control what your agent can execute on your VM. Each toggle restricts a category of commands:
| Toggle | When enabled |
|---|---|
| Browser Search | Restricts web browsing (Chrome, Chromium) |
| Code Execution | Restricts Python/Node scripts and dev tools |
| OS Commands | Restricts shell access and file system commands |
Toggles are off by default (all commands allowed). Enable them to restrict categories you don't want your agent using.
Set spending limits
Set a daily credit cap and a max session runtime. Once either limit is hit, OpenClaw pauses until the next day or until you raise it. You probably want both set unless you're actively testing.
Change your model
Pick from the preset list or enter a custom provider + model ID. This applies to all conversations on your instance.
Install skills
Browse and install skills from the marketplace. Installed skills are deployed to your agent machines automatically. You can enable, disable, or uninstall skills from the skills drawer on any instance card.
Manage SSH access
Your current IP is auto-detected at provision time. You can update the allowlist from settings whenever you need to.
Restrict phone numbers
Three modes: unrestricted, allowlist, or blocklist. Numbers use E.164 format. Wildcards work:
+6591234567 # exact match +65* # all Singapore numbers +1415* # all San Francisco numbers +44* # all UK numbers
If you're using allowlist mode, you probably want to add your own number first before testing.
Gateway
The OpenClaw gateway runs as a systemd service (openclaw-gateway). It auto-restarts on failure and survives reboots. You can start, stop, and restart it from the VM instances page.
How authentication works
- Your Clerk JWT is verified by Tropic's proxy
- A 48-character hex gateway token is injected into the page
- The token is stored in
localStoragefor WebSocket auth - A session cookie (10-minute TTL) is set for subsequent requests
Health checks
Tropic polls your VM's nginx every 15 seconds. The logic is simple:
- • 200 response → running
- • 502/503 within 3 min of start → initializing
- • Anything else → stopped
WebSocket connections use TCP keep-alive (30s interval) with no idle timeout, so long-running sessions won't drop from inactivity.
Credentials
All credentials are encrypted before being stored in the database. Keys are synced to your VM via SSM during provisioning and on every start.
Claude API key
Encrypted in the database. Written to OpenClaw's .env on the VM during provisioning. If you update it while the VM is stopped, it'll be re-synced on next start.
SSH key pair
An Ed25519 key pair is generated per user via AWS EC2. Download the private key as a .pem file from the "Download SSH key" link on any agent machine card.
# Download your key from the agent machine card, then: chmod 600 ~/Downloads/tropic-vm-key.pem ssh -i ~/Downloads/tropic-vm-key.pem ubuntu@your-vm-ip
SSH keys rotate automatically based on your configured rotation period (30, 60, or 90 days, default 90). When a key rotates, the new public key is pushed to all your running VMs and the old private key stops working. Re-download the new key from the agent machine card. You can also regenerate your key manually at any time.
Gateway token
48-character hex token, generated during OpenClaw onboarding on the VM. Tropic reads it from openclaw.json via SSM. This authenticates WebSocket connections to the gateway.
There's also a 64-character VM API token for internal communication between Tropic and the VM. Stored as a SecureString in SSM Parameter Store. You don't need to manage this one.
Pair your account
Go to the VM instances page and click “Pair WhatsApp.” A QR code will appear — scan it with WhatsApp on your phone. The pairing happens via SSM, and the QR updates in real-time.
Restrict who your agent can message
Three modes:
- Unrestricted — agent can message anyone. Probably not what you want in production.
- Allowlist — only numbers matching your patterns. Start here.
- Blocklist — everyone except numbers on the list.
Phone number patterns are documented in Settings → Restrict phone numbers above.