Security model
Keystone treats model output, repository files, web pages, and agent reports as input that may be wrong or hostile. Its protections live in the runtime, outside the model, so they hold whatever an agent has been persuaded to do.
What Keystone enforces
Credentials stay outside the agent. On Keystone's hosted path, each agent run gets its own isolated microVM. The agent receives no cloud credentials, provider API keys, Keystone control-plane credentials, or GitHub credentials of yours. It gets two short-lived capabilities: one to check out the approved repository, and one to call its bound model session through Hub.
Agents propose, and trusted components publish. An agent's result is a proposal. After you approve it, a trusted Keystone component creates the commit, branch, and draft pull request, and Ledger performs any merge with one-use authority. Approvals covers the details.
Approvals cover exact content. Every approval binds to the digest of what was reviewed, and any change to that content voids it.
Agent claims are checked. Run rebuilds the patch from the agent's checkout, rejects commits the agent made itself, and runs the approved checks on its own.
Each run has limits. Run and Hub enforce separate limits on time, model turns, provider calls, and spending for every run.
Records are tamper-evident. Each record carries a digest and links to the record before it, so an edited or reordered history fails verification when it is read.
Work can be stopped. An andon hold stops an agent before it starts, and again before any change to shared source.
Deadlines survive a crash. On machines you enroll, the host operating system enforces each run's deadline, so a run stops on time even if the process coordinating it dies.
Current limits
| Area | Today |
|---|---|
| Repository confidentiality | A hosted agent gets a full checkout and ordinary outbound network access, so a prompt-injected agent could send repository contents elsewhere. A deployment that must prevent that needs tighter network controls. |
| Local custody | Local records are tamper-evident, and every Keystone process on a machine runs as the same operating-system user. A malicious process running as that user is outside what the records defend against. |
| Identity | Studio sign-in can federate to your identity provider, such as Microsoft Entra. The chain from a signed-in person to the agent run acting for them is still being completed, and some write paths still accept attribution supplied by the caller. |
| Hosted workers | The hosted cloud path is pre-production. |
| Review journey | Each part of review and landing has been proven, and one complete run driven by a signed-in person through Studio is still ahead. |
| Beta packages | Tester packages are unsigned, and the macOS package is not yet notarized. |
Your part
Keystone narrows what an agent can do. Deciding whether a change is right remains yours:
- Read the exact diff before you choose Accept. Keystone binds your decision to that diff, and the judgment of whether it serves your project belongs to you.
- Keep provider keys in Hub's vault, and out of repositories and prompts.
- Check
ksvantage statusfor held and uncertain work, since those are the cases Keystone leaves for a person.