private beta · invite-only

The secure agent platform for engineers who need agents that actually touch prod.

RunVault gives your AI agent a persistent Linux box, hooks it into Slack, Telegram, and Discord, and routes every credential through a server-side proxy. Run kubectl, hit internal APIs, ship runbooks — without leaking secrets.

Request an invite See how it works

Hosted · BYOK · audit-ready

agent@runvault:/workspace
● live
# ops 12 members
Messages Canvas Files
Today
Jess Lin 2:02 PM
@runvault any open issues on acme/api with the p0 label?
RunVault APP 2:02 PM
2 open in acme/api:
#1842 checkout returns 5xx after retry · opened 3h ago
#1838 webhook backlog growing · opened 1d ago
Want me to page on-call?
Jess Lin 2:03 PM
yes please 🙏
Message #ops
# inside the agent's sandbox agent ▸ runvault integrations add github ✓ credential stored — alias "gh-prod" ⚠ secret never written to /workspace   agent ▸ curl -H "Authorization: $GH_TOKEN" \ api.github.com/repos/acme/api/issues → proxied · token injected · response 200 OK   agent ▸ echo $GH_TOKEN (empty) — secret is never set in the sandbox env   agent ▸ runvault audit 14:02:11 tool=http actor= "#ops" ok 14:02:13 tool=shell cmd= "kubectl" ok
Works in Slack Telegram Discord Webhooks
Powered by Anthropic OpenAI Gemini MCP
The problem

Internal agents fail in predictable ways.

You've tried these. So have we. Each one solves a slice; none solves the whole.

what teams try first
approach 01

LangChain + glue

Six weeks of plumbing. Brittle tool calls. Nobody on the team wants to own it.

  • — No multi-user model
  • — No credential isolation
  • — You own every regression
approach 02

Dust / Lindy

Polished UI — but the agent can't kubectl get pods . Workflow tools dressed as agents.

  • — No real shell
  • — No /workspace
  • — Closed tool catalogue
approach 03

n8n / Zapier-style

Workflows are a graph of nodes. Agents are an open-ended loop. The shapes don't match.

  • — Workflow-first, not agent-first
  • — Branching gets ugly fast
  • — Limited memory
close, but solo

OpenClaw

The inspiration. A single user with a real shell — great. But built for one developer at their desk.

  • — Single-user
  • — No channels
  • — No managed audit / RBAC
How it works

Secrets stay server-side. The agent never sees them.

A credential proxy sits between the sandbox and the outside world. Three boundaries, one rule: the token never enters the agent's environment.

01

The sandbox

A real Linux box with a persistent /workspace. The agent owns it — but no credentials ever land here.

# inside the sandbox
$ echo $GH_TOKEN
(empty)
02

The proxy

Holds the credentials. Injects them server-side. Blocks any host that isn't on the per-credential allow-list.

# on the way out
Authorization: Bearer ghp_••••
↑ injected · host allow-listed
03

The audit row

Every call leaves a trail — actor, tool, target, status. Blocked attempts are logged the same way.

# every call, server-side
✓ alex · http · github.com · 200
Capabilities

A flat list. Nothing hidden behind a sales call.

Sandbox

the box

  • Persistent Linux workspace

    /workspace survives restarts. Real shell, real filesystem, real package manager.

  • CLI-native administration

    Manage integrations, schedules, members, and skills through the runvault CLI — just like the agent does.

  • MCP server support

    Plug in any MCP-compatible tool server. Existing internal tooling becomes available to the agent.

Security & governance

the rails

  • Credential proxy

    Secrets injected server-side, never in the sandbox. Per-credential hostname allow-list blocks exfiltration to attacker hosts.

  • RBAC + integration grants

    Owner / admin / member / viewer. Per-user access to specific integrations. Least privilege by default.

  • Audit everything

    Every tool call, credential use, member change, RBAC mutation — logged with actor and metadata.

Channels & surfaces

where it lives

  • Multi-channel

    Slack, Telegram, Discord, web, and webhooks. One agent, one memory — across all of them.

  • Schedules

    Cron jobs and one-shot tasks the agent owns. Daily standups, weekly cleanup, on-call rotation reports.

  • Per-message debugging

    Click any message to see the exact tool calls, token counts, latency, and full system prompt.

