Platform
Security
AI agents are a new kind of software. They execute code, browse the web, process untrusted input, and hold accumulated professional judgment. The threat model is different from traditional SaaS. Here's how Vessel's architecture addresses each layer of risk.
The threat landscape
The OWASP Top 10 for Agentic Applications (developed by 100+ security researchers, published December 2025) identifies the risks specific to AI agents. Not all of them apply equally to every deployment. But the ones that do are serious.
Agent goal hijack
Prompt injection redirects your agent’s objective. The top risk identified by OWASP for agentic applications.
Tool misuse
An agent with file access, browser, and shell can be tricked into actions the user never intended. CVE-2025-53773 (GitHub Copilot) enabled remote code execution via prompt injection in source code comments.
Identity and privilege abuse
Agents inherit credentials. If a shared platform is compromised, every tenant’s credentials are at risk. Separation of service accounts is the mitigation.
Supply chain
Malicious MCP servers, tool poisoning, dependency confusion. Of 1,899 MCP servers analyzed, 5.5% exhibited tool poisoning characteristics. CVE-2025-6514 (mcp-remote, 437K+ downloads) enabled full RCE.
Unexpected code execution
Agents that generate and run code can execute attacker-controlled payloads. Container escapes (CVE-2024-21626, CVE-2025-9074) turn this into host-level compromise on shared infrastructure.
Memory poisoning
Persistent corruption of agent memory. The MINJA attack achieved 95%+ injection success rates through query-only interaction. Poisoned instructions persist across sessions.
Sources: OWASP Agentic Top 10, CVE-2025-53773, MINJA, Kaspersky MCP analysis
Why architecture matters more than features
Prompt-level rules crumble under indirect injection. Regex fences get bypassed. The security community is converging on one principle: control belongs at the architecture boundary, enforced by systems, not by instructions.
Meta's security team formalized this as the Agents Rule of Two: an agent should never simultaneously process untrusted input, access sensitive data, and communicate externally. If it must do all three, it needs human supervision. The boundary has to be architectural, not a prompt instruction.
Vessel's architecture enforces this at the infrastructure level. Your agent runs on its own VM with its own kernel. The blast radius of any compromise is one machine, one client.
What Vessel does about each risk
Not every risk has a complete solution. We're honest about what we mitigate, what we contain, and what remains an open problem.
Prompt injection
Contained, not solvedNo platform has solved prompt injection. OpenAI has acknowledged it “is unlikely to ever be fully solved.” What we can do is contain the blast radius. On shared infrastructure, a successful injection against one tenant can affect others. On a dedicated VM, the damage is limited to one machine, one client. Your data doesn't leak to other tenants because there are no other tenants.
Container and sandbox escapes
Eliminated by architectureMost AI platforms run agents in shared containers. Container escapes are not hypothetical: CVE-2024-21626 (runc, January 2024) was found in 60% of cloud environments.CVE-2025-9074 (Docker, CVSS 9.3) and CVE-2025-23266 (“NVIDIAScape,” CVSS 9.0, three-line exploit) followed in 2025. On Vessel, there's nothing to escape into. Each agent runs on a dedicated VM with its own kernel. A container escape hits bare metal, not another customer's data.
Memory and context poisoning
Cross-client contamination eliminatedOn shared platforms, a poisoned memory entry can affect every user on the same instance. On Vessel, each client's agent memory lives on a separate machine. There's no shared memory store to poison across tenants. Within a single agent, memory poisoning remains an open research problem ( researchers found that even advanced detectors miss 66% of poisoned entries), but the blast radius is limited to one vessel.
Supply chain attacks
Impact contained per vesselA malicious MCP server or poisoned tool can compromise an agent. Isolation limits the impact to one VM. The compromised vessel can't reach other vessels (no cross-VM traffic), can't access Vessel's database, and can't escalate to project-wide permissions. The agent runtime (OpenClaw) is open source, so the code running on your machine is inspectable.
Identity and privilege abuse
Separated by architectureFour separate service accounts with distinct privilege boundaries. VMs cannot access the database, the API token, or the service role key. Secret Manager IAM is conditioned to specific prefixes. The VM's service account has exactly two permissions: write logs and read its own tokens.
Network architecture
Your vessel has no front door. No public IP, no open ports, no SSH. Inbound traffic reaches your agent through a single encrypted Cloudflare Tunnel. Outbound traffic goes through a managed Cloud NAT gateway.
You (browser / messaging app)
Cloudflare Tunnel
Encrypted, authenticated, DNS-based
Your Vessel (dedicated VM)
Cloud NAT (outbound only)
LLM APIs, web browsing, messaging channels
No public IP
Your VM has no publicly routable IP address. It cannot be found by scanning the internet.
No SSH access
Port 22 is blocked by firewall rules. There is no standing remote access to your machine.
Tunnel-only inbound
All inbound access goes through an encrypted Cloudflare Tunnel. The connection is DNS-based and authenticated per vessel.
No cross-VM traffic
Firewall rules prevent VM-to-VM communication. A compromised vessel cannot reach other vessels.
Minimal service account
The VM runs with two permissions: log writing and secret access for its own tokens. No project-wide admin. IAM conditions scoped to specific secret prefixes.
One-time provision tokens
The token used to activate your vessel is SHA-256 hashed in the database, used once during boot, then destroyed. It cannot be reused or replayed.
For the full argument on why dedicated VM isolation matters and how it compares to shared containers, see our isolation deep-dive.
Automated monitoring
Coming soonWe're building a sidecar watchdog that runs alongside your agent. It will monitor health, apply updates, and report diagnostics automatically.
Health checks every 5 minutes
The watchdog will verify your agent is responsive and the VM is reachable. Three consecutive failures will trigger an automatic restart.
Daily updates with safe rollback
OpenClaw updates applied automatically. If the update fails health checks, the previous version is restored immediately.
Daily health digest
Full morning diagnostic: container status, HTTP health, disk usage, resource consumption, tunnel connectivity, and overnight update results.
Where your data lives
Your agent's memory, files, and configuration live on your dedicated VM. Plain files on disk, inspectable and exportable. Not locked in a proprietary format.
On your VM
Agent memory, files, config, corrections, workspace data
In transit
Inference requests to LLM API (encrypted, API terms, no training)
On our side
Vessel metadata, event logs, billing. No agent data, no prompts, no files.
When your agent processes a request, inference goes to the LLM provider's API. All major providers (Anthropic, OpenAI, Google) commit to not training on API data by default. Anthropic retains API logs for 7 days, then deletes them. This is fundamentally different from consumer terms, where your data may be used for training unless you opt out.
For more on data ownership, training policies, and what the courts are saying about AI and professional privilege, see who owns your agent's knowledge.
Audit trail
Your vessel maintains audit trails at two levels: infrastructure events tracked by Vessel's console, and agent activity tracked by OpenClaw on your machine.
For professionals in regulated industries, this matters. FINRA's 2026 oversight report expects firms to establish a supervision and governance framework with comprehensive documentation for generative AI. If a regulator asks “when was this AI running, what did it do, and who reviewed the output?” you need answers at both levels.
Infrastructure events (Vessel console)
Every lifecycle event is recorded with timestamps and structured metadata: provisioning, activation, status changes, errors, destruction. Events are append-only. This log answers “when was the vessel running and what was its status?”
Agent activity (OpenClaw on your vessel)
OpenClaw maintains detailed records of your agent's work, stored locally on your VM. You access these through the OpenClaw interface at your vessel's tunnel URL:
- Conversation transcripts. Full session history in append-only format. Every message, every response, timestamped.
- Memory and learning logs. Daily records of what your agent learned, which corrections it absorbed, and how its knowledge evolved over time.
- Token usage and costs. Per-session breakdowns of model usage, so you know exactly what your agent consumed.
- Task and cron history. Records of scheduled tasks, their execution status, and outputs.
Infrastructure event log / example
Because your vessel is a dedicated machine, all agent activity data stays on your VM. It's not aggregated with other customers, not accessible to Vessel, and not sent anywhere except the LLM API for inference (under API terms that prohibit training). The audit trail is yours.
What we're building next: bulk export of agent activity data for compliance archival, and dashboard integration so you can browse session history without opening the OpenClaw interface separately.
Resource guardrails
Hard limits prevent runaway resource consumption. Enforced at the platform level.
Vessel limit
Maximum 3 active vessels per workspace. Prevents runaway costs. Adjustable for teams with specific requirements.
Rate limiting
Provisioning and webhook endpoints are rate-limited server-side. Applied per IP and per workspace. Rate limiters are currently in-memory, which constrains horizontal scaling.
Your responsibility
You are responsible for output. Your agent handles production. You handle judgment. Every draft, report, and recommendation is a proposal for your review, not a finished deliverable.
Prompt injection is unsolved. We contain the blast radius to one VM, one client. But we can't prevent your agent from being tricked by malicious content it encounters. No platform can, yet.
Inference leaves your machine. When your agent thinks, the request goes to the LLM provider's API. It's processed under API terms that don't train on your inputs. But the data does leave your VM during inference.
No SOC 2 certification yet. We describe our architecture precisely so you can evaluate it yourself. SOC 2 Type II is on our roadmap.
See how vessels are provisioned and managed, learn about OpenClaw, the agent runtime, read the case for dedicated VM isolation, or check your OpenClaw instance for free, scan a ClawHub skill before installing, or generate a hardened config.
