Self-hosted infrastructure for a fleet of long-lived AI agents. Each agent runs in its own sandboxed container with a persistent workspace, internet access, and a pluggable driver.

Yes. Single-VM deploy on plain Docker with your own keys and data. No vendor lock-in, no per-seat SaaS tax, nothing leaves your stack.

Which agent engines (drivers) are supported?

One identical API across swappable brains: Vanilla, Opencode, Codex, and Claude Code. The driver is part of an agent's config and can be swapped anytime.

How do you keep my data and agents secure?

Every agent runs in a hardened container: read-only root filesystem, dropped capabilities, network egress filtering, and CPU/memory limits. LLM keys are stored server-side, encrypted, and never sent to the browser.

Can I watch what an agent is doing?

Yes. Every task streams over Server-Sent Events (assistant messages, tool calls, results, file changes, a live token meter), and reconnects resume where they left off.

Accounts are provisioned by admins; you self-host the stack. Use Get started, or sign in if you already have an account.

Claude Code GitHub Actions Security Checklist

A safe Claude Code GitHub Actions workflow separates untrusted analysis from privileged execution. Treat it as an agentic CI workload with code access, prompt input, tools, tokens, and possible write paths. Do not review it like a normal linter.

The core risk is the combination of four things: untrusted GitHub content, an LLM that interprets that content, tools that can change state or call APIs, and secrets or write tokens in the runner. If those four sit in the same job without guardrails, a pull request title, issue body, comment, markdown file, commit message, or hidden HTML can become operational input to an agent.

Use this checklist when a team proposes Claude Code for PR review, issue triage, automated fixes, or repository maintenance.

Start with the trust boundary

Before looking at YAML details, ask one question: what content can Claude read, and what can Claude do after reading it?

Claude Code GitHub Actions can analyze code, implement changes, and push commits when triggered by @claude or by configured automation prompts. Anthropic's examples include permissions such as contents: write, pull-requests: write, issues: write, id-token: write, and actions: read. Those permissions may be valid for some workflows, but they are not harmless defaults.

In practice, split the review into two columns:

Inputs: PR code, PR title, PR description, issue text, comments, review comments, commit messages, markdown, repository config, hidden HTML, and files checked out from a fork.
Capabilities: commenting, pushing commits, opening or editing PRs, reading Actions logs, using Bash, calling gh api, downloading files, accessing secrets, requesting cloud credentials through OIDC, or triggering deployment steps.

The safer design keeps untrusted inputs close to read-only capabilities. Privileged capabilities should sit behind an explicit gate or in a separate non-AI job.

Use the least risky trigger that still works

For fork pull requests, prefer pull_request when Claude only needs to inspect code and produce analysis. GitHub gives fork PR workflows a read-only GITHUB_TOKEN and no secrets under pull_request. That is a useful default because the job is already constrained.

Be much more careful with pull_request_target. It runs the trusted base workflow with the base repository token and secrets. That can be appropriate for trusted metadata tasks, but it becomes dangerous when the workflow checks out or executes PR-head code.

For pull_request_target and workflow_run, Anthropic recommends checking out the base branch at the workspace root. If PR files are required, check out the PR head into a subdirectory and pass it as data with --add-dir. The important distinction is that fork code should be treated as data to inspect, not as the active workflow workspace.

GitHub also changed the baseline in June 2026: actions/checkout v7 refuses common unsafe fork PR checkouts in pull_request_target and some workflow_run workflows unless allow-unsafe-pr-checkout: true is set. If a proposed Claude workflow needs that override, stop and require a specific security review. The override is a signal that the workflow is crossing into a higher-risk pattern.

Lock down permissions before testing prompts

Do not begin with prompt wording. Begin with permissions.

Set the default token permissions as low as possible, then add only the scopes the workflow actually needs. For a read-only AI analysis job, that usually means avoiding write scopes such as contents: write, pull-requests: write, and issues: write. If the job must post a comment, consider whether a separate, deterministic job can do the posting from a saved artifact.

Review these items line by line:

contents: write: allows repository changes. Do not grant it to a job that reads untrusted PR content unless the workflow has a deliberate approval gate.
pull-requests: write: allows PR comments, reviews, labels, and updates depending on API use. Treat it as a write capability, not a reporting detail.
issues: write: risky on public repositories when issue text or comments can trigger Claude.
id-token: write: enables OIDC credential flows. Use it only in jobs that truly need cloud identity, and put environment required reviewers in front of secrets or deploy paths.
Personal access tokens: avoid them in agentic jobs. They are usually broader and longer lived than the job needs.

GitHub's secure-use guidance points in the same direction: least-privilege GITHUB_TOKEN permissions, environment required reviewers for secrets, OIDC instead of long-lived cloud secrets, and CODEOWNERS review for workflow files.

Do not let broad app permissions become broad workflow permissions

