Governed cloud coding agent

A coding agent your team can approve once.

Connect a repository and open a session. The agent works on an isolated machine under a policy pinned for the whole session, a hard token cap, and encrypted evidence, then hands back a pull request you review. Nothing runs on your laptop, and no credential reaches the agent.

Start with GitHub See a real session

Free for 30 days, then $19 a month per workspace. Bring your own Anthropic, OpenAI, Gemini, or Fireworks key. Open-source runtime, Apache-2.0.

A Jern Cloud session: the guarantees pinned for the session, the conversation with the agent, and an attempt that stopped to ask a question before writing code.

Pinned for the sessionRevision, policy digest, environment, model, and cap. None can change once the session opens.

Every attempt, on the recordTokens metered by the gateway, files changed, the receipt check, and encrypted evidence a click away.

It asks before it guessesWhen the task is ambiguous the agent stops, publishes what it has, and waits for your answer.

A real session

The pull request arrives with its evidence.

This session ran on Jern Cloud against the public jern-demo repository. Two messages, two attempts, one pull request, #20, on a branch owned by the session.

Session · pull request ready

Open the pull request ↗

Repository: jern-ai/jern-demo

Policy: Repository baseline, digest b2b19437

Attempts: 2 · both within cap

Changed: src/temperature.py +17 −2

Branch: jern/session-953b71f31b5e…

Pull request: #20 · Open for review

Evidence run: run_7395bd05…

Credentials in agent: None

Policy verified by digest before the agent startedTokens metered by the gateway, not self-reportedTrace encrypted before it touched a database

How a session works

Four steps. Nothing to install.

1
Connect
Install the GitHub App on the repositories you choose. Python, Node, .NET, and Java environments are detected from the repository. A protected baseline in the repository is preferred; a workspace default works until one exists.
2
Open a session
Pick a repository and describe the work. The session pins the revision, the policy, the environment, the model, and the token cap. None of them can change afterwards.
3
Watch it work
Each message becomes one attempt on a fresh isolated machine. Live activity, budget, and evidence show in the session as it runs. Interrupt at any time.
4
Review the pull request
Changes land on the session's branch as one pull request that follow-up messages keep updating. Your branch protection and reviewers apply. Jern never merges.

What is different

Guarantees you approve once, not actions you supervise all day.

Every one of these is enforced by the runtime or the control plane and shown inside the session, where a reviewer forms trust.

Policy pinned by digest

The repository's baseline decides which paths can change and which commands run without asking. The runner verifies its digest before the agent starts, and it cannot change for the life of the session.

No credential in the agent

Checkout, evidence upload, model inference, and publication each use a separate short-lived credential held by the runner. The agent process has none, and its only network route is the inference gateway.

Hard caps, metered where it counts

Tokens are counted by the gateway from the provider's own response, not by the agent. Wall clock, process count, output size, and attempts per task are capped too.

Encrypted evidence for every attempt

The exact trace is encrypted with AES-256-GCM before it reaches a database. Open it from any attempt. Retention is yours to set and is enforced automatically.

Immutable environment

The image and setup command are pinned by revision per session. A change to the environment is a new revision, never a surprise mid-session.

Review is the only exit

Work ends on an isolated branch as a pull request, or as a labelled failure. Optionally, every attempt waits for a human approval before it runs.

The policy

This is the whole policy for the demo repository.

It lives in the repository as .jern/baseline.json, is reviewed like any other change, and is pinned by digest for the life of a session. The runtime enforces the policy half; Jern Cloud provides the environment half; the runner refuses to publish anything outside it.

{
  "policy": {
    "allow": ["edit_file", "write_file", "mcp__jern__start_service"],
    "edits_within": ["src/", "tests/"],
    "memory": "allow",
    "shell_allow": ["python3 -m unittest discover -s tests -t .", "python3"]
  },
  "environment": {
    "services": ["postgres:16"],
    "network_allow": ["docs.python.org"]
  }
}

