Yana AI inserts a governance layer between models and machine actions
A new open-source system called Yana AI positions itself as the control plane between an AI model and the real powers it can exercise on a user's machine. The project, built by a single developer in Vietnam, treats every model proposal as a request that must pass through four sequential gates: authority, capability, policy and executor. The model proposes an action, authority checks whether this agent is allowed to ask, capability defines the exact power from a small fixed set, policy applies rules then human approval, and the executor performs only the permitted operation. A human can always stop the process at the policy stage, and the same flow applies whether the model is Claude, GPT, Gemini, DeepSeek or a local instance.
Component inventory with live status markers
The repository ships nine components, each tagged with a status that means something specific. Yana Studio, the desktop workspace for files, editor, terminals, chat and tasks, is live but with partial parity. The Rust runtime yana-rt owns the turn loop and authority contract for 19 providers across local and cloud models; it is live. Governance — capability manifests, human approval, hash-chained audit log and core-lock integrity — is live in core. Giám Thị, an independent watcher that halts later tool calls on drift, is live but opt-in. Harness adapters for Claude Code, Codex, Cursor and Antigravity are live with enforcement strength varying by host. The knowledge layer of agents, skills, commands and rules is live but grants no permissions. Yana OS, a local management plane for identity, autonomy, quotas and quarantine, remains in development. Earlier Electron shells Yana Desktop and Yana Web are maintained separately from Studio. Yana Wheelbot, an ESP32-S3 robotics platform in its own repo, is experimental. Live means shipped and in use; in development means real code exists but is not feature-complete; experimental means opt-in and not independently verified.
Filesystem-derived counts kept honest by CI
Core directory contents are not hand-counted. The hooks directory holds 66 entries, 63 shell and 3 JavaScript. Rules number 71, most describing behaviour the agent applies to itself. Specialist agents total 100. Skills number 2,026. Claude Code slash commands number 170. The config directory contains core-lock.json, a SHA-256 manifest pinning 287 core files. These counts come from core/scripts/check_counts.py, which CI runs so the numbers cannot drift from the tree. The project versioning spans three axes — the product, yana-rt on crates.io and the yana-ai Python package on PyPI — each with its own registry and numbering, deliberately omitted here since they go stale; readers should consult VERSIONING.md.
Studio consolidates files, terminals, git and chat in one window
Yana Studio is a single window for the things a developer switches between when working with AI on a project. It communicates with the model only through yana-rt, never calling a provider from the UI layer. The editor uses CodeMirror; files up to 8 MiB are fully editable, larger ones open as read-only 256 KiB windows, and saves detect outside changes before overwriting. Terminals are real PTY sessions in tabs or a grid of up to 12. Git shows read-only status, worktrees and diffs; stage and commit are deliberately not AI tools. Chat streams through yana-rt with multiple saved conversations, a stop button, approval prompts and token usage display. All 19 providers — 13 cloud, 6 local — plus a custom OpenAI-compatible endpoint are available. A local manager detects 9Router, Ollama, LM Studio, llama.cpp, TurboFieldfare and AirLLM. API keys travel to Rust over stdin and are stored encrypted in the OS keystore, never in workspace files. Tasks are created, listed, depended on and dropped against the real yana-rt task store; marking done requires evidence, and blocked status is always computed by the runtime. The design canvas is native with 22 components, phone and desktop screens, layers, undo/redo and guarded AI proposals. Governance telemetry records what was allowed, blocked and why. Missing features include device registry, agent sessions screen, mobile pairing, SSH/Docker execution, permission-lease UI and signed auto-update; per-screen status lives in tools/yana-studio/SCREEN-STATUS.md.
Platform support and source build
Installers ship per platform: .dmg or.zip for macOS Apple Silicon, .exe x64 or ARM64 for Windows, .deb or.AppImage for Linux x86_64. No Linux ARM build exists. The macOS build is ad-hoc signed and not notarized, so Gatekeeper warns on first launch; two official opening methods are documented in docs/MACOS_INSTALL.md. Building from source requires Node 24+ and a C++ toolchain for node-pty. The commands cd tools/yana-studio && npm ci && npm run rebuild && npm run stage:runtime -- /absolute/path/to/yana-rt && npm start install the runtime and start Studio. A single Rust binary owns the turn loop and authority check for every client, so Studio, the CLI and MCP do not each reimplement permission logic.
Nineteen providers with typed failover and SQLite state
The canonical provider list lives in src/model/catalog.rs and includes anthropic, openai, gemini, groq, deepseek, openrouter, xai, novita, nvidia, minimax, glm, huggingface, 9router, kimi (cloud) and ollama, lmstudio, llama.cpp, TurboFieldfare, airllm (local). Failover uses typed provider errors, fallback providers and credential-pool rotation. State persists in a SQLite session store with full-text search, per-profile state, crash recovery and shadow-git checkpoints with rollback. Capability tools include file read/patch, command execution under validation, MCP client over stdio, web search through a checked HTTPS layer and a read-only LSP client. Optional features — mcp, lsp, pty-bridge, Discord remote adapter — are off by default.
Giám Thị watches from outside the AI session
Giám Thị runs independently of any AI session, scheduled by the OS: launchd on macOS, systemd timer on Linux, Task Scheduler on Windows, every 6 hours. It compares the repo against a human-approved baseline commit across enforcement-controlling files: hook settings for Claude Code, Codex and Cursor, CI workflows, core/rules, core/gates, core/hooks, core/scripts and src/guard. On drift it writes GIAMTHI_HALT.lock; a hook running first on every tool call then denies everything while the lock exists. Only a person can delete the lock; the hook, watcher and environment variables cannot. Management commands are yana-ai giamthi install | status | repair | uninstall. The watcher is opt-in, and the 6-hour schedule means a window of up to 6 hours between a change and the halt. Codex fires PreToolUse only for shell commands, so Yana also checks the lock on SessionStart and UserPromptSubmit for Codex.
Enforcement differs across four host adapters
How governance applies depends on the host. Claude Code uses native hooks and rules in .claude/ with runtime blocking on every tool call and hash-chained audit. Codex relies on AGENTS.md, .codex/ hooks, synced skills and agents installed via yana-ai install --engine codex; enforcement is project-scoped. Cursor uses .cursorrules, .cursor/rules and a beforeShellExecution hook; shell commands are screened but MCP tool calls are not covered. Antigravity is advisory only, governed by .agent/rules/yana-ai.md, not enforced at the shell. Details and switching commands are in adapters/README.md.
Security model acknowledges practical limits
The audit log is hash-chained so editing or deleting a line is detectable, but it is tamper-detectable not tamper-proof. Core-lock proves the tree matches the lock file, but whoever can edit core can regenerate the lock; Giám Thị is the independent check for that. The human gate requires fresh confirmation for force-push, publish, deploy and delete in the current session; earlier approval does not carry over. The guard-destructive.sh script matches command strings, not a full shell parse, so a deliberately crafted command can slip past it. Antigravity is advisory and Cursor does not screen MCP calls. Browser-only web deployments without the Rust runtime are not fully governed. These limits are documented in the project's SECURITY.md.
Single-maintainer Apache 2.0 project
Yana is built by one person with no team and no funding, licensed Apache 2.0. The Python CLI installs via pip install yana-ai; the runtime via cargo install yana-rt. Both need Python 3.11+ or Rust, Git, and one supported harness. All CLI commands are in COMMANDS.md, including the 170 Claude Code slash commands in core/commands/ that run inside a session. Yana is not published to npm.