I build an open-source runtime security layer for AI agents – Let's break it

Pryxor, a self-hosted open-source runtime gateway for AI agents, evaluates an agent's concrete tool call before it reaches an external system and returns one of three outcomes — APPROVED, HOLD, or BLOCKED — with the agent never receiving the executor's upstream credentials. In the project's Docker-based demo, an email to an internal domain (alice@company.local) returns status APPROVED, while an email to an external domain (bob@example.com) returns status HOLD with reason EXTERNAL_EMAIL and retry set to false, meaning nothing is sent. Pryxor requires Docker 24+, Docker Compose v2, and Git, and its author states it is not an LLM firewall and does not understand user intent by itself, enforcing only explicit deterministic controls at the action boundary.

AI agents often have valid credentials and still perform the wrong action. A token can authorize access to a CRM, a database, an email provider, or a payment API. That does not mean every request made with that token should be allowed. Pryxor is a self-hosted runtime gateway that evaluates an agent's concrete action before it reaches the real system. The agent proposes. Pryxor decides. A trusted executor acts. Pryxor can: - approve safe actions; - block forbidden actions; - pause risky actions for human review; - execute approved actions without exposing upstream credentials to the agent; - record the policy decision, approval lifecycle, and execution result. It is designed for agents that can send messages, modify data, access files, call APIs, or perform other externally visible actions. Pryxor is not an LLM firewall and does not currently understand user intent by itself. It enforces explicit, deterministic controls at the action boundary. Traditional authorization usually answers: Can this identity call this API? Agent security also needs to answer: Should this exact action be allowed now? Those are different questions. An agent with valid read access to a CRM might: - retrieve far more records than the task requires; - repeat individually valid requests until it exports an entire customer table; - read sensitive data and then send it to an external destination; - continue acting after the user's task has already been completed; - perform a destructive action because the API credential technically permits it. Pryxor does not claim to solve all of these problems automatically. It provides the enforcement point where these decisions can be made explicitly, tested, audited, and connected to human approval. AI agent | | proposes a tool call v Pryxor runtime | | authenticate the agent | validate the arguments | evaluate deterministic policy | approve, block, or hold v Trusted executor | | uses the real credential | calls the external system v External API The agent does not receive the executor's API URL or upstream secret as part of the execution contract. Every governed action returns one of three outcomes: - APPROVED - HOLD - BLOCKED A HOLD is not a retryable error. The agent must not simply submit the same action again. The demo uses a simulated HTTP endpoint. It does not send a real email. See the QUICKSTART.md https://github.com/Pryxor/pryxor/blob/main/QUICKSTART.md for the full walkthroug. Requirements: - Docker 24+ - Docker Compose v2 - Git git clone https://github.com/Pryxor/pryxor.git cd pryxor make init make up make health The example policy contains two rules: - emails to an internal domain are approved; - emails to an external domain are held for review. Register an agent: make register AGENT=ops agent Copy the returned agent key: export PRYXOR AGENT KEY="your-agent-key" export PRYXOR URL="http://127.0.0.1:8000" Call the simulated email tool with an internal recipient: curl -s "$PRYXOR URL/v1/execute-tool" \ -H "X-Agent-Key: $PRYXOR AGENT KEY" \ -H "Content-Type: application/json" \ -d '{ "tool name": "send email", "parameters": { "to": "alice@company.local", "subject": "Hello", "body": "This is an internal test." } }' | python -m json.tool Expected result: { "status": "APPROVED", "execution": { "success": true } } Now try an external recipient: curl -s "$PRYXOR URL/v1/execute-tool" \ -H "X-Agent-Key: $PRYXOR AGENT KEY" \ -H "Content-Type: application/json" \ -d '{ "tool name": "send email", "parameters": { "to": "bob@example.com", "subject": "External test", "body": "This action requires review." } }' | python -m json.tool Expected result: { "status": "HOLD", "action id": "hold ...", "reason": "EXTERNAL EMAIL", "retry": false } Nothing has been sent. Register an administrator: make register-admin NAME=reviewer Then approve the hold: make approve HOLD ID=hold ... Pryxor executes the action only after the approval and records the approving administrator in the audit trail. Policies are explicit and deterministic: { "type": "declarative", "rules": { "name": "allow-internal-emails", "when": { "tool": "send email", "to domain in": "company.local" }, "then": { "approve": true } }, { "name": "hold-external-emails", "when": { "tool": "send email" }, "then": { "hold": "EXTERNAL EMAIL", "message": "External recipients require human approval." } } } Rules are evaluated before the executor is called. For security-sensitive deployments, Pryxor should use a default-deny policy: an action without an explicit valid authorization rule must not execute. - runtime interception of governed tool calls; - agent and administrator authentication; - argument validation against tool schemas; - deterministic APPROVED, HOLD, and BLOCKED outcomes; - durable human approval state; - approval and rejection lifecycle tracking; - credential isolation from the agent; - configurable HTTP executors; - idempotency keys for execution attempts; - redacted audit records; - metrics and notifications; - MCP support; - Python SDK; - adapters for selected agent frameworks; - single-node Docker deployment. Pryxor is not: - a replacement for IAM; - an LLM prompt-injection detector; - a sandbox for hostile code; - a complete data-loss-prevention system; - a monitoring or tracing platform; - a guarantee that an external API will execute exactly once; - a system that automatically understands the user's intent. Pryxor can only govern actions that are actually routed through it. If an agent has another path to the external system, that path must be removed or separately controlled. A compromised agent host with a valid Pryxor key may still submit requests as that agent. Production deployments need network controls, key rotation, least privilege, and host isolation in addition to Pryxor. Pryxor is an early-stage open-source project. The current release is suitable for: - local evaluation; - security experiments; - staging environments; - single-node deployments; - building integrations and policy prototypes. It is not yet ready to claim: - high availability; - multi-tenant SaaS; - SSO or enterprise RBAC; - a management dashboard; - regulated-environment compliance; - protection against every form of data exfiltration; - autonomous intent understanding. Security claims matter only when their boundary is explicit. Read KNOWN LIMITATIONS.md before using Pryxor with real systems. The project is moving in four directions: - default-deny behavior; - strict policy validation; - action-bound approvals; - policy simulation and tests; - cumulative budgets and rate limits. - clearer timeout and unknown-outcome handling; - connector-specific idempotency; - revalidation immediately before execution; - safer retries and recovery. - approval inbox; - role-based reviewers; - policy versioning; - approval notifications; - audit export. - PostgreSQL-backed state; - horizontal scaling; - SSO; - secret-manager integrations; - additional MCP and framework integrations. The core runtime will remain open source under the Apache-2.0 license. The most useful contributions are: - adversarial test cases; - policies that expose dangerous edge cases; - executor integrations; - MCP compatibility reports; - framework adapters; - security reviews; - documentation improvements. A useful issue is not just “this feature would be nice.” It is a concrete scenario: Here is the tool call, here is the policy, here is what should happen, and here is what happened instead. Please report security vulnerabilities privately. See SECURITY.md . Apache License 2.0