Models

the brains

  • Multiple providers

    Anthropic, OpenAI, Google Gemini. Switch model mid-conversation — different jobs, different brains.

  • BYOK

    Bring your own keys. Zero markup. Zero lock-in. Switch providers per conversation.

  • Versioned skills

    Skills are stored in the tenant DB, versioned and reviewable. Edit them via the CLI — every change shows up in the audit log.

CLI-native

The agent administers itself. So can you.

Everything the dashboard does, the runvault CLI does — and it lives inside the sandbox. The agent uses the same surface you do.

# add a credential the agent can use without seeing it ▸ runvault integrations add stripe ? alias › stripe-prod ? secret › ▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆▆ ? scopes › read:charges, read:customers ✓ stored — actor=alex@acme.com audit#7F11 ▸ runvault integrations grant stripe-prod --to @ops --read-only ✓ granted to 4 members
Compared

We are not a workflow tool with a chat skin.

An honest table. We've used the others — they're good at what they do; what they do is not this.

RunVaultOpenClawDust / Lindyn8n / Dify
Real Linux shell Yes Yes — —
Persistent /workspace Yes Yes — —
Server-side credential proxy Yes — — —
Slack / Telegram / Discord Yes — Yes Partial
Multi-user, RBAC, grants Yes — Partial —
Full audit log Yes Partial Partial Partial
Schedules · cron Yes — Yes Yes
BYOK (no markup) Yes Yes — Partial
Runs as a service Yes — Yes Yes
Private beta

Get an invite code.

We're onboarding a small batch of teams every week. Tell us a bit about what you'd build — we'll get back within 48 hours with a code or a polite "not yet."

By submitting, you agree to be contacted about the beta. No marketing spam.
FAQ

The questions security teams actually ask.

How does the credential proxy actually work?
When the agent makes an outbound HTTP call (or a CLI tool that wraps one), the request goes through RunVault's proxy. The proxy looks up the integration alias, checks the destination hostname against an allow-list bound to that credential, injects the secret as a header or body field on the way out, and writes a structured audit row. If the hostname doesn't match, the call is blocked before any secret is touched — so a compromised prompt can't exfiltrate tokens to an attacker-controlled host. The sandbox process never has the raw secret in its environment, on disk, or in any log it can read.
Is the workspace really persistent?
Yes. /workspace is a persistent volume that survives sandbox restarts, agent upgrades, and conversation switches. Anything outside /workspace is treated as ephemeral. Use it like a real engineer would: stash venvs, cache, scratch repos, and notes.
What's the difference between RunVault and an MCP server?
MCP is a protocol for exposing tools to an agent. RunVault speaks MCP — you can plug your existing MCP servers in. But the agent in RunVault also has a shell, a filesystem, schedules, and a CLI to manage itself. MCP is a piece; RunVault is the platform around it.
Can I self-host?
Not yet. Self-hosted sandbox runtime is on the roadmap for after GA. During beta everything runs on RunVault's infrastructure; if a self-hosted target is a hard requirement for you, mention it in the invite form and we'll keep you posted.
Do you charge a markup on model tokens?
No. BYOK from day one. You bring your Anthropic / OpenAI / Google keys, you pay them directly, you switch providers per conversation. We charge for the platform — seats and credits — not for the tokens.
How does this compare to OpenClaw?
OpenClaw was the inspiration — a single user, a real shell, an agent loop. RunVault is the team-grade version of that idea, run as a service: RBAC, multi-channel surfaces (Slack/Telegram/Discord), schedules, a credential proxy that keeps tokens out of the sandbox, and a full audit pipeline. Same primitive, different operating layer.
How does this compare to giving Claude a shell with computer use?
Computer use gives an agent a shell. RunVault gives a team a managed, audited, multi-user platform around that shell — channels, RBAC, schedules, credential isolation, and a CLI surface so the agent can run itself in production.
Private beta · invite-only

Give your team an agent that can actually touch prod.

Tell us what you'd build and we'll get back within 48 hours.

Request an invite Read the docs