CtrlAI is a transparent HTTP proxy that provides AI agent guardrails by sitting between agent SDKs and LLM providers. Built primarily for developers using frameworks like OpenClaw, it intercepts LLM responses, evaluates tool calls against configurable rules, and blocks dangerous operations—all without any modifications to the agent code itself. The proxy operates on a simple principle: any agent SDK that supports a custom baseUrl can be routed through CtrlAI, making it a drop-in security layer for AI agents. By decoupling safety enforcement from agent logic, CtrlAI enables teams to add robust security policies after development, ensuring that even autonomous agents remain constrained within safe boundaries.
AI agents powered by large language models frequently execute tool calls that can access files, run shell commands, interact with messaging platforms, or control hardware. Without guardrails, a rogue or misdirected agent could read SSH private keys, delete critical system files, exfiltrate environment variables, or send unauthorized messages. The core problem CtrlAI solves is the inherent trust gap between LLM-provided actions and the need for deterministic security controls. Developers cannot manually review every tool call in production, yet leaving agents unchecked risks data loss, compliance violations, or infrastructure damage. CtrlAI addresses this by providing a programmable safety layer that enforces policies before any tool call reaches the underlying system.
The first major feature group is the built-in guardrail rule set, comprising 19 pre-configured security rules enabled by default. These rules cover file system protection (blocking access to SSH keys, .env files, shell configs, browser passwords, and private keys), destructive commands (preventing rm -rf /, mkfs, dd if=, fork bombs), credential exfiltration via curl or wget, privacy violations (camera snap, screen recording, GPS location), messaging admin actions (kick, ban, timeout, role changes), and gateway configuration modifications. Each built-in rule can be individually toggled in the rules.yaml file, allowing organizations to start with a strong security baseline immediately. This approach ensures that even without custom rule writing, agents are protected against the most common and dangerous attack vectors.
The second major feature group is the custom rule engine, which allows users to define precise matching conditions in YAML. Rules can match on tool name, action field, agent ID, file paths using globs, substrings in arguments (arg_contains), regex patterns on commands (command_regex), and URL regex. Multiple fields in a single rule are ANDed, while lists within a field use OR logic, enabling complex conditions like 'block exec commands matching rm -rf on agent work'. The first matching rule wins, with a default allow behavior when no rule applies. Custom rules are evaluated after built-in rules, giving administrators full control to extend or override base protections. The ability to test rules without live traffic via the 'ctrlai rules test' command makes development safe and iterative.
admin
Additional capabilities include multi-agent support, an audit dashboard, and a kill switch. The proxy URL structure incorporates both a provider key (e.g., anthropic, openai) and an agent ID, allowing distinct rules, audit logs, and kill switches for each agent. The dashboard at /dashboard provides real-time visibility into proxy activity, while audit logs record every tool call and the action taken. The kill switch can instantly halt all traffic through the proxy, providing an emergency stop mechanism. Brotli decompression support handles compressed LLM responses, and the proxy forwards API paths transparently. These features combine to give operators comprehensive oversight and control over agent behavior.
CtrlAI works by acting as an intermediary HTTP proxy. The agent SDK is configured to send requests to the proxy's URL instead of directly to the LLM provider. The proxy forwards the request to the actual provider, receives the streaming response, and inspects each tool call returned by the LLM. For each tool call, it first evaluates the built-in rules (if enabled), then custom rules in order. If a rule matches and its action is 'block', the tool call is removed or replaced with an error message before the response is sent back to the agent SDK. If no rule blocks the call, it passes through unmodified. This transparent design means the agent code never needs to change—it simply sees the (possibly modified) response as if it came directly from the LLM provider.
Concrete use cases include restricting an intern agent from executing any shell commands or writing files, preventing any agent from accessing .env or SSH key files, blocking network exfiltration commands like scp or nc matching sensitive file paths, and testing new rules with sample tool call JSON before deploying. Organizations deploying multiple agents with different roles can assign separate security policies per agent—for example, a 'main' agent with full capabilities and a 'work' agent limited to reading code files only. The result is a production-ready safety layer that prevents accidental damage, malicious prompt injection, or credential leakage without slowing down development velocity. Teams gain confidence that their agents operate within approved boundaries at all times.
The target audience includes developers building AI agents who need to enforce safety policies without modifying agent code, security engineers responsible for governing LLM tool usage, and teams using agent SDKs like OpenClaw that require a transparent proxy for guardrails. The tool runs on Linux, macOS, and Windows, requires Go 1.24+ for compilation, and is distributed as a single binary. It is open source under the MIT license, with no vendor lock-in. By providing AI agent guardrails that require zero code changes, CtrlAI empowers teams to deploy autonomous agents with confidence, knowing that every tool call is audited and constrained by explicit, customizable rules.
Developers building AI agents using SDKs like OpenClaw who need to enforce safety policies without modifying agent code. Security engineers responsible for governing LLM tool usage across multiple agents. DevOps teams deploying autonomous agents into production and requiring granular runtime controls. Organizations managing diverse agent roles (e.g., main, intern, work) that need distinct security perimeters. Open source contributors seeking a flexible, zero-code proxy solution for AI agent guardrails.