# 2ok for agents Domain-independent governance primitives for AI agents. Experimental open-source Rust foundations and a proposed independently enforced architecture. Canonical public origin: https://2ok.ai 2ok is independent, domain-neutral governance infrastructure under development, not an autonomous agent or publicly accessible execution system. WebMCP site discovery is read-only. ## Public topics - [Agents can propose. Authority lives elsewhere.](https://2ok.ai/index.md) — 2ok is a domain-neutral Rust foundation for making an agent's proposed work reviewable, authorizable and independently enforceable. The resource—not the agent—makes the final decision to act. - [For agents](https://2ok.ai/overview.md) — 2ok is reusable, domain-independent governance building blocks; a website is not an approval server. - [Architecture and contract boundaries](https://2ok.ai/architecture.md) — Intent → Verify → Authorize → Execute → Observe → Record; decision, enforcement and evidence are separate. - [Implementation roadmap](https://2ok.ai/roadmap.md) — Implemented identity/evidence foundations; planned immutable specs, independent policy, approvals, transactions, leases, orchestration. - [Deployment topologies](https://2ok.ai/deployment.md) — One versioned API across laptop, on-prem and cloud/edge placements, with candid trust assumptions. - [Operating profiles and ergonomics](https://2ok.ai/profiles.md) — Development speed, engineer-supervised sessions and managed enforcement are distinct modes. - [Interfaces and reuse decisions](https://2ok.ai/interfaces.md) — Adopt proven policy, identity and database infrastructure; keep speculative tools behind adapters. - [Current implementation status](https://2ok.ai/status.md) — Experimental Rust crates and illustrative browser demo; no production authorization or isolated execution. ## Terms explained Definitions and examples of unfamiliar terms are in [the 2ok glossary](https://2ok.ai/glossary.md). These explanations are background context, not evidence of working security services. ## Source of truth and authority The standalone Rust crates, tests and core-owned roadmap describe implemented behavior. Website descriptions of planned contracts are not live tool APIs. No credentials, approval keys, tasks or protected execution are available through this website. The core does not import any consumer application's agent instructions, backlog, licensed datasets or implementation details. See [architecture](https://github.com/x2ot/2ok/blob/main/docs/architecture.md), [independent roadmap](https://github.com/x2ot/2ok/blob/main/docs/migration-roadmap.md), and [publication boundary](https://github.com/x2ot/2ok/blob/main/docs/publication-boundary.md). --- # Agents can propose. Authority lives elsewhere. 2ok is a domain-neutral Rust foundation for making an agent's proposed work reviewable, authorizable and independently enforceable. The resource—not the agent—makes the final decision to act. Early-stage software. Two experimental Rust foundations; no live protected-execution service, authenticated approvals or production security guarantee. - 01 Propose An agent drafts an intent and an exact, reviewable change. - 02 Verify Independent evidence is checked against the intended revision. - 03 Authorize A qualified actor and policy grant narrowly scoped permission. - 04 Enforce independent authority An independent resource verifies permission and produces a receipt. Separation is a requirement of the proposed system, not a property granted by this website. ## Agents suggest changes Not trusted just because a model generated them. ## Independent systems decide Approval records and policies cannot replace enforcement. ## Outcomes must be observed A trace or simulation alone is never a verified effect. ## Composable governance. Explicit trust boundaries. Implement a small foundation before claiming a complete platform. Status reflects reviewed public work, not unfinished branches. ### Identity & delegation Validated principal records and narrowing delegation scopes; no credential issuer, hosted identity provider or runtime authorization. ### Evidence & digests Bounded evidence records, providers and versioned digests; does not establish truth, approval or protected execution. ### Specifications Immutable reviewed revisions, exact change proposals and versioned contracts. Work outside main does not advance public status. ### Approval & policy Exact-resource decisions, independent policy and verifiable human approvals. No operational approval service is exposed. ### Protected execution One-use resource-scoped leases, resource-side re-verification, receipts and uncertain-outcome recovery. ### Review checkpoints Durable task pause, independent review and safe resume; queuing a task never grants execution authority. ## Distinct profiles, explicit authority. ### Development / YOLO Normal local agent edits, builds and tests remain fast. Shadow policy is advisory; unrestricted agents on one host are not contained. ### Commissioning / engineer-directed Time-limited, target-scoped engineer sessions support rapid iteration. Engineer access never automatically delegates credentials to agents. ### Managed / production Independently controlled endpoints own credentials, verify execution leases, reject replay and record receipts. Approval is not functional safety. ## One architecture, three placements. Proposed deployment patterns, not currently shipped services. Split processes only for an actual trust or operational boundary. ### Local Windows + WSL2 + Docker Proposed APIs, identity, PostgreSQL, policy and workers in containers; native connector where needed. One laptop cannot resist full host compromise. ### Customer on-premises Same interfaces with locally managed identity and audit, independently administered connector host and segmented protected-resource network. ### Cloud + on-premises edge Core governance in the cloud when useful; protected credentials, connectivity and authoritative execution stay behind the customer-controlled edge. ## Prove one portable end-to-end slice. No second standalone platform or copied consumer backlog. Start with a synthetic resource and validate strong enforcement at the resource, not the agent prompt. - 01 Now Standalone Rust identity/delegation and evidence slices; explicit publication and boundary tests. - 02 MVP Synthetic proposal → independent verification → exact engineer approval → trusted dummy connector → receipt; reject replay/mismatch/uncertain effects. - 03 Next Immutable specification revisions and small event-backed policy/transaction API, reusing mature policy/identity/storage components. - 04 Then Passkey-backed approval and durable task pause/resume, with authoritative verification outside the agent. - 05 Proof Move connector onto independently managed hardware without changing the versioned protocol. ## Help agents discover the design, not execute it. 7 public, domain-independent topics share one manifest for standalone HTML, Markdown, llms indexes, sitemap and discovery catalog. Compatible browsers may expose optional read-only WebMCP tools for search, capabilities, roadmap, profiles and site map. The website never approves transactions, receives credentials, opens local resources or starts remote execution. Local, read-only search of the rendered site and public docs, sharing the WebMCP index. No query is sent to a server. ## Source first. Claims second. Inspect the standalone Rust foundations and their tests. Operational APIs, real human approvals and protected execution are future work and require separately controlled infrastructure. ## Public links - [Understand the architecture ↗](/architecture/) - [What is actually implemented ↗](/status/) - [View source ↗](https://github.com/x2ot/2ok) - [Full roadmap ↗](/roadmap/) - [Core-owned roadmap ↗](https://github.com/x2ot/2ok/blob/main/docs/migration-roadmap.md) - [Proposed service interfaces ↗](/interfaces/) - [agents · current For agents 2ok is reusable, domain-independent governance building blocks; a website is not an approval server.](/overview/) - [deployment · design Deployment topologies One versioned API across laptop, on-prem and cloud/edge placements, with candid trust assumptions.](/deployment/) - [security · design Operating profiles and ergonomics Development speed, engineer-supervised sessions and managed enforcement are distinct modes.](/profiles/) - [Agent entry point](/for-agents/) - [Machine-oriented Markdown](/for-agents.md) - [Compact index](/llms.txt) - [Expanded public context](/llms-full.txt) - [Discovery catalog](/.well-known/ai-catalog.json) - [HTML site map](/sitemap.xml) Status: experimental. This public page is informational, not operational authority. --- # For agents 2ok is reusable, domain-independent governance building blocks; a website is not an approval server. 2ok is an experimental open-source foundation for agent identities, delegation, immutable specifications, explicit authorizations, protected transactions, evidence and task checkpoints. It is not an autonomous agent or operational control plane. Start from the [architecture](https://github.com/x2ot/2ok/blob/main/docs/architecture.md) and [independent roadmap](https://github.com/x2ot/2ok/blob/main/docs/migration-roadmap.md). Agents may propose protected actions; only independently controlled systems can authorize and enforce them. Status: current. This public documentation does not grant permissions. --- # Architecture and contract boundaries Intent → Verify → Authorize → Execute → Observe → Record; decision, enforcement and evidence are separate. The generic lifecycle is **Intent → Verify → Authorize → Execute → Observe → Record**. Each consequential request should bind actor, action, resource, artifact revision and narrowly scoped permission. Immutable proposals are not approvals; policy decisions are not enforcement; observation is not authorization. Generic interfaces are proposed for `SpecRevision`, `ChangeProposal`, `PolicyDecision`, `ApprovalStatement`, `ExecutionLease`, `ExecutionReceipt` and `TaskCheckpoint`. These contracts are **planned**, not currently exposed as a production service. Strong claims require independently administered resource enforcement and negative replay/mismatch tests. Status: design. This public documentation does not grant permissions. --- # Implementation roadmap Implemented identity/evidence foundations; planned immutable specs, independent policy, approvals, transactions, leases, orchestration. **Extracted foundations:** `ok-identity` (validated principal and delegation scope records; not credential issuance) and `ok-evidence` (bounded records and digests; not trust or authorization). **Planned in order:** immutable spec revisions and proposals; generic action/policy and exact approval bindings; durable transaction/event/receipt semantics; independently enforced one-use execution leases; task pause/review/resume. First end-to-end proof should use a synthetic resource and a dummy connector with tamper, replay and uncertain-outcome negative tests. These are **2ok-owned milestones**, not a copy of any consumer's backlog. Status: mixed. This public documentation does not grant permissions. --- # Deployment topologies One versioned API across laptop, on-prem and cloud/edge placements, with candid trust assumptions. **Local Windows + WSL2 + Docker:** run planned APIs, identity, Postgres, policy and workers in containers; Windows-native connector as necessary. One compromised workstation defeats local isolation assumptions. **Customer on-prem:** place secrets and protected connector on separately administered host with network segmentation and local identity/audit. **Cloud + edge:** put the governance plane in cloud where desired, but hold credentials and resource access in an independently enforced local connector. All three use compatible versioned interfaces; deployment/topology remains a design, not a working 2ok distribution. Status: design. This public documentation does not grant permissions. --- # Operating profiles and ergonomics Development speed, engineer-supervised sessions and managed enforcement are distinct modes. **Development / YOLO:** unrestricted edits and normal builds are legitimate, with shadow-policy evaluation if desired. Do not claim an unrestricted agent is contained. **Commissioning / engineer in control:** short-lived target-scoped engineer sessions and direct engineer actions reduce repeated approvals. A signed-in engineer never automatically delegates credentials to autonomous agents. **Managed operation:** protected actions require independently enforced, audience-bound, short-lived authority. A policy prompt or read-only WebMCP tool is not a resource guard. Human approval does not guarantee physical safety. Status: design. This public documentation does not grant permissions. --- # Interfaces and reuse decisions Adopt proven policy, identity and database infrastructure; keep speculative tools behind adapters. Favor Open Policy Agent as policy decision engine, standard OIDC/passkeys for human identity/approvals, and PostgreSQL for durable records. Independently protected connectors must enforce the decision and own secrets. Evaluate mature orchestration before implementing task durability from scratch. TAP, withHuman, HARP, HumanAuth, Trigger.dev, SpecD and ASDD are candidates or references, **not declared production dependencies or proven security boundaries**. Assess licenses, self-hosting, maintenance and exact trust models before adoption. Status: design. This public documentation does not grant permissions. --- # Current implementation status Experimental Rust crates and illustrative browser demo; no production authorization or isolated execution. The `ok-identity` and `ok-evidence` crates are extracted Rust slices with validation/digest behavior. No public 2ok service currently provisions isolated execution, stores production credentials, issues cryptographically verified phone approvals or controls protected resources. The site visualizations are deterministic browser demonstrations only, with no backend side effects. The installed source and local tests are authoritative for implemented behavior, not marketing diagrams. **Public capability review — 2026-10-25** **Identity & delegation / experimental:** Validated principal records and narrowing delegation scopes; no credential issuer, hosted identity provider or runtime authorization. **Evidence & digests / experimental:** Bounded evidence records, providers and versioned digests; does not establish truth, approval or protected execution. **Specifications / planned:** Immutable reviewed revisions, exact change proposals and versioned contracts. Work outside main does not advance public status. **Approval & policy / planned:** Exact-resource decisions, independent policy and verifiable human approvals. No operational approval service is exposed. **Protected execution / planned:** One-use resource-scoped leases, resource-side re-verification, receipts and uncertain-outcome recovery. **Review checkpoints / planned:** Durable task pause, independent review and safe resume; queuing a task never grants execution authority. **Publication rule:** Update only after reviewing public code merged into 2ok main. Work in feature branches, demonstrations, and other applications does not establish an implemented capability. **Operational surface:** none. This site does not exercise authorization. Status: experimental. This public documentation does not grant permissions. --- # 2ok terminology explained Short explanations and concrete examples for the governance and developer terms used across 2ok. These definitions explain ideas, not claims that 2ok implements every described service. ## agent governance Rules, reviews and independent controls that limit consequential actions by an AI agent. **Example:** An agent may draft a deployment change, but an independently controlled system should decide whether that exact change may proceed. ## authorization A decision that a particular action on a particular resource is permitted. An agent's request is not permission. **Example:** A successful review of a proposed action is not authorization unless resource-side controls accept an exact, valid permission. ## checkpoint A saved point where a task can stop, be reviewed and safely resumed with its context intact. **Example:** A long-running task could pause before an action. Durable 2ok task checkpoints remain planned. ## CLI Command-line interface: a way to run software by typing commands in a terminal. **Example:** A developer may invoke a local CLI command to inspect a build or generate a preview. ## delegation Giving someone or something limited permission to act without sharing every privilege. **Example:** A service may be allowed to propose one project update without receiving the human operator's other permissions. ## digest A compact data fingerprint for detecting changes, not proof that the content is true. **Example:** A file digest lets a reviewer notice that bytes changed; it cannot show whether the content is correct. ## evidence Recorded observations or checks supporting a claim. Evidence does not grant permission. **Example:** A passing test supports a claim about the tested input, not a claim that an agent is safe to execute a different action. ## execution lease A short-lived, narrowly scoped permission a protected resource can verify before acting. **Example:** A planned protected connector might accept a permission valid for one approved action and reject a second use. 2ok does not yet run this service. ## FFmpeg A widely used local tool for editing and combining audio and video. **Example:** The creative lab documents local FFmpeg production; the public website never processes uploaded footage. ## FFprobe A companion tool that inspects media metadata such as duration and tracks. **Example:** A local editor can check a clip's duration with FFprobe before planning the edit. ## immutable Not changeable in place. Updates create a new version so earlier reviewed content remains identifiable. **Example:** Reviewing version 4 of a proposal should not silently authorize an edited version 5. ## MCP Model Context Protocol: a standard way for AI software to discover and invoke structured tools. **Example:** An assistant can use MCP to discover a tool's arguments; permission to invoke it is a separate question. ## OIDC OpenID Connect: a common identity standard for signing users in. **Example:** An app can use OIDC to learn which user signed in, but identity does not automatically authorize every operation. ## OPA Open Policy Agent: software for evaluating policy rules separately from an application. **Example:** A proposed policy service could ask OPA whether an action is allowed; the resource must still enforce that decision. ## passkey A phishing-resistant cryptographic sign-in credential, often unlocked by a device. **Example:** A person may use a passkey to sign in, while a separate authorization decision still governs a protected action. ## policy A set of explicit rules used to decide which actions are allowed or need review. **Example:** A policy might require review of a high-impact action; 2ok's independent policy service is planned. ## principal The named person, agent or service to which an identity, request or permission is attributed. **Example:** A principal identifies who is asking; it says nothing by itself about what they may do. ## protected connector A separately controlled component that holds resource access and verifies permission before executing. **Example:** In a proposed design, the connector—not the agent's prompt—holds credentials. 2ok has no deployed protected connector. ## receipt A record of what a system reports performing and the outcome observed. **Example:** An execution receipt should identify the request and report whether the resource confirmed success, failure or an uncertain result. ## replay Trying to reuse an earlier valid request or permission. Protected actions should reject unintended reuse. **Example:** A previously approved transfer should not be accepted as approval for the same transfer a second time. ## scope The limits of permission, such as which action, target or revision it covers. **Example:** A request scoped to one file should not permit editing every file in the workspace. ## storyboard An ordered plan of video scenes, timing, and optional titles. **Example:** A storyboard might specify scene order and a two-second title before rendering a local preview. ## trust boundary A separation between components with different privileges or responsibilities. **Example:** Keeping approval decisions outside an agent process avoids treating the agent's own request as trusted approval. ## WebMCP An experimental browser interface for exposing website tools to compatible AI clients. Here the tools only read public information. **Example:** This site's WebMCP search helps compatible agents find public pages; it does not approve or execute a protected task. ## WSL2 Windows Subsystem for Linux 2: a Linux environment running on Windows. **Example:** A developer may run Linux tooling through WSL2 on Windows; this alone does not create an independent security boundary.