Security model

This page says what the code in a run can read and reach, what it cannot, and the settings that keep your customers' data and repositories safe. Read it before you start runs for your customers.

What a run can read and reach

Everything inside a run sandbox is readable and writable by the agent and by any code it runs: your org's Anthropic key, every run secret (a GitHub token included), inputs, the repository, the runtime's own state and event outbox, and both of the runtime's access tokens. Both tokens are valid only for that sandbox. Treat the sandbox as controlled by the repository's code from the first turn.

A run cannot reach other runs, other workspaces, Forgeling's control services, the private network or the cloud metadata server. It cannot sign webhooks, change the list of collected output files (they are collected outside the sandbox) or change hosting-time metering (measured outside the sandbox).

Events and token usage are reported by the sandbox. Events prove origin, not truth: re-read state such as the pull request's head SHA from GitHub before any irreversible action.

Deny rules are not a security boundary when Bash is allowed. A shell can edit any file a deny rule protects.

Your org's Anthropic key

The Anthropic API key you store for a workspace is readable by the agent inside every run sandbox of that workspace. There is no credential proxy in v1. Use a spend-limited Anthropic workspace key per org.

The quickstart shows where the key is stored.

Repositories without push protection

A repository whose default branch cannot be verified as blocking direct pushes (for example a private repository on GitHub Free, which cannot have rulesets or branch protection) is refused by default: the run fails with repo_policy_unmet. It may run only if an admin of your customer's org explicitly opts in, acknowledging that the agent could push straight to the default branch. The opt-in belongs to that org admin, not to the app's developer, and is recorded on every run that uses it. Forgeling cannot verify the admin: your app attests it with repo_policy_ack.

The coding-run guide shows the request, and what your app owes the admin and your users.

Private beta: shared workers

During the private beta, runs share worker machines with other customers' workloads that Forgeling hosts, and with the worker's service account, which can read those workloads' backups; a gVisor escape would reach them. This is why the private beta runs only apps the owner has approved. Public sign-up opens once runs move to an isolated pool.

Recommended settings

• A spend-limited Anthropic workspace key per org. The agent can read the key, so cap what a leak can cost.
• Short-lived, repository-scoped tokens. Give each run a GitHub token that reaches only the repository it works on and expires soon after the run needs it. The coding-run guide shows how to refresh one.
• A default branch that blocks direct pushes. Forgeling requires it, and checks it before provisioning and at every resume. The guide says how to set it up.
• A ruleset that limits branch and tag creation, so an agent can create only the branches your app expects. A ruleset to start from is in the guide.
• Never add your GitHub App to a bypass list, of a ruleset or of branch protection. The agent pushes with your App's token, so a bypass lets it push straight to the default branch, and Forgeling's check cannot see bypass lists.

Output files

A file's download URL is a signed URL on storage.googleapis.com that expires after 5 minutes. It carries the signer's address, which names the hosting project. Download each file and serve it to your users from your own storage, and never hand the signed URL on.

A purge (DELETE /v1/runs/{run} or a workspace delete with ?purge=true) removes outputs at once. Nothing is kept restorable, so a purged file cannot be brought back.

Webhooks

Webhooks are signed outside every container, so nothing running in a sandbox can sign one. A valid signature shows that a delivery came from Forgeling; it does not make an event the sandbox reported true. Verify every delivery, and rotate a secret when you suspect it has leaked.

No IP allowlisting

There is no IP allowlisting, in either direction. An API key cannot be limited to addresses, and Forgeling publishes no egress IP addresses, so you cannot allowlist its webhook deliveries or its runs by address. Runs share their egress with other apps, so an address proves nothing about who is calling. Authenticate with the API key on the way in and with the webhook signature on the way back.

API keys

• The prefix fgk_ is registered with secret scanners, so a scanner can flag a key that ends up in a repository.
• Store keys on your server, in its secret store. A key never belongs in a browser, a mobile app or a repository.
• Use restrictions. Give each key only the scopes it needs, and limit it to some workspaces where you can. Restricted keys explains how.
• Roll keys on a schedule and whenever someone who could see one leaves. A rolled key's old secret keeps working for up to 24 hours. See API keys.