Zero-Trust Agent Runtime#

Runabot is a zero-trust runtime for AI agents, developer workspaces, CI/CD jobs, and package build environments. It deploys and manages useful workloads while keeping real credentials and broad network access out of the runtime.

The runtime is meant for AI agents, developer workspaces, CI/CD jobs, and package build environments that need external dependencies without exposing real tokens.

Design Goal#

Runabot assumes that agents will read hostile content, run imperfect tools, and sometimes be manipulated by prompt injection or compromised dependencies.

The runtime is therefore designed so a compromised agent has as little useful material as possible:

• no real upstream credentials in the container
• no open internet access by default
• no broad tool access by default
• no network access
• no silent use of unmanaged external systems

Proxy-Centered Architecture#

Access to important systems goes through dedicated proxies.

flowchart LR
    Agent["Agent runtime<br/>scoped Runabot token"]
    Proxy["Runabot proxy<br/>authn, authz,<br/>inspection, audit"]
    Secret["Real upstream credential<br/>outside the agent"]
    System["External or internal system<br/>Git, MCP, LLM, web, API"]
    Telemetry["Observability backend<br/>logging, monitoring,<br/>tracing"]

    Agent -->|scoped request| Proxy
    Proxy -->|uses policy| Secret
    Proxy -->|approved request| System
    System -->|response| Proxy
    Proxy -->|logs, metrics, traces| Telemetry
    Proxy -->|filtered/logged response| Agent

The agent can use the proxy, but it cannot extract the upstream credential that the proxy uses. If the agent leaks its own token, the leaked value is useless outside without direct access to the proxy.

Control Layers#

Human-In-The-Loop Agents#

Human-in-the-loop agents are powerful because a developer can steer them interactively. They are also risky because they often need shell access, Git access, package installation, web search, and issue tracker access.

Runabot treats these agents as confined work environments:

• the developer can connect through SSH or web terminal
• the agent gets scoped Git and tool access
• network egress remains default-deny
• credentials are mediated by proxies
• backups and restore make the environment reproducible

This is a better fit for many teams than running a coding agent directly on a developer laptop with broad local credentials.

Autonomous Agents#

Autonomous agents need stricter controls because they can act without approval at each step.

Runabot’s model is to give autonomous agents narrow capability slices:

• selected tools, not whole tool servers
• selected repositories, not a whole Git organization
• selected domains, not the internet
• selected API operations, not a broad service token

The runtime should make the wrong action impossible where possible, not merely inconvenient.

Beyond Agents: Secure Development Workloads#

The same confinement model is useful outside AI agents.

Modern software development already executes large amounts of untrusted or semi-trusted code: package install scripts, build plugins, test fixtures, compiler plugins, code generators, dependency update bots, CI actions, and release automation. Supply-chain malware such as the Shai-Hulud incidents targets exactly this surface because developer and CI environments often contain valuable credentials.

Runabot can reduce that risk by running development workloads behind the same boundaries used for agents:

• IDE environments can run over SSH or web terminal with Git, package registry, issue tracker, and cloud access mediated by proxies.
• CI/CD pipelines can receive scoped proxy credentials instead of real deploy keys, cloud tokens, package publishing tokens, or Git provider tokens.
• Dependency installation and builds can run with default-deny egress, so unexpected outbound callbacks are blocked unless explicitly allowed.
• Release automation can be limited to specific repositories, package names, environments, and operations.
• Contractor or temporary developer workspaces can be provisioned with narrow access and destroyed without leaving long-lived secrets on laptops.

This changes the economics of credential theft. Malware may still execute inside a development container or CI job, but it should not find reusable upstream tokens. If it steals a Runabot proxy token, that token is valid only through the proxy, only from the intended runtime path, and only for the scoped actions allowed by policy.

The firewall adds a second barrier. Even if malware tries to exfiltrate source code or build secrets directly to an attacker-controlled host, default-deny egress can block the connection and surface the denied destination for review.

This makes Runabot a zero-trust development runtime as well as a zero-trust agent runtime.

Community And Source Access#

Integrations are too specific for one vendor to build alone. Every organization has different internal APIs, approval workflows, MCP servers, legacy systems, and audit requirements.

Runabot’s intended model is a member community: organizations can access and adapt the runtime source code for their own business needs, then contribute improvements back to the code shared with other club members. This lets members reuse the hardened foundation while adding the adapters and authorizing proxies their environments require.

The model is not classic public open source. The goal is controlled source access for member organizations, shared improvements, and collective security review without publishing the entire attack surface to the open internet.

Related Reading#

• Anthropic: Zero Trust for AI agents
• Runabot: Security Features