Cupcake Governance and Augmentation Orchestrator

Cupcake provides several key security and governance features:

• Granular Tool Control: Prevent specific tools or arguments (e.g., blocking rm -rf /).
• MCP Support: Native governance for Model Context Protocol tools (e.g., mcp__memory__*, mcp__github__*).
• LLM-as-Judge: Use a secondary LLM or agent to evaluate actions for dynamic oversight.
• Guardrail Libraries: Integrations with NeMo and Invariant for content and safety checks.
• Observability: Structured logs and evaluation traces for all inputs, signals, and decisions.

Watchdog is Cupcake's LLM-as-a-judge capability. It provides semantic security analysis by evaluating AI agent tool calls using an LLM before they execute. This complements deterministic policy rules by providing context awareness and dynamic reasoning to catch threats that don't match simple patterns.

Workflow:

1. An AI agent attempts a tool call.
2. Cupcake intercepts the event.
3. Watchdog sends the event to an LLM.
4. The LLM returns a structured judgment (allow/deny, confidence, reasoning).
5. This judgment is available to your policies as input.signals.watchdog.
6. Your policies decide the final outcome based on this signal.

Cupcake is a policy enforcement layer for AI coding agents. It intercepts agent events (such as shell command execution or file edits) and evaluates them against user-defined rules written in Open Policy Agent (OPA) Rego.

Instead of relying on model context (which consumes tokens and can be ignored), Cupcake uses policy-as-code to provide deterministic guarantees. It sits in the agent hook path and returns decisions in milliseconds.

Cupcake supports two evaluation models:

1. Deterministic Policies: Written in OPA/Rego and compiled to WebAssembly (Wasm) for fast, sandboxed evaluation.
2. LLM-as-Judge (Cupcake Watchdog): Uses a secondary LLM to evaluate actions for dynamic oversight when static rules are insufficient.

Choosing between evaluate() and evaluateSync() depends on your application type:

Performance Benchmarks:

• Initialization: ~100-200ms (one-time, includes policy compilation)
• Evaluation: <1ms for simple policies, 1-5ms for complex policies
• Concurrency: Supports thousands of concurrent evaluations.

All Claude Code hook events in Cupcake are unified by a common structure. Every payload implements the EventPayload trait, which provides access to CommonEventData.

CommonEventData Fields

• session_id: String
• transcript_path: String
• cwd: String
• permission_mode: PermissionMode

PermissionMode Enum

Indicates the current permission level for the session:

• Default: User is prompted for dangerous operations.
• Plan: Claude creates plans without executing them.
• AcceptEdits: File edits are auto-approved.
• BypassPermissions: All tool calls are auto-approved (dangerous).

Special Traits

• InjectsContext: A marker trait implemented by payloads that support special stdout handling for context injection. These include SessionStart, UserPromptSubmit, and PreCompact.

When a policy denies an action in Cursor, Cupcake supports providing differentiated feedback. This allows you to send a simplified message to the user while providing detailed technical context to the AI agent to help it learn from the violation.

In a Rego policy, the decision object can include both reason (for the user) and agent_context (for the AI).

Example Rego Decision Structure:

deny contains decision if {
    input.hook_event_name == "beforeShellExecution"
    contains(input.command, "rm -rf")
    decision := {
        "reason": "Dangerous command blocked: rm -rf",
        "agent_context": "This action violates system policies. Recursive deletion of directories is prohibited for security reasons.",
        "rule_id": "CURSOR-SECURITY-001",
        "severity": "CRITICAL"
    }
}

Cupcake includes several Built-ins—special policies enabled by default in rulebook.yml that protect critical system functionality and cannot be easily bypassed by AI agents. These provide layered security at both the global and project levels.

Common Built-ins:

• rulebook_security_guardrails: Protects the .cupcake/ directory from being tampered with or deleted by an agent.
• protected_paths: Blocks modifications to sensitive system paths like /etc/ or /System/.
• git_pre_check: Validates git operations.
• git_block_no_verify: Blocks git commands that attempt to skip verification (e.g., using --no-verify).

Builtins are high-level policy abstractions that allow you to implement common security patterns without writing Rego.

Enabling/Disabling:

• To enable: Simply configure the builtin. If a builtin has any configuration keys, it is enabled by default.
• To disable: Set enabled: false or remove the configuration entirely.

Scope:

• Project-level: Configured in .cupcake/rulebook.yml.
• Global-level: Configured in ~/.config/cupcake/rulebook.yml. Global configs take precedence and cannot be overridden by project configs.