Security Features#

Runabot’s security model is based on zero trust for AI agents and development workloads: no real credentials in the runtime, no default external network access, and every important tool boundary mediated by a proxy.

This page describes the user-facing security controls. For a broader product overview, see Zero-Trust Agent Runtime.

Zero Credential Exposure#

Agents should not store upstream credentials for SSH, GitHub, Azure DevOps, Salesforce, MCP servers, LLM providers, or internal business APIs.

Instead, Runabot gives the agent a scoped proxy credential. The real upstream credential remains in the Runabot control plane or in a dedicated proxy service. The proxy validates the agent request, checks policy, and only then talks to the destination service.

This changes the blast radius of a compromise:

• a leaked agent token is not valid on the public internet
• the token can be scoped to a single proxy and a narrow set of operations
• upstream credentials can be rotated centrally without touching the agent filesystem
• access can be revoked without logging into the agent

Default-Deny Networking#

Runabot uses Kubernetes network isolation to deny external egress by default for agent and addon workloads.

Allowed destinations are explicit. Users and/or IT-administrators can manage and inspect allowlists using domains and service policies instead of giving workloads broad internet access.

This means an agent cannot quietly open arbitrary outbound connections just because it runs inside the cluster. External access is a policy decision.

MCP Proxy Pattern#

MCP gives agents a standard way to use tools, but an unrestricted MCP server can expose too much power.

Runabot’s MCP proxy pattern places a controlled boundary between the agent and downstream MCP-connected systems:

• the agent receives a Runabot-issued token that is valid only toward the proxy
• real credentials for systems such as Salesforce, Azure DevOps, GitHub, or internal APIs stay outside the agent container
• the proxy can expose only selected MCP tools to a specific agent identity
• tool access can be changed centrally without rebuilding the agent runtime

If prompt injection causes the agent to reveal its MCP token, or malware steals files from the agent container, the token is still constrained to the Runabot proxy and its assigned policy. Stolen tokens are invalid outside the Runabot container.

Git Proxy Addon#

The Git Proxy addon lets a bot access upstream Git repositories without storing upstream Git credentials directly in the bot filesystem. The bot uses a single Runabot-issued proxy token, and the proxy decides at request time whether the bot may read or write a specific Git repository path.

This reduces the blast radius of leaked credentials:

• a stolen bot token is valid only against the Runabot Git proxy
• access can be limited to selected repository paths
• read-only and read-write permissions are separated
• permissions can be changed centrally without modifying the bot filesystem

git config --global url."https://git-proxy.runa.bot/github/".insteadOf "https://github.com/"

git clone https://github.com/someorg/repo.git

git clone https://git-proxy.runa.bot/github/someorg/repo.git

Why this is useful:

• the bot can fetch source code from GitHub without having direct GitHub credentials
• the proxy can enforce read-only access even if the bot runs attacker-controlled prompts
• prompt injection cannot turn a read-only proxy rule into a write-capable GitHub credential
• a supply-chain attack inside the bot can at most reuse the Runabot proxy token against the allowed proxy paths
• outbound Git access becomes auditable and centrally revocable

This is especially helpful for coding agents that need to inspect repositories but should not be able to push code, create tags, or access unrelated repositories.

Recent supply-chain attacks show why direct credentials inside developer and agent environments are dangerous:

• Shai-Hulud Goes Open Source: Malware Code Leaked to GitHub
• Miasma Worm Hits 73 Microsoft GitHub Repositories in Major Supply Chain Attack

Web And Search Proxying#

Agents often need to read websites, search results, documentation, issue trackers, and package metadata. Those inputs are untrusted.

Runabot’s security model routes this access through controlled fetch and proxy components where responses can be inspected before entering the agent context. A secondary model or classifier can detect suspicious instructions such as:

• commands hidden inside web content
• requests to download and execute scripts
• attempts to exfiltrate secrets through URLs or tool calls
• instructions that override the user’s original goal

The point is not to make every webpage safe. The point is to keep untrusted content behind a boundary where policy, inspection, and logging can be applied.

Traceability#

Proxy-mediated access gives operators clear audit points.

For LLM traffic, Runabot can route inference requests through an LLM proxy and export request and response telemetry as OTLP-compatible traces. For Git, MCP, and web access, the same principle applies: the proxy boundary sees the request before it reaches the destination and can record what happened.

Those traces are useful for security investigations, but they are also a development tool. Data scientists and agent developers can inspect how an autonomous agent decomposed a task, which tools it called, which model responses influenced its next step, and where a workflow became slow, expensive, or unreliable.

This helps answer security questions after an incident:

• Which agent made the request?
• Which proxy credential was used?
• Which upstream system was contacted?
• Was the request read-only or write-capable?
• What response entered the agent context?

Human Policy, Automatic Enforcement#

Runabot keeps humans in control of policy while making enforcement automatic.

Operators define allowed domains, repository paths, tool exposure, and credential scopes. The runtime enforces those decisions through network policy, proxy authorization, and centrally managed credentials.

Denied connections can be surfaced to users and administrators as a concrete list of blocked destinations to review before expanding access.

Security With Deployment Simplicity#

The zero-trust controls are built into the same deployment platform used for normal bot operations:

• web UI driven provisioning
• isolated Kubernetes namespaces
• backup and restore
• SSH and web-terminal access
• addon assignment and reconfiguration
• API foundation

The goal is a strong security boundary that remains practical for teams, SMBs, and individual developers to operate.