The official Claude GitHub App has broad permissions across Actions, Checks, Contents, Discussions, Issues, Pull requests, Repository hooks, and Workflows. Anthropic notes that GitHub does not allow installing only a subset for that app.

That does not mean every workflow should behave as if all those permissions are acceptable. For higher-assurance repositories, use a custom GitHub App with narrower Claude Code Action permissions. This is especially important in public repositories, deployment repositories, package release repositories, and monorepos where one workflow file can affect many teams.

Treat actor allowlists as security controls

Anthropic says the action checks actor eligibility before Claude starts. Write access is required for issue and PR events, bot actors are rejected unless allowlisted, and scheduled runs skip user-authored checks.

That gate matters. Do not weaken it casually.

Anthropic marks allowed_non_write_users as risky because it bypasses the main write-access requirement. It supports *, which can turn a workflow into a public prompt surface if used badly. If a team asks for it, require very limited workflow permissions and a clear reason.

Apply the same standard to bots. Anthropic warns that allowed_bots: '*' is dangerous on public repositories because external GitHub Apps can trigger issue, comment, and review events and supply prompt content. A bot allowlist should name the specific automation identity that needs access. It should not be a wildcard.

Separate read-only AI from privileged posting

The strongest pattern in the brief is a two-job architecture:

A read-only Claude job inspects untrusted inputs and writes a structured result to an artifact.
A separate non-AI job reads that artifact and posts the PR review, updates labels, or performs the approved write action.

This design limits the blast radius. If prompt injection succeeds against the AI job, the compromised job still lacks the token needed to write to PRs, push commits, or reach secrets. The posting job should be deterministic: validate the artifact shape, reject unexpected fields, and post only the expected content.

This pattern is not as convenient as giving Claude pull-requests: write directly, but it matches the actual risk model. The agent can still be useful without holding every credential at the moment it reads hostile input.

Narrow Claude's tools

Tool access is where prompt injection turns into action. A workflow that lets Claude read text is one thing. A workflow that lets Claude run generic Bash, call gh api, use pipes and heredocs, download remote scripts, or write commits is a different system.

Review the tool list as carefully as the token list. Remove tools that are not required for the job. Prefer specific APIs or MCP-style tools for review comments over broad shell commands. Community reports in the brief show Bash guards blocking gh api POST, pipes, heredocs, and multiline comment commands. That friction points to a useful rule: if the workflow needs to post a review, a narrow posting interface is easier to reason about than a general shell.

For jobs that inspect fork PR code, pay special attention to subprocess behavior. A July 2026 issue argued that the recommended --add-dir pattern still needs credential isolation because fork PR code can attempt environment-variable exfiltration through Bash subprocesses. The practical answer is to avoid putting valuable environment variables in the AI job in the first place.

Pin the supply chain and assign owners

Pin third-party actions by full-length commit SHA, not only by tag. GitHub recommends full-SHA pinning because it gives immutability. The tradeoff is patch velocity, so pair SHA pins with Dependabot or an internal update workflow that refreshes pins after review.

At minimum, require:

Full-length commit SHA pins for actions.
CODEOWNERS coverage for .github/workflows/.
Review from a platform or security owner before adding Claude write permissions.
CodeQL or equivalent checks for workflow vulnerabilities.
OpenSSF Scorecards or a similar repository hygiene signal for critical repos.

Also check the Claude Code version path. The GitHub advisory GHSA-xq4m-mc3c-vvg3, also tracked as CVE-2025-66032, lists affected @anthropic-ai/claude-code versions below 1.0.93. The patched version is 1.0.93, with a CVSS v4 score of 8.7. If the workflow depends on Claude Code packages directly or through an action wrapper, make sure the update mechanism is visible.

Filter prompt inputs, but do not rely on filtering alone

Prompt filtering helps, especially in public repositories. Limit whose comments enter Claude's prompt. Be explicit about whether issue comments, PR comments, review comments, bot comments, markdown, and hidden HTML are included.

One maintainer asked for clearer documentation of include_comments_by_actor because security docs discussed hidden markdown prompt injection but did not explain comment filtering enough. That is the right instinct. Public repositories need direct control over whose words become model context.

Still, filtering is a secondary control. The primary control is architecture: untrusted text should not share a job with secrets, broad write tokens, generic shell access, and deployment authority.

Use research data to set the review bar

This is not a theoretical category. A 2026 preprint on agentic workflow injection analyzed 13,392 workflows across 10,792 repositories. It reported 519 potential vulnerabilities, 496 confirmed exploitable vulnerabilities, and 95.6% precision.

Another 2026 preprint, GitInject, tested real AI-powered CI/CD workflows across four AI providers and reported that all tested providers were susceptible to at least one default attack class.

Preprints are not the same as settled standards, but the numbers are enough to justify a higher review bar. A Claude workflow with write permissions should go through the same kind of review you would apply to a release workflow or deployment credential change.