The Agent Tool Governance Stack: 5 Open Source Tools That Protect Production AI Agents

The bottom line: When an AI agent can issue refunds, execute code, and export data, a system prompt saying “follow the rules” isn’t a control — it’s a suggestion. A new category of open-source tools — Cupcake, Enforra, Cordum, AgentMint, and OQP — now sits between your agent and every tool call it makes. Here’s how they compare and when to use each.

The Governance Gap

LangChain’s State of Agent Engineering report found 57% of organizations have agents in production as of early 2026 [1]. Those agents call tools — database queries, payment APIs, shell commands, email senders. Each call is a potential blast radius.

Microsoft’s Agent Governance Toolkit benchmarks showed that prompt-based safety (telling agents to “be careful”) fails 26.67% of the time in red-team tests [2]. That’s not a security boundary — it’s a suggestion with a 1-in-4 failure rate.

The response has been a wave of open-source tools purpose-built for one job: intercept every agent tool call and decide before execution whether to allow, block, or escalate.

Cupcake: Policy-as-Code for Agent Actions

Released in December 2025 by EqtyLab, Cupcake is a policy enforcement layer that intercepts agent events and evaluates them against rules written in Open Policy Agent (OPA) Rego [3].

The key insight: rules live outside your agent’s context window. They don’t consume tokens, and agents can’t talk their way past a deterministic policy engine.

# Example Cupcake Rego policy — block tool calls outside working hours
package cupcake.tools

import future.keywords.if

default allow := false

allow if {
  input.tool_name == "execute_shell"
  input.time.hour >= 9
  input.time.hour < 17
}

Cupcake’s architecture intercepts agent events at the harness level — it integrates with Claude Code, Cursor, and custom agent frameworks. When an agent violates a policy repeatedly, Cupcake can trigger alerts and put the agent in a timeout state.

The project ships with a policy studio for interactive testing [4].

Enforra: Local Action Governance SDK

Enforra launched in mid-2026 as a lightweight SDK that wraps your application-owned tool callbacks [5]. It runs locally, makes no network calls, and returns one of four decisions: allow, block, require_approval, or log_only.

Feature	Cupcake	Enforra
Policy engine	OPA/Rego	YAML-based
Deployment	Agent harness level	Application callback level
Decisions	Allow/block/modify/alert	Allow/block/require_approval/log
Network calls	No	No
Audit trail	Event log	JSONL audit file

The SDK pattern means you don’t need to change your agent runtime — you wrap the callback and let Enforra evaluate policy before the real function runs:

const result = await enforra.enforceToolCall({
  tool: "stripe.refund",
  args: { amount: 250 },
  execute: async () => stripe.refund({ amount: 250 })
});
// execute only runs when policy returns allow or log_only

Enforra’s CI pipeline runs policy tests before deployment, so governance violations surface during development, not in production.

Cordum: The Agent Control Plane

Cordum describes itself as an “Agent Control Plane” — a source-available system that monitors and governs agent actions across your infrastructure [6]. It ships with Cordum Edge, a compliance firewall for Claude Code and other local agent actions.

Where Cupcake and Enforra focus on per-call enforcement, Cordum provides a centralized dashboard showing every agent across your fleet, what tools they’re calling, and which policies are being violated. It’s closer to a SIEM for agents than a simple policy engine.

Cordum ships with a local compliance firewall for Claude Code via a simple configuration file:

# cordum.yaml — Cordum Edge configuration
gateway: https://localhost:8081
api_key: ${CORDUM_API_KEY}
tenant: default
policy_mode: enforce          # also: monitor, off
approval_wait_timeout: 30s    # pause execution pending human approval

The Edge agent intercepts every tool call your agent makes — shell commands, file writes, API calls — and checks them against fleet-wide policies before execution. Violations are denied in enforce mode and surfaced in the Cordum dashboard.

Cordum uses the CAP protocol for agent communication and includes features like:

• Fleet-wide agent monitoring
• Centralized policy management
• Real-time violation alerts
• Compliance reporting

AgentMint and OQP: Compliance and Verification

Two newer entries round out the ecosystem:

AgentMint provides OWASP compliance for AI agent tool calls [7]. It maps agent actions to the OWASP Top 10 — helping teams identify injection risks, broken access controls, and data exposure in their agent tool chain.

OQP (Open Query Protocol) is a verification protocol for AI agents [8]. It creates verifiable attestations of agent actions, so downstream systems can verify that an action was authorized before trusting its output.

When to Use Which

Scenario	Tool	Why
Single coding agent (Claude Code / Cursor)	Cupcake or Cordum Edge	Harness-level integration, minimal setup
Custom agent framework calling your APIs	Enforra	SDK pattern, wraps existing callbacks
Fleet-wide visibility and compliance	Cordum	Centralized dashboard, multi-agent
OWASP compliance audit	AgentMint	Maps tool calls to security framework
Verifiable action proofs between agents	OQP	Attestation protocol for agent-to-agent trust

How to Apply This

1. Audit your agent tool surface. List every tool your production agents can call, the data it accesses, and the blast radius if called with malicious input.

2. Start with one tool. Pick the one that matches your deployment model. If you’re using Claude Code or Cursor, Cupcake or Cordum Edge integrate at the harness level. If you’re building custom agents with tool callbacks, Enforra wraps them without changing your runtime.

3. Write policies before you deploy. Define rules as code (YAML or Rego), test them in CI, then push to production. Both Cupcake and Enforra support CI workflows.

4. Enable audit logging from day one. All four tools produce structured audit logs — feed them into your existing observability pipeline.

5. Test with adversarial prompts. Don’t assume your system prompt holds. Red-team your agent against the policies themselves — can the agent talk its way past them? Deterministic policy engines (Rego, YAML-based) are immune to prompt injection by design.

The Pattern: Deterministic Enforcement Around Probabilistic Systems

The common thread across all five tools is the same architectural insight that made Kubernetes admission controllers successful: probabilistic systems (LLMs) make decisions, but deterministic guardrails enforce boundaries.

Your LLM decides which tool to call and with what arguments. The governance layer evaluates that decision against hard rules before it executes. The LLM can’t negotiate with a Rego policy — it either passes or it doesn’t.

This pattern — probabilistic reasoning inside deterministic boundaries — is becoming the standard production architecture for AI agents. And these five tools are how you implement it today.

[1] LangChain, “State of Agent Engineering 2026” — https://www.langchain.com/state-of-agent-engineering [2] Microsoft, “Agent Governance Toolkit” (April 2, 2026) — https://opensource.microsoft.com/blog/2026/04/02/introducing-the-agent-governance-toolkit-open-source-runtime-security-for-ai-agents/ [3] EqtyLab, “Cupcake — Policy enforcement for AI agents” — https://github.com/eqtylab/cupcake [4] Cupcake Policy Studio — https://cupcake-policy-studio.vercel.app/ [5] Enforra, “Action governance for AI agent tool calls” — https://github.com/enforra/enforra [6] Cordum, “Agent Control Plane for Governance, Safety, and Trust” — https://github.com/cordum-io/cordum [7] AgentMint, “OWASP compliance for AI agent tool calls” — https://github.com/agentmint/agentmint (Show HN: May 2026) [8] OQP Protocol, “Verification protocol for AI agents” — https://github.com/oqp-protocol/oqp (Show HN: May 2026)

← Back to all posts