Landscape

Note

Design document: draft. Shiin has a pre-alpha source implementation. Third-party comparisons remain the dated source snapshot stated below. Every statement about another project links its source and gives the date it was verified.

Summary

Many tools already help people control what AI agents do. They intercept actions at different points, enforce decisions with different strength, and leave different evidence. Shiin is designed as a local, agent-agnostic authorization layer for agent actions. It is not a sandbox, a network firewall, or a gateway, and it is designed to work alongside all three.

Deciding whether an agent’s action proceeds, is refused, or waits for a person is not a new idea. Several open-source projects already do it, and Open-source agent action gates credits them with sources. Shiin’s case rests on the four differentiators described in the vision: task-intent binding, an open agent-neutral contract, analyzable policy, and explicit enforcement levels. Shiin’s first experimental CLI and Unix-daemon release is available for Linux and macOS; client and MCP integrations remain source-only. If you need a working tool today, evaluate the projects on this page.

How to read this page

• Facts about other projects come from their own documentation or repositories, linked beside each statement, as checked on 2026-09-14.
• A table cell that reads “not documented” means the sources checked for this page did not establish the fact. It does not mean the project lacks the capability.
• Each project is described in its own terms. Where a project’s decision labels differ from Shiin’s allow, deny, and pending, they are quoted as that project’s labels.
• Statements about Shiin describe its design, not shipped features.

Standards that frame the problem

Shiin’s problem statement draws on three public documents, which are also useful when comparing any tool on this page:

• OWASP LLM06:2025 Excessive Agency (verified 2026-09-14).
• OWASP Top 10 for Agentic Applications 2026 (verified 2026-09-14).
• The NIST National Cybersecurity Center of Excellence concept paper on software and AI agent identity and authorization, published in February 2026 (verified 2026-09-14).

Categories

Tools in this space fall into six broad categories, and a single tool can span more than one. The categories act at different points and answer different questions, which is why they combine well.

Host-native controls

The applications that run agents ship their own controls, and they are the first thing to configure.

• Claude Code has permission rules, and PreToolUse and PermissionRequest hooks that can return allow, deny, or ask decisions (hooks, permissions, verified 2026-09-14). Hooks can be disabled with --bare or the disableAllHooks setting, and managed hooks cannot be disabled (hooks, verified 2026-09-14).
• OpenAI Codex CLI has approval policies and sandbox modes (agent approvals and security, verified 2026-09-14). Its PreToolUse hooks cover Bash, apply_patch, and MCP tools (hooks, verified 2026-09-14). Its documentation calls hooks “a useful guardrail, not a complete enforcement boundary” (hooks, verified 2026-09-14).
• Cursor has offered hooks since version 1.7, including beforeShellExecution, beforeMCPExecution, beforeReadFile, and preToolUse, with allow, deny, or ask responses and a failClosed option (hooks, verified 2026-09-14).

How Shiin relates. Shiin’s enforcement level L1 adapters are designed to use these same hook mechanisms, so they inherit the hooks’ strengths and limits. Shiin is designed to add to host controls, not to replace them, so keep them enabled. Enforcement levels records what each adapter can and cannot see.

OS sandboxes and isolation

A sandbox limits what a process can do after it starts, whatever the reason it was started. Containers and virtual machines are the general-purpose form, and some hosts include a sandbox of their own:

• Claude Code’s sandbox applies to Bash commands and their child processes (sandboxing, verified 2026-09-14).
• Codex CLI’s sandbox modes use Seatbelt on macOS, and bwrap and seccomp on Linux (agent approvals and security, verified 2026-09-14).

How Shiin relates. Shiin decides whether an action should happen; a sandbox limits the damage if an allowed action, or the code it runs, misbehaves. Shiin cannot see what a program does after it is allowed to run, as Limitations explains, so a sandbox covers a gap that Shiin leaves. OS-enforced integration (L3) is a future enforcement level. Using Shiin with sandboxes describes the intended layering.

Network egress controls

Egress controls restrict where traffic can go, regardless of which action produced it.

• The GitHub Copilot coding agent firewall restricts outbound network access for processes started by the agent’s Bash tool (customize the agent firewall, verified 2026-09-14). It does not apply to MCP servers or setup steps, and its documentation says it “should not be considered a comprehensive security solution” (customize the agent firewall, verified 2026-09-14).
• Coder Agent Firewall, formerly called Agent Boundaries, is a process-level network firewall that restricts domains and HTTP methods and keeps audit logs (agent firewall, verified 2026-09-14). It covers network egress only (agent firewall, verified 2026-09-14).
• pipelock is an agent firewall for HTTP, MCP, A2A, and WebSocket traffic, with DLP, SSRF, prompt-injection, and tool-poisoning detection and signed action receipts (luckyPipewrench/pipelock, verified 2026-09-14). It is written in Go, with an Apache-2.0 core and Elastic-2.0 enterprise features (luckyPipewrench/pipelock, verified 2026-09-14).

