Hooking Coding Agents with the Cedar Policy Language

Hooking Coding Agents with the Cedar Policy Language

Speaker: Matt Maisel — CTO and Co-Founder, Sendera

Conference: [un]prompted 2026 — The AI Security Practitioner Conference

Date: March 3–4, 2026, San Francisco

Watch on YouTube: https://www.youtube.com/watch?v=m6pzrqFJ6hE

Reading time: ~8 minutes

TL;DR

Coding agents plan, generate, execute, and loop — and every step of that loop is a potential policy enforcement point. Matt Maisel of Sendera demonstrates how to intercept the full trajectory of a coding agent using tool hooks and adjudicate every action with the Cedar policy language, creating a deterministic, formally verifiable security boundary that operates outside the model itself and cannot be bypassed through prompt injection.

Introduction

Coding agents are powerful precisely because they are autonomous. They plan, generate code, execute shell commands, read files, write outputs, and loop until they complete the task. That autonomy is also the attack surface. A prompt injection in a fetched skill file, a malicious MCP server on a public marketplace, a shell command that exfiltrates environment variables to an external endpoint — these threats play out within the same loop that makes agents useful.

Matt Maisel, CTO and co-founder of Sendera, has spent 15 years at the intersection of machine learning, security, and software engineering. At [un]prompted 2026, he delivered a rapid-fire technical talk — explicitly flagged as a lightning talk — that in under 15 minutes outlined a complete architectural approach to governing coding agent behavior using the Cedar policy language. The core thesis: model-level safeguards are necessary but insufficient. What's needed is a deterministic reference monitor, outside the model, that mediates every action the agent takes.

▶ Watch: Introduction and Agent Loop Overview (0:00)

The Trajectory Event Model: Mapping the Agent Loop

The foundation of Maisel's approach is a formal model of what coding agents actually do. Coding agent scaffolds plan, generate, execute code, and run tools in loops. This action space maps onto four event types:

• Actions: The agent initiates actions — writing or modifying files, running shell commands, executing code. These mutate the environment.
• Observations: The environment returns feedback to the agent after each action, providing input for the next model inference step. This is where untrusted data enters the loop — a skill file fetched from a public marketplace, a web page with injected content, an API response.
• Control events: User prompts, permission requests, sub-agent orchestration — how the agent receives direction and coordinates with other agents.
• State events: Memory compaction, pruning, environment snapshots — the agent's internal bookkeeping.

With this model in place, the threat landscape maps directly onto trajectory events. The lethal trifecta — the three conditions that together create a dangerous agent — can be expressed precisely:

1. Untrusted input arrives as an observation (a skill file fetched from a public marketplace that contains injected instructions)
2. Sensitive data is already in the agent context or retrieved from memory (source code, internal documentation, PII)
3. Exfiltration capability exists through state changes (shell commands or code execution that send data out)

"With this trajectory model, you can also reason about more complex, multi-step attacks that play out over multiple turns of the loop and involve combinations of control events and state events. You can also map other threat and risk models, like the OWASP Top 10 for Agentic Applications, onto this same framework."

▶ Watch: Trajectory Model and Threat Mapping (2:00)

Reference Monitors and Agent Hooks

A reference monitor sits outside the agent and the model, mediating every event. Ideally it is always invoked, tamper-proof, and verifiable — a hard security boundary between the events the agent produces and the rest of the system. But a reference monitor is only as good as the policy enforcement points it supports.

Agent hooks provide those enforcement points. Different coding environments expose hooks differently:

• Gemini CLI: Before-and-after model hooks that let you stream individual tokens and do processing on them
• Claude Code: No model hooks; only a final agent response returned as a notification event type
• Cursor: Fairly granular hook types covering MCP, shell commands, and more generic tool calls

Each hook lifecycle event becomes a policy enforcement point. The goal is to intercept trajectory events, process them, and decide whether to allow, modify, or stop the agent's loop — before any action reaches the environment.

▶ Watch: Agent Hooks as Enforcement Points (4:00)

