Built for agents you can’t fully trust.
Ryph assumes any agent can be manipulated, and limits what a manipulated one can do. Credentials stay behind gateways, direct internet access goes through an allowlist, and Git changes come back as patches.1
The agent calls the model with a key that only works for this run.
What a run can reach, and what it can’t
Every run starts with only what its agent was granted, and what it does with that is on record.
No real credentials in the pod
Provider keys and tool credentials are sealed outside. Pods get tokens scoped to one run.1
Tools on an allowlist
You choose which servers and which tools each agent can use. MCP config from a repo never loads.2
Patches, not pushes
The forge gateway accepts patch bundles, never Git pushes from the pod. Ryph delivers the change to your forge.3
Limits on forge writes
Admins cap the issues, comments, reviews and closes each run can make. Every write names its agent, run and who asked, and a run holding a private repo can’t write to public ones.4
Every call on record
Model usage is metered per run, and every tool call lands in the run’s trail beside its transcript.5
Internet access you choose
Allow the package registries and hosts your agents need. The egress proxy checks each destination against the run’s frozen allowlist.6
Run-scoped access
Model, tool and forge keys are revoked when a run concludes. Internet access uses a short-lived proxy token.7
Published pages in a sandbox
Pages agents publish are cleaned when they’re published and shown in a sandbox with no origin, so a manipulated page can’t read Ryph or act as the person viewing it.8
Kill switches
Archive a provider key or MCP server, and runs using it lose access on their next call. Rotate a credential in place without restarting anything.
- The credential and patch boundary shown here applies to every repo, including one on your own machine: runs clone through the forge gateway and get no Git credential.
- Ryph’s own memory, web, chat and forge tools are available to agents by default. An agent’s tool policy can narrow them.
- Patch-only describes Git delivery through the forge gateway. Allowed tools can also post comments, change issues, send chat messages or fetch web pages, and allowed internet hosts remain reachable.
- Caps are set per agent by an admin, from 1 to 50 per action, and fixed for the run when it starts. The footer appears on issues, comments and reviews; adding a label or closing an issue without a note carries none. A run holding a private repo can still reply in the thread that started it.
- Usage and tool-call recording are best effort. Transcripts stream through a bounded retry buffer; outages, rejected batches or overflow can leave gaps, which the emitter reports when it can.
- The proxy allows hostnames, not individual URLs, on ports 80 and 443. Kubernetes enforces the route with NetworkPolicy, and confined Docker with an internal network. Allowlisted Docker keeps a direct route. Deployments can explicitly select open internet access. The built-in web search and fetch tools don’t go through the proxy: fetch reads any public HTTPS page and returns it as untrusted text. An agent’s tool policy or a deployment setting can turn them off.
- Model, MCP and forge keys are revoked on conclusion, with expiry as a backstop if revocation fails. The egress proxy token only expires: its default lifetime is 24 hours, and it is not revoked when the run ends.
- An opened page runs its own scripts, which can still reach the internet from the viewer’s browser, for example through links. The sandbox keeps a page away from Ryph and the viewer’s session, not off the network. Images in a page come only from what the run’s own tools returned.
Finished work can wait for GitHub
A GitHub or GitLab outage doesn’t have to strand finished work. Git fetches go through a pull-through cache, and accepted patches wait in a durable outbox until they can be delivered.9
- PR #418 payments-api
- PR #419 storefront
- payments-api waiting
- storefront waiting
Runs clone through the forge gateway's pull-through cache, which fetches from GitHub as it needs to.
A pull-through cache for git
Runs clone from the forge gateway’s cache, which fetches from GitHub only what it needs. Losing the cache costs a re-fetch, nothing more.
A durable patch outbox
Accepted patches are stored on disk or in S3 before Ryph submits them to GitHub.9
Retries without duplicates
Failed submissions back off and try again. A retry adopts the pull request it already opened instead of creating another.
Any replica can deliver
With the outbox in S3, a patch handed to one forge gateway replica can be submitted by any other.
- New clones still require a successful upstream refresh, and runs that already cloned need the forge to fetch, update from the base branch or use forge tools. Patch intake can avoid the forge while its base remains cached; a lost cache must be fetched again before acceptance. Retryable submissions back off for up to eight attempts, about an hour by default, then wait for a manual retry.
More of Ryph
- Incident response An agent joins the incident chat, investigates and ships the fix.
- Automations Recipes that run on a schedule or when a webhook fires.
- Forges and chat Summon an agent with /ryph on an issue, a pull request or a merge request.
- Artifacts Reports and overviews agents publish as pages your team can open.
- Memory What agents learn, shared and kept current with the code.
- Agentic CI One CI for agents and the people working with them. Pull requests open already green.
- Environments Images built for your repo, and services for every run.
- Deploy One binary on a laptop, or your own cloud.
Try it on your own machine.
One binary with the web app and database built in.
Get started