How Shiin relates. Shiin’s design can deny a network action it can see, but it does not inspect traffic content, and it cannot see data leaving through an action it has allowed. Egress controls are the right layer for that, and Shiin is designed to run alongside them.

MCP and agent gateways

Gateways sit in the traffic between an agent and the tool servers or other agents it calls.

• agentgateway is a Linux Foundation proxy for MCP and A2A with RBAC rules written in CEL (agentgateway/agentgateway, verified 2026-09-14). It is written in Rust and licensed Apache-2.0 (agentgateway/agentgateway, verified 2026-09-14).
• Invariant provides rule-based guardrails for LLM and MCP applications (invariantlabs-ai/invariant, verified 2026-09-14). It is written in Python and licensed Apache-2.0 (invariantlabs-ai/invariant, verified 2026-09-14). Invariant Labs was acquired by Snyk in June 2025 (Snyk announcement, verified 2026-09-14).
• Belay, described under open-source agent action gates, can also work as an MCP proxy.

How Shiin relates. Shiin’s early MCP proxy implementation (v0.5) is an L2 mediated adapter with a narrower role than a general gateway. It turns supported MCP tool calls into action requests; conformance and end-to-end policy validation remain open. MCP tool annotations can make a decision stricter but never more permissive. If what you need is access control for MCP or A2A traffic shared across many agents, a general gateway may be the better fit.

Policy engines as building blocks

Policy engines evaluate rules. They do not intercept agent actions themselves; other tools embed them.

• Cedar is an authorization policy language and engine (cedar-policy/cedar, verified 2026-09-14). Its cedar-policy Rust crate is licensed Apache-2.0, Cedar is a CNCF Sandbox project, and it is formally verified in Lean (cedar-policy/cedar, verified 2026-09-14).
• regorus is a Rust interpreter for Rego, and it is used in Azure Policy (microsoft/regorus, verified 2026-09-14).
• Other projects on this page also build on policy languages: Cupcake uses OPA/Rego compiled to WebAssembly (eqtylab/cupcake, verified 2026-09-14), and agentgateway uses CEL (agentgateway/agentgateway, verified 2026-09-14).

How Shiin relates. Shiin builds on Cedar rather than competing with it. Operators write TOML policy, which Shiin compiles to Cedar. The choice was accepted in ADR-0014, and the source implementation uses it. Direct Cedar input remains unimplemented.

Open-source agent action gates

These projects are closest to Shiin. They act at the point where an agent proposes an action and decide what happens to it.

• Belay is a local-first security layer at the tool-call boundary for Claude Code, Codex, Cursor, and MCP, using native hooks or an MCP proxy (SECBLOK/belay, verified 2026-09-14). It returns “deny”, “ask”, or “allow” and keeps a tamper-evident audit trail (SECBLOK/belay, verified 2026-09-14). It is written in Rust and licensed AGPL-3.0, with a commercial option (SECBLOK/belay, verified 2026-09-14).
• Cupcake works through the hooks of Claude Code, Cursor, and other agents, with policies written in OPA/Rego and compiled to WebAssembly (eqtylab/cupcake, verified 2026-09-14). It is written in Rust and licensed Apache-2.0 (eqtylab/cupcake, verified 2026-09-14).
• AgentFence is deny-by-default, with “allow”, “deny”, and “ask” outcomes and Ed25519-signed, hash-chained logs (dgenio/agentfence, verified 2026-09-14). It is written in Go and licensed Apache-2.0 (dgenio/agentfence, verified 2026-09-14).
• Cerberus is a local gateway for Claude Code, Codex, Cursor, and Cline that risk-scores actions and returns one of the project’s own labels: “ALLOW”, “AUDIT”, “HITL”, or “BLOCK” (Adirdabush1/cerberus, verified 2026-09-14). It is written in TypeScript and licensed Apache-2.0 (Adirdabush1/cerberus, verified 2026-09-14).
• agent-belay is a desktop approval app that shows tool requests with diffs and command previews for Claude Code, Copilot, and others, with optional LLM-based risk scoring (mikepenz/agent-belay, verified 2026-09-14). It is written in Kotlin and licensed Apache-2.0 (mikepenz/agent-belay, verified 2026-09-14). It is a separate repository from SECBLOK/belay.
• ActionRail checks consequential tool-call arguments against live systems of record and returns one of the project’s own labels: “allow”, “hold”, or “block” (ToolJet/ActionRail, verified 2026-09-14). It is written in Python, licensed Apache-2.0, and in public beta (ToolJet/ActionRail, verified 2026-09-14).
• latchagent/latch describes itself as a “control layer for autonomous AI agents” in which risky actions wait for approval (latchagent/latch, verified 2026-09-14). It is written in TypeScript and licensed MIT (latchagent/latch, verified 2026-09-14).
• Agent Governance Toolkit provides policy enforcement, zero-trust identity, sandboxing, and audit for AI agents (microsoft/agent-governance-toolkit, verified 2026-09-14). It is written in Python and licensed MIT (microsoft/agent-governance-toolkit, verified 2026-09-14).