Why Cedar: Formally Verifiable Policy Language

For expressing policies over trajectory events, Maisel chose the Cedar policy language — originally developed at Amazon and designed for attribute-based access control in cloud services.

Cedar's properties that make it suited for this domain:

• Expressive: Supports complex attribute-based conditions across entity schemas
• Fast: Engineered for real-time policy evaluation
• Formally analyzable: Uses the Lean symbolic compiler to enable formal verification — Cedar policies can be analyzed for contradictions, vacuous policies, and other problematic policy subsets that would be undetectable through testing alone
• ABAC support: Attribute-based access control maps naturally to agent trajectory domain, where decisions depend on rich contextual attributes — trajectory labels, data sensitivity, agent state

Compared to Rego (used in Open Policy Agent), Cedar's formal properties allow automated analysis of the policy set as a whole, not just evaluation of individual policies.

A Cedar schema for a shell command action and context type might attach entity attributes including:

• Agent identity and role
• Trajectory state and accumulated labels (data sensitivity classifications)
• Signature tags from YARA rule matches
• Values computed from safety models or other guardrails

Policies are written against all of these attributes, enabling rich conditional authorization.

The Harness Architecture

The full harness that Maisel demonstrated at [un]prompted 2026 consists of:

Local adapters: Commands that coding agents run as hooks. These intercept trajectory events over standard input, transform them into the unified trajectory event model, and forward them to the local harness service.

Cedar policy engine: Inside the harness service. Extracts entities from trajectory events, processes them against three classes of guardrail:

• YARA signatures: Pattern-based detection of known-malicious content in shell commands, code, or fetched files
• Information flow control (IFC) model: Tracks data sensitivity labels across the trajectory, propagating taint as sensitive data enters and moves through the agent context
• Safety model: A GPT Safeguards 20-billion-parameter model that classifies data against sensitivity label policies defined through examples — used for the IFC classification

Entity and trajectory stores: Stateful bookkeeping. As entities are observed and their attributes evolve over the conversation, those attributes are tracked and exposed as dynamic attributes in Cedar policy evaluation. This gives Cedar — which is inherently stateless — access to trajectory-level context for stateful multi-turn decisions.

▶ Watch: Building the Harness (6:00)

Four Concrete Examples

Maisel demonstrated the system through four specific scenarios:

Policy generation via MCP: A policy agent with a skill containing procedural knowledge about Cedar and tool-calling instructions. The agent fetches available entity types and context values from the schema, receives a request to write policies for shell injection, and produces Cedar policies grounded in the actual schema — using entity types, context types, IFC label values, and YARA rule set categories. Because Cedar's formal tools can verify these generated policies, agent-authored policies can be deployed with confidence.

Blocking a destructive SQL command: Cedar policies look for SQL mutations without constraints — specifically DELETE FROM users without a WHERE clause. When Claude attempts to execute this command, the hook intercepts it, the policy engine returns a violation with full context, and that context is fed back to the agent to steer it toward a corrected approach (or surfaced to the user for review).

Multi-turn information flow control: Using Gemini CLI. PII enters the agent context — a name, date of birth, address. The safety model classifies this as highly confidential and taints the trajectory with that label. On a subsequent turn, when the agent attempts a web fetch or network command, the policy engine sees that the trajectory carries a sensitive-data label and dynamically blocks the tool call, returning context explaining why.

Lethal trifecta in action (Cursor): A skill from a public marketplace claims to generate code quality metrics. Inside the skill is a script that harvests environment variables and sends them to an external endpoint. When the agent attempts to run the script, the hook intercepts the shell command event, processes the script file against YARA signatures and the safety model, detects environment variable harvesting and outbound network activity, and blocks execution — making all context available for policy-level and user review.

▶ Watch: Live Examples (8:00)

Advantages Over Existing Approaches

Maisel positioned the Cedar-based harness relative to two existing defense mechanisms:

Permission systems (agent approval prompts): Induce consent fatigue as users click through repeated permission requests. They also lack trajectory context — each approval decision is made in isolation, without knowledge of what data has already been tainted or what the agent has already observed.

Sandbox systems: Often overly restrictive. They operate at the syscall or process level and cannot express context-dependent decisions. A shell command that's fine in most contexts might be dangerous if the agent's trajectory already contains sensitive PII — sandbox can't make that distinction.

The Cedar harness operates at the trajectory level, with rich context available at every decision point. It complements both approaches rather than replacing them.

Challenges and Open Problems

Maisel was candid about three significant challenges:

The Goldilocks policy zone: Policies need to be tuned for the specific agent context. Overly restrictive policies cripple agent utility; overly permissive ones miss threats. Brittle pattern matching on destructive commands (like rm -rf) can invite policy hacking — sophisticated prompt injection could phrase equivalent operations in ways the pattern doesn't catch.

Policy scalability: The policy agent with formal Cedar tooling helps — but agent-assisted policy generation is still evolving. Writing and maintaining Cedar policies by hand for complex agent deployments is nontrivial.

Temporal reasoning: Cedar is inherently stateless. The entity and trajectory store provides a workaround, tracking attributes over time and exposing them as dynamic attributes. But for sophisticated multi-turn stateful policies — reasoning about sequences of actions, temporal ordering constraints — other logic systems like temporal linear logic may eventually be more expressive.

▶ Watch: Challenges and Q&A (10:00)

Delivery and Open Source

The primary deliverable from this work is an open-source Cedar policy engine integrated with coding agent hooks, available on GitHub via the QR code shown at the talk. A separate open-source Cedar policy engine for any Python-compatible agent framework (supporting LangChain and similar) is also available.

The implementation is deterministic and operates outside the model — unlike prompt-based guardrails, it cannot be bypassed through prompt injection against the model itself. It surfaces trajectory context to every policy decision, which neither permission systems nor sandbox systems can match.

Notable Quotes

"A reference monitor sits outside the agent and the model, mediating every event. Ideally this monitor is always invoked, it's tamper-proof, and it's verifiable — making it a hard security boundary." (from transcript)

"The lethal trifecta is three conditions that together create a dangerous agent: untrusted input, sensitive data access, and external output capability." (from transcript)

"Cedar policies can be analyzed through formal methods to check for contradictions, vacuous policies, and other problematic policy subsets. Unlike Rego, you get this through the formal properties of the language itself." (from transcript)

"Permission systems can induce consent fatigue and have missing context. Sandbox systems might be overly restrictive. This approach gives you trajectory context in your policy decisions, which is more expressive than either approach alone." (10:00)

Key Takeaways

• The trajectory event model — actions, observations, control events, state events — provides a precise framework for mapping coding agent behavior to policy enforcement points at every step of the agent loop.
• Cedar's formal properties (contradiction detection, vacuous policy analysis via Lean compiler) make it uniquely suited for agent policy governance where policy correctness is security-critical.
• Information flow control via trajectory tainting enables multi-turn decisions: sensitive data that enters the agent context in one turn can influence what the agent is permitted to do in subsequent turns.
• The harness is deterministic and outside the model — unlike prompt-based guardrails, it cannot be bypassed through prompt injection or model manipulation.
• The Goldilocks policy zone is a real challenge: policies must be tuned per agent context to avoid either utility degradation (too restrictive) or threat miss (too permissive).

Slides Reference

Slides are available as 2026-04-04-D1-S2-14-33-Hooking-Coding-Agents-with-the-Cedar-P.pdf. Key slide topics include:

• Trajectory event model diagram: actions, observations, control, state events in the agent loop
• Lethal trifecta threat model mapped to trajectory events
• Cedar policy schema for shell command action and context types
• Harness architecture: local adapters → Cedar policy engine → entity/trajectory stores
• Four demo scenarios: policy generation, destructive SQL blocking, IFC multi-turn, lethal trifecta with Cursor
• Challenge framing: Goldilocks policy zone, policy scalability, Cedar statefulness limitations