ironcurtain
starsforks
How to install ironcurtain?
provos/ironcurtain
$git clone https://github.com/provos/ironcurtain**A secure\* runtime for autonomous AI agents, where security policy is derived from a human-readable constitution.**
README.md
| 1 | # IronCurtain |
| 2 | |
| 3 | [](https://github.com/provos/ironcurtain/actions/workflows/ci.yml) |
| 4 | [](https://www.npmjs.com/package/@provos/ironcurtain) |
| 5 | [](LICENSE) |
| 6 | [](https://ironcurtain.dev) |
| 7 | |
| 8 | **A secure\* runtime for autonomous AI agents, where security policy is derived from a human-readable constitution.** |
| 9 | |
| 10 | _\*When someone writes "secure," you should immediately be skeptical. [What do we mean by secure?](https://ironcurtain.dev)_ |
| 11 | |
| 12 | > [!WARNING] |
| 13 | > **Research Prototype.** IronCurtain is an early-stage research project exploring how to make AI agents safe enough to be genuinely useful. APIs, configuration formats, and architecture may change. Contributions and feedback are welcome. |
| 14 | |
| 15 | ## Demo |
| 16 | |
| 17 | <p align="center"> |
| 18 | <img src="demo.gif" alt="IronCurtain mux demo: trusted input from command mode enables auto-approval of git clone and git push" width="800"> |
| 19 | </p> |
| 20 | |
| 21 | The agent is asked to clone a repository and push changes. Both `git_clone` and `git_push` are escalated by the policy engine, but the auto-approver approves them automatically — the user's trusted input from command mode (Ctrl-A) provided clear intent, so no manual `/approve` was needed. |
| 22 | |
| 23 | ## The Problem |
| 24 | |
| 25 | Autonomous AI agents can manage files, run git commands, send messages, and interact with APIs on your behalf. But today's agent frameworks give the agent the same privileges as the user such as full access to the filesystem, credentials, and network. Security researchers call this **ambient authority**, and it means a single prompt injection or multi-turn drift can cause an agent to delete files, exfiltrate data, or push malicious code. |
| 26 | |
| 27 | The common response is to either restrict agents to a narrow sandbox (limiting their usefulness) or to ask the user to approve every action (limiting their autonomy). Neither is satisfactory. |
| 28 | |
| 29 | ## The Approach |
| 30 | |
| 31 | IronCurtain takes a different path: **express your security intent in plain English, then let the system figure out enforcement.** |
| 32 | |
| 33 | You write a **constitution** which is a short document describing what your agent is and isn't allowed to do. IronCurtain compiles this into a deterministic security policy using an LLM pipeline, validates the compiled rules against generated test scenarios, and then enforces the policy at runtime on every tool call. The result is an agent that can work autonomously within boundaries you define in natural language. |
| 34 | |
| 35 | The key ideas: |
| 36 | |
| 37 | - **The agent is untrusted.** IronCurtain assumes the LLM may be compromised by prompt injection or drift. Security does not depend on the model "being good." |
| 38 | - **English in, enforcement out.** You write intent ("no destructive git operations without approval"); the system compiles it into deterministic rules that are enforced without further LLM involvement at runtime. |
| 39 | - **Semantic interposition.** Instead of giving the agent raw system access, all interactions go through [MCP](https://modelcontextprotocol.io/) servers (filesystem, git, etc.). Every tool call passes through a policy engine that can **allow**, **deny**, or **escalate** to the user for approval. |
| 40 | - **Defense in depth.** Agent code runs in a V8 isolate with no direct access to the host. The only way out is through semantically meaningful MCP tool calls and every one is checked against policy. |
| 41 | |
| 42 | ## Architecture |
| 43 | |
| 44 | IronCurtain supports two session modes with different trust models: |
| 45 | |
| 46 | - **Builtin Agent (Code Mode)** — IronCurtain's own LLM agent writes TypeScript snippets that execute in a V8 sandbox. IronCurtain controls the agent, the sandbox, and the policy engine. Every tool call exits the sandbox as a structured MCP request, passes through the policy engine (allow / deny / escalate), and only then reaches the real MCP server. |
| 47 | |
| 48 | - **Docker Agent Mode** — An external agen |
People who liked this also viewed
6 picksType
- mcp-scannerScan MCP servers for potential threats & security findings.MCP ServersJul 2026
- hol-guardOpen-source antivirus for AI agents: block risky tools, secret access, prompt injection, malicious packages, MCP servers, plugins, and skills at runtime.MCP ServersJul 2026
- agent-scanSecurity scanner for AI agents, MCP servers and agent skills.MCP ServersJul 2026
- falcon-mcpConnect AI agents to CrowdStrike Falcon for automated security analysis and threat huntingMCP ServersJul 2026
- python🔐 Plug-and-play auth for Python MCP servers.MCP ServersAug 2025
- auth0-mcp-serverConnect LLMs and AI agents to Auth0 Management APIs via an MCP server. Use natural-language commands to create apps, deploy Actions, and query logs—runs locally and supports interactive tenant authentication for secure Auth0 administration from AI tools/CLIs.MCP ServersJul 2026