How Shiin relates. This is where Shiin overlaps most, as the section Where Shiin overlaps and where it differs explains.

Comparison dimensions

These questions help compare any tool on this page, including Shiin. The last column includes current and planned design; the roadmap records implementation scope.

Projects at a glance

The tables below summarize the facts cited in Categories. Every row links its source, and every fact was verified on 2026-09-14. “Not documented” means the sources checked for this page did not establish the fact.

Host and platform controls

Open-source projects

Where Shiin overlaps and where it differs

Overlap

Deciding, before an agent’s action runs, whether it proceeds, is refused, or waits for a person already exists in open-source projects.

• Belay and AgentFence document allow, deny, and ask outcomes together with tamper-evident or signed, hash-chained audit records (SECBLOK/belay, dgenio/agentfence, verified 2026-09-14).
• Cupcake applies policy through the hooks of Claude Code, Cursor, and other agents (eqtylab/cupcake, verified 2026-09-14).
• Cerberus returns its own “ALLOW”, “AUDIT”, “HITL”, or “BLOCK” labels from a local gateway (Adirdabush1/cerberus, verified 2026-09-14).

Related ideas exist too. Cupcake and agentgateway express policy in established languages, pipelock issues signed action receipts, and Belay is local-first and written in Rust (sources in Categories). None of these, on its own, is a reason to choose Shiin: intercepting actions through hooks, returning allow-or-deny outcomes, keeping an audit trail, writing policy as code, running locally, or being written in Rust.

Differences

Shiin’s case rests on the four differentiators in the vision. Each is a design commitment; the source implements task constraints, core wire contracts, policy evaluation, cooperative hooks, Unix approval services, evidence, and early integrations. Host validation and stronger enforcement remain open.

1. Task-intent binding. Shiin checks actions against constraints in experimental, human-confirmed task declarations, as well as standing policy; measurements and host validation remain open. This page records no verified fact that another project listed here binds decisions to per-task constraints. If one does, please request a correction.
2. An open, agent-neutral contract. The action request, decision, and approval protocol are designed as versioned specifications with schemas and test vectors that other tools can implement. Several projects above support more than one host, but supporting several hosts is not the same as publishing the request and approval formats as independent specifications. This page records no verified fact that another project listed here publishes such specifications.
3. Analyzable policy. Policy as code is not new; Cupcake uses Rego and agentgateway uses CEL. Shiin uses Cedar behind a TOML front-end so that policies can be tested and explained (ADR-0014, accepted).
4. Explicit enforcement levels. Vendors already state the limits of their own controls: Codex CLI calls hooks “a useful guardrail, not a complete enforcement boundary” (hooks, verified 2026-09-14), and GitHub says its agent firewall “should not be considered a comprehensive security solution” (customize the agent firewall, verified 2026-09-14). Shiin applies that honesty uniformly: every adapter is designed to state its enforcement level and what it cannot see (ADR-0033).

A differentiator on paper is not a working tool. Until Shiin ships, the projects above are the ones you can use.

When to use something else instead of or alongside Shiin

Keeping this page accurate

• Anyone, including the maintainers of a project described here, may request a correction by opening an issue at BAGOMBEKA-JOB-DEV/shiin.
• Every fact about another project links a public source and states the date it was verified.
• A claim that cannot be verified from a public source is removed rather than guessed, and a table cell that cannot be verified reads “not documented”.
• Maintainers re-verify every fact on this page before each release and update the reviewed date in the page metadata.
• Projects are described in their own terms and credited for their work. This page does not disparage any project.
• A project is added through a pull request that includes public sources. Being listed is not an endorsement.

Read next

• Vision
• Limitations
• Enforcement levels
• FAQ