edits_within names the only paths the agent may change. Nothing outside src/ and tests/ can be written, checkpointed, or published.
shell_allow lists the commands that run without asking. In a cloud session there is nobody to ask, so anything else is denied.
allow grants tools by name; here the file edits and the one MCP tool that starts the declared database on demand. A deny in any layer wins over it.
memory lets the agent keep notes about the repository between sessions, which Jern Cloud stores encrypted and shows on the repository page.
environment is what the host provides around the agent: a Postgres the agent may start, and one public host it may fetch from through the proxy, every connection counted.

Verbatim from jern-ai/jern-demo, the file that governs every session on it, such as pull request #20 above. Setup writes a baseline like it for you; the full reference is in the policy docs.

How it compares

Hosted agents ask for trust. Jern gives you something to check.

Cursor Cloud Agents, Devin, and Codex cloud run capable agents. The difference is what you can verify afterwards, and what the agent can reach while it works.

In every session	Jern Cloud	Typical hosted agent
Policy	Repository-owned, protected by your reviewers, pinned by digest for the session	Per-run settings, changeable by whoever starts the run
Credentials in the agent	None. Checkout, inference, evidence, and publication use separate short-lived credentials outside the agent	A repository token and often a provider key in the agent's environment
Network	One route, to the inference gateway, plus only the public hosts the baseline names, each connection counted	Usually open, sometimes an allowlist
Cost control	Your own provider key, a hard cap per attempt metered from the provider's usage, a monthly workspace allowance	Bundled credits or seat pricing, usage counted by the vendor
Evidence	The exact trace, encrypted before storage, with a receipt you can replay	A transcript in the vendor's UI
Runtime	Open source, Apache-2.0. The same agent runs on your laptop	Proprietary
Delivery	One pull request per session on an isolated branch. Never merges	A pull request or a direct push, depending on settings

Comparisons describe common designs of hosted coding agents in general, not any vendor's current terms. Check the security page for what Jern does not defend against.

The boundary is the product

Isolate execution. Centralize control.

Each attempt runs on a machine created for it and destroyed afterwards. The agent lives in a private network namespace with one route: the Jern gateway, which holds the provider key, enforces the cap, and meters usage. Publication happens outside the agent, after policy and secret checks.

Read the data flow and honest limits →

Your repositorySource at a pinned revisionProtected policy baselineBranch protection and reviewersThe pull request

Isolated machine + Jern CloudAgent with no credentialsGateway holds the model keyCap enforced and meteredEvidence encrypted, then the machine is destroyed

An inspectable foundation

Trust starts in the open.

Policy enforcement, receipt derivation, trace formats, and replay live in the Apache-2.0 Jern repository. The control plane does not reinterpret what the runtime recorded, and the same runtime runs on your laptop.

Open-source runtimeUse, govern, edit, and test the agent locally. Security and data flowWhat runs where, what is encrypted, and what we do not defend against. Runtime security modelThe claim, the boundary, and its limits, in the code's own words.

One price, your own key

Priced like infrastructure, because that is what it is.

Sessions run on your own Anthropic, OpenAI, Gemini, or Fireworks key, so tokens bill to your account and never to a shared pool. Jern's price covers the control plane: the isolated machines, the gateway, the evidence, and the policy enforcement. Every new workspace gets 30 days free, no card needed. When the trial ends, sessions stay readable and new work pauses until you subscribe.

$19per workspace / month
after a 30-day free trial

Up to 10 governed repositories
Up to 10 team members
Isolated machine for every attempt, destroyed afterwards
Hard cap per attempt, metered from your provider's own usage
Encrypted evidence, 90-day retention you control
Email support from the people who built it

Start with GitHub Model usage is billed by your provider on your own account and is not included. Larger workspaces and support commitments: hello@jern.ai.

Your next pull request can arrive with evidence

Put a coding agent to work without giving up control.

Start with GitHub Read the docs Review security first