Give an AI agent SSH access to a real Linux box — without giving it a real shell. AIShell-Gate becomes that shell: every command it sends is evaluated, risk-scored, and logged before a single byte reaches the kernel. Point any AI at it — a remote agent over SSH, a local pipeline, or a coding assistant like Claude Code — and it gets the same protection.
Large language models are increasingly used to generate shell commands. They are good at it. They are also probabilistic. Linux execution, by contrast, is deterministic and irreversible — a single misplaced flag or path can permanently alter system state.
How often does this actually happen?A structured simulation exercise estimated that even a well-prompted, safety-tuned large model generates at least one policy-flaggable command in a complex CI/CD plan 20–30% of the time. For smaller or less-aligned models given terse prompts, that figure rises above 85%. The most dangerous cases are not catastrophic failures — they are silent partial errors that leave production in a subtly wrong state while everything appears normal. → read the risk assessment · → read the documented incident & benchmark evidence
AIShell-Gate exists to close that gap. It sits between an AI agent's proposed actions and the operating system — whether that agent connects over SSH, runs as a local pipeline, or is a coding assistant like Claude Code — evaluating every command against declared policy before a single byte reaches the kernel. Unsafe commands are denied with a reason. Safe commands are allowed — with a confirmation level appropriate to their risk. No shell is ever invoked.
AI Agent │JSON action plan ▼aishell-gate-exec(no policy logic — pure execution harness) │forks policy engine for each action ▼aishell-gate-policy(deterministic policy engine — separate process) │ALLOW / DENY + confirmation level + validated argv ▼aishell-gate-exec(collects human confirmation if required) │ ▼execve(absolute_path, validated_argv, safe_environment)(no shell — no PATH inheritance — no environment injection)
The separation between the two programs is the central security property of the system. The executor has no policy logic; the policy engine has no ability to execute. Neither component can reach across that boundary.
346
Linux commands catalogued
3,489
individual flag assessments
7
built-in policy presets
02 SSH Deployment
This is the primary way to run AIShell-Gate: an AI agent connects over SSH, and AIShell-Gate — not /bin/bash — is what is waiting on the other end.
Fastest way to test this: If you already have Claude Code or Cursor set up, you don't need to touch SSH or create an account first. Point your existing setup at AIShell-Gate the way you'd add any MCP server, and you're running commands through the real policy engine in minutes. That's not a coding-agent feature — it's just an existing, already-authenticated account you probably have lying around, and the quickest on-ramp to see the gate work before you set up the SSH path. → jump to the Claude Code / Cursor quickstart (§03)
A dedicated ai-agent account is set up with a forced command in its SSH configuration, so instead of dropping into a login shell, every SSH session lands directly in AIShell-Gate. The agent sends a JSON action plan over that connection; each command in the plan is evaluated by the policy engine, logged to the tamper-evident audit chain, and — if allowed — executed directly with execve(). No shell is ever invoked, so there is no shell to escape from.
The Linux answer
If you sat down and thought carefully about how to give an AI controlled access to a Linux system in a way that would make an experienced sysadmin comfortable, you would probably arrive at something very close to this. You would reach for SSH because it is already there and already trusted. You would use a forced command because that is what forced commands are for. You would create a dedicated account because that is how you scope identity. You would call execve() directly because you know what shells do to arguments. The result is not a clever new thing — it is the application of well-understood primitives to a new problem. That is exactly the right kind of design.
This works for any AI system that can open an SSH connection — a remote autonomous agent, a scheduled pipeline, a local LLM calling out over the network. Coding assistants like Claude Code and Cursor are one example client among many; see §03 for that integration path specifically.
AIShell-Gate in Claude Code. Two config files. Ten minutes.
If you are driving AI-to-Linux access through an MCP-compatible coding agent instead of the SSH path above, here is how AIShell-Gate slots in — the same policy engine, the same audit chain, the same guarantees. Every other MCP tool gives an AI access to one capability; AIShell-Gate gives it access to the operating system, and the policy engine is what makes that access safe.
evaluate_plan
Submit a goal and list of commands to the policy engine without executing anything. Returns per-action decision, confirm level, resolved binary path, risk score, and reason. The right first step before any execution.
execute_plan
Submit a goal and list of commands for live execution. Runs a pre-flight policy evaluation first. Plans containing high-risk or confirmation-required actions are blocked and reported — the operator adjusts policy or proceeds manually.
Three steps to connect Claude Code
01
Create aishell-mcp.json in your project root: {"exec_binary": "./aishell-gate-exec", "policy_binary": "./aishell-gate-policy", "preset": "ops_safe"}
02
Add to .mcp.json: {"mcpServers": {"aishell-gate": {"command": "python3", "args": ["./aishell-gate-mcp.py"]}}}
03
Restart Claude Code or Cursor. The evaluate_plan and execute_plan tools appear automatically. The AI calls them directly — no shell scripting, no manual pipe setup.
Full integration walkthrough: Getting Started Guide §20 →
·
Requires Python 3.8+ · No additional dependencies
04 The Programs
aishell-gate-policy
Policy Engine
Receives a proposed shell command, normalizes it, evaluates it against a layered policy stack, computes a risk score, and emits a structured JSON decision. It never executes anything. Its only output is the decision record: allow or deny, confirmation level, matched rule and layer, validated argument array, risk score, blast radius, and reason.
aishell-gate-exec
Executor
Accepts a JSON action plan from an AI agent, submits each command to the policy engine as a child process, reads the JSON decision back over a pipe, collects human confirmation where the policy requires it, and calls execve() with the validated argument vector. Contains no policy logic of its own.
aishell-gate-mcp
MCP Server
Exposes AIShell-Gate to Claude Code, Cursor, and any MCP-compatible AI coding environment via stdio transport. Provides evaluate_plan (policy-gated inspection, never executes) and execute_plan (live execution with pre-flight check). Python 3, no additional dependencies. Configured via aishell-mcp.json.
AIShell-Gate is agent-agnostic. The same policy engine, audit chain, and confirmation model apply equally to Claude Code, Cursor, local inference models via pipeline script, and remote AI agents over SSH. The gate does not care what produced the plan — only what the plan contains.
The architectural principle
The executor-separation principle is not a convenience — it is the core security property. If the executor is compromised through a bug, a malicious plan, or a hostile environment, it still cannot grant itself permission to run a command the policy engine has denied. Permission is not a variable inside the executor. It is the output of an independent process the executor has no ability to modify.
Policy Layers
Policy is a stack of three layers evaluated in order: base (organizational floor), project (workflow-specific rules), and user (personal preferences). A deny at any layer is final. The built-in presets — ops_safe, dev_sandbox, read_only, danger_zone — give teams a working starting posture without manually assembling policy files.
Confirmation Levels
Every ALLOW decision carries a confirmation level: none (proceed immediately), plan (show the plan before running), action (explicit per-command approval), or typed (operator must type a code derived from the exact command). Risk scoring escalates levels automatically — commands scoring above 40, 70, or 90 are raised to plan, action, or typed regardless of what the matching rule says. Levels can only be raised, never lowered.
Audit Chain
Every evaluation can be written to a tamper-evident JSON Lines audit log. Each entry carries a sequence number, session identifier, full decision context, and an SHA-256 hash linking it to the preceding entry. HMAC-SHA256 mode restricts verification to key-holders. Concurrent sessions write safely via advisory file locking.
The audit chain is a compliance evidence artifact. Every command an AI agent proposes — whether allowed, denied, or confirmed — is recorded with its full decision context: the matched policy rule, the layer that matched, the risk score, the confirmation level required, and the timestamp. The chain is cryptographically linked so any post-hoc modification is detectable. For organizations subject to HIPAA, PCI-DSS, CMMC, or FedRAMP audit requirements, this record demonstrates that AI-generated actions were evaluated against declared policy before execution — not after the fact.
Regulated Environments
AIShell-Gate is aligned with the NIST AI Risk Management Framework (AI RMF 1.0) and AI 600-1. The two-binary reference monitor architecture reflects the access control framework defined in NIST SP 800-162. For organizations operating under HIPAA, PCI-DSS, CMMC, or FedRAMP requirements, AIShell-Gate provides a documented, auditable execution boundary between AI agents and production infrastructure — a control that sandbox-based approaches cannot fully replicate when AI agents must operate on real systems rather than isolated environments.
Sandboxes protect by isolation. AIShell-Gate protects by policy. When an AI agent must touch a real database, a real deployment pipeline, or a real server — because that is the point of the integration — isolation is not an option. Policy, confirmation, and a tamper-evident record of every decision are what remain. That is what AIShell-Gate provides.
05 Documentation
The following documents are included with this release. All are available in the same directory.
Note: New to AIShell-Gate? Start with the Remote Deployment Guide for SSH-based access — the primary way to run AIShell-Gate. The Getting Started Guide covers the other paths: direct AI pipeline (§7), interactive mode (§4), and Claude Code / Cursor via MCP (§20).
06 Audit Evidence and Cyber Insurance
Cyber insurance underwriting has moved from self-attestation to evidence-based verification, and in 2026 that scrutiny reached artificial intelligence. Carriers have begun issuing AI security riders — policy addenda conditioning coverage on documented AI governance, an inventory of AI tools in use, and technical controls over what those tools can reach.
Published rider requirements so far centre on data exfiltration and model risk. Command execution on infrastructure is the adjacent exposure, and most organisations carrying it keep no record of what their agents proposed, what ran, and what was refused. AIShell-Gate produces that record: every decision written to a tamper-evident audit chain, signed with HMAC-SHA256 in the Enterprise edition and verifiable afterwards.
Why a record and not just a control
Underwriters increasingly ask applicants to demonstrate that a control is operating rather than assert that it exists, and carriers use the same records in forensic review after an incident. A guardrail that leaves no trace produces nothing to submit and nothing to verify.
AIShell-Gate 1.0 is available for direct download. The policy engine, execution gateway, and operator confirmation relay are functionally complete. Documentation is available from the links above. The flag catalog covers 3,489 individual flag assessments across 346 Linux commands. The package includes the MCP server for Claude Code and Cursor integration. Both binaries support interactive human operator workflows in addition to AI agent pipelines.
▸ AIShell-Gate — 1.0 Research Pilot
AIShell-Gate 1.0 Research Pilot
The download package contains both compiled binaries, all documentation, the install scripts, and the README.
Intended use: local and single-session use by technically experienced Linux engineers, DevOps teams, and security engineers. Evaluate in controlled, non-production environments before wider rollout.
Neither binary uses any external libraries — no static linking, no dynamic linking beyond the C standard library
Tested on Linux
AIShell-Gate 1.0 is available for direct download — the release tarball, binaries, scripts, and documentation included.
Deploying over SSH? Follow the Remote Deployment Guide to set up a forced-command account for your AI agent.
Leave your email in the comment if you would like a reply.
Once You Have the Package
The Beta Tester Guide, included in the download package, walks you through the system from first binary verification to a full multi-action AI pipeline — with copy-paste commands at every step and expected output so you know if it is working. It covers the policy engine in interactive mode, single command evaluation, preset comparison, executor plans with --dry-run, audit logging, custom policy files, jail root containment, and enterprise features.
Work through it in order. Stop at any stage where something breaks and report what you saw — a tester who reaches Stage 4 and hits an error is giving us something more useful than one who skips to Stage 9. The guide includes structured feedback questions after every stage.
Submit Your Test Results
Once you have worked through the tester guide, submit your structured feedback using the link below. All fields are optional except your name. Your responses go directly to us and will directly shape the 1.0 release.
Prefer email? Send your completed tester guide responses to info@aishellgate.com with subject Beta Feedback — [your name]. For security findings, use security@aishellgate.com privately. For documentation or technical questions, contact sgilley@aishellgate.com directly.
What the beta is for
Does the policy model work for real operational workflows? Are rule definitions intuitive? Are risk classifications appropriate? Are confirmation levels correctly escalated? Are integration points clear and usable? Feedback from practitioners working in real environments is essential to refining the system. AI systems are capable of generating powerful commands. Power without policy is risk. AIShell-Gate exists to make the execution boundary explicit.
08 Looking for a Pilot Partner
AIShell-Gate is at the research pilot stage, and what we need most right now is a small number of teams willing to run it against a real environment and tell us where it breaks. If you are pointing AI agents at Linux infrastructure — over SSH, in a CI/CD pipeline, or through a coding assistant — and want a documented execution boundary in place while you do it, we would like to work with you directly.
A pilot partner gets direct access to the team building AIShell-Gate, a say in which policies and presets ship in 1.0, and hands-on help setting up whichever integration path — SSH or MCP — fits your environment. In return, we ask for structured feedback from a real deployment, not just a lab test.
If that sounds like a fit, email partnerships@aishellgate.com with a short note on your environment and what you are running AI against.
Who this is for
The right pilot partner already has AI touching real infrastructure and wants a real answer to "what's stopping it from doing damage" — not a sales conversation. If you are already asking that question, we should talk.
Separately: channel and licensing arrangements for MSPs, MSSPs, VARs, and system integrators are on the roadmap but not the current focus. If that's specifically what you're after, email cparrish@aishellgate.com and we'll keep you posted as that program develops.
