AI
Mapping the coding agent loop to a trajectory event model
Coding agent scaffolds plan, generate, execute, and run tools in loops. Maisel maps that action space into four trajectory event types: actions (writing files, running shell commands, executing code), observations (environment feedback fed back to the next model call), control events (user prompts, permission requests, sub-agent orchestration), and state events (memory compaction, environment snapshots). Each type marks a concrete point where an attacker can inject, exfiltrate, or escalate. The lethal trifecta, untrusted input arriving as an observation, sensitive data already in context, and a shell command that ships it out, lands cleanly on this model. So do multi-step attacks that chain observations and actions across several turns.
Why a reference monitor plus Cedar, not prompts or sandboxes
Prompts are inside the model. A reference monitor sits outside it, mediating every trajectory event before it reaches the environment. Maisel’s design demands the monitor be always invoked, tamperproof, and verifiable. Those properties are what make it a hard boundary rather than a suggestion.
“a reference monitor by itself is it’s only as good as the policy enforcement uh points that it supports” — Matt Maisel
Cedar supplies those points. Unlike Rego, Cedar’s formal methods flag contradictory, vacuous, or shadowed policy subsets before deployment. Attribute-based access control maps cleanly to agent entities (agent, user, trajectory), so data-sensitivity tags and YARA signature results become first-class policy inputs. Policies can also be generated from existing context files (CLAUDE.md or Cursor rules), converting informal intent into enforceable Cedar forbids.
Building the hook-based policy harness
Local adapters sit at each hook point, receiving events over stdin, normalizing them into the trajectory model, and forwarding them to a harness service. Inside that service, a Cedar engine extracts entities and runs them through pluggable guardrails — currently YARA signatures, an information-flow control model, and a safety model. Results feed back into entity and trajectory stores for stateful bookkeeping across turns. Writing Cedar policies by hand is tedious, so a policy agent generates and validates them via MCP tools, using Cedar’s formal properties to catch contradictions before deployment.
Harness demos: policy generation, command blocking, PII taint tracking, and lethal trifecta interception
Three demos, three threat classes. First, a policy agent fetches the Cedar schema and generates shell-injection policies on demand — the harness blocks a DELETE FROM users with no WHERE clause (08:33), returning the violation context to the agent for steering or user review. Second, Gemini CLI observes a name, date of birth, and address in the trajectory, taints it, and the harness blocks a subsequent web fetch to Google (09:04) — no per-call rule required, just the IFC label. Third, a public marketplace skill containing metrics.py quietly harvests environment variables and phones home. The harness catches it at the shell command event via YARA signatures before it runs (09:54).
Q&A
For the IFC model, are you tagging the data or labels using AI? A GPT Safeguards 20B model classifies sensitivity labels based on example policies you provide, though any DLP or data classification system can supply those labels instead. ▶ 12:38
Who decides what the policy should be for a given agent, and where in the hook lifecycle does enforcement sit? Policy authorship sits with the engineering team, sourced from existing intent in CLAUDE.md or cursor rules files, then formalized into Cedar and enforced at the pre/post hook points around tool and LLM calls. ▶ 13:23
How does the Cedar policy engine work with first-party agents like LangChain or Copilot Studio? Cinderea open-sourced a Cedar policy engine that embeds directly into Python-based agent frameworks including LangChain, Strands, and ADK. ▶ 15:07
How does Cedar complement an existing permission system like Claude Code’s bash permissions? Cedar adds trajectory context on top of static wildcard permissions, so a command can be allowed by default but blocked the moment the trajectory carries a tainted IFC label. ▶ 15:43
Have you experimented with multi-agent architectures where trajectories converge and diverge? The current work targets single agents; multi-agent boundary policies using contextual integrity are a planned direction but not yet implemented. ▶ 16:27
Notable Quotes
a reference monitor by itself is it’s only as good as the policy enforcement uh points that it supports Matt Maisel · ▶ 3:17
this is a deterministic policy engine that’s outside the model. So you know we we don’t have to simply rely on safeguards or instructions and prompts Matt Maisel · ▶ 10:46
permission systems can induce consent fatigue and have missing context Matt Maisel · ▶ 11:01
we’re we’re making this trade-off of giving the agent more access and given more utility to do useful things for us and then trying to dynamically determine when to revoke that access Matt Maisel · ▶ 14:12
Key Takeaways
- Hook every coding agent event through a Cedar reference monitor — don’t trust safeguards baked into the model itself.
- Taint the trajectory when PII appears so downstream network calls are automatically blocked without per-call rules.
- Generate Cedar policies with an LLM, then use Cedar’s formal tools to verify them for contradictions before deploying.