Skip to content

AI agents & automation

TOVIO treats an AI agent as a first-class, bounded participant — not a borrowed human login. An agent gets its own identity, a capability token that says exactly what it may touch, and a provenance trail that ties every line it writes back to the human who authorized it. The result is the feeling this whole section is built around: you can hand an agent real work and stay calm, because it is scoped, audited, and cryptographically bounded by construction.

Phase 2 is implemented across CLI, Node, and MCP

Capability tokens, commit --token, read/write secret_clearance, provenance, the tovio agent lifecycle, the Node bindings/SDK, the MCP server (over stdio or loopback-default Streamable HTTP, launched by tovio mcp serve), and the coordination session registry all run today. Protected plaintext diff, protected same-policy moves, protected conflict resealing, region-level MCP resolution, server-generated session correlation, the old-reader-key rotation fallback, chain-bearing delegated sessions with full-chain provenance, and the canonical tool_manifest_hash (tovio-tool-manifest-v3) are implemented. The remaining edge gaps are the protocol-level scope echo as one combined handshake object, an approaching-expiry signal on tool responses, npm package publication, and full relay ahead/behind status; amend, direct lane creation, and sync stay outside the registered MCP tool surface.

Why TOVIO is built for agents

Git has no idea an agent exists. It runs as you, with your full access, and the only record that an agent did the work is a name in a commit. TOVIO inverts every part of that.

  • Scoped by a capability token

    A token bounds an agent to a set of paths, a set of operations, and a deadline. Anything outside that is refused before policy is even read — the agent cannot act on, or even learn about, what it was not given.

    Capability tokens

  • The TOVIO read surface withholds uncleared plaintext

    A protected file remains ciphertext through TOVIO for an agent without clearance. Capability tokens do not sandbox unrelated tools or retract plaintext explicitly supplied outside that read path.

    How tokens scope reads

  • Every action is provenance-stamped

    Each accepted agent commit records the model, task, prompt hash, and human authorizer. A delegated leaf connects only after the core re-verifies its full root-to-leaf chain, and its commits record that whole delegation_chain. Nothing accepted is anonymous or authorized-by-omission.

    Provenance

  • Agents speak MCP, not the raw CLI

    The MCP server validates the token on every call and never even offers the operations agents must never perform. A forbidden tool is structurally absent, not denied after the fact.

    The MCP server

The model in one minute

  1. A human issues a token. tovio agent new <name> --model <id> --task <text> --expires-in <hours> mints a tovio-capability-v1 token signed by your identity. Its defaults are safe: broad access to ordinary code, zero access to policy-protected paths, no way to escalate.
  2. The agent connects over MCP. The workspace MCP process starts with the token in TOVIO_TOKEN — its cap_… id, or the hex-serialized token a delegating agent handed out. The server hands the token to the Rust core, which runs the full validity check before any session exists.
  3. Every call is re-checked. Token validity, then path scope, then operation allow/deny, then policy and key availability — in that exact order, on every single tool call. Scope is checked before policy, so an out-of-scope request never even learns a path's policy.
  4. Writes are stamped and bounded. Provenance is injected by the server (the agent cannot forge or omit it), and a write to a protected path still needs the same cryptographic proof a human would provide.
  5. It all expires. Tokens are never indefinite. A long job renews deliberately; an expired token simply stops working — no silent extension at 3 a.m.

Where to go next

  • Agent sessions

    What a session is, why "one agent, one task" is the unit operators reason about, and how renewals are deduplicated. (explanation)

    Agent sessions

  • Capability tokens

    Issue, scope, renew, and revoke tokens; understand path_scope, secret_clearance, allowed and denied ops, and delegation. (how-to)

    Capability tokens

  • Run the MCP server

    Start the unpublished workspace MCP package over stdio or Streamable HTTP, see the tools it exposes, and learn how the token is validated on every call. (how-to)

    MCP server

  • Write an integration

    Wire up Cursor, Claude Code, or a custom MCP client to a scoped TOVIO session. (how-to)

    Write an integration

  • The machine contract

    The clean --json / --quiet output agents parse — and the hard rule that it never carries emoji, celebration, or warmth. (reference)

    The machine contract

New to the core ideas?

If "policy", "clearance", and "Change ID" are new to you, read the concepts first — the agent model sits directly on top of TOVIO's permission system.

Last reviewed September 9, 2026

Suggest an improvement to this page Not for security reports — see disclosure