Watchlight and the Cedar Ecosystem

Watchlight is built on Cedar — the open-source, formally-verified policy engine — and it's part of a growing set of Cedar-based projects for authorizing AI agents, several of them from AWS. These projects solve different problems and sit at different layers of the stack, so this page simply lays out what each one is and how Watchlight relates to it. The goal is orientation, not a scoreboard.

The pieces

• Cedar — the decision core. It answers a single, precise question — "may this principal take this action on this resource, in this context?" — and answers it deterministically. Cedar reasons about one request at a time. Watchlight embeds real Cedar; every Watchlight decision is a Cedar decision.

• cedar-for-agents (AWS) — build-time tooling. Its main piece generates a Cedar schema from an agent's MCP tool definitions, so your tools and your policies share one vocabulary. It's a way to author policy against agent tools; it isn't a runtime.

• Dogwood (AWS) — a policy language that extends Cedar with temporal logic. Where Cedar reasons about a single request, Dogwood reasons about a sequence of them: rate limits, ordering, prerequisites ("approval within the last hour"), and aggregate caps ("no more than a set amount transferred per hour"). It ships as a language specification and a reference interpreter.

• Watchlight — a runtime. It embeds Cedar to make the decision, then enforces that decision against a live agent and governs everything around it.

How they differ — languages, tooling, and a runtime

The clearest way to hold these apart is by the layer each operates at. Cedar and Dogwood are policy languages — they express what should be allowed. cedar-for- agents is authoring tooling — it helps you write the schema. Watchlight is the enforcement runtime — it applies decisions to a running agent and handles what happens next.

That difference in layer is why Watchlight covers ground a language doesn't. A language decides; a runtime has to act, and act on the messy cases:

Concern	Addressed by
Decide a single request	Cedar (and Watchlight, which embeds it)
Reason over a sequence of requests	Dogwood (as declarative policy); Watchlight, via learned behavioral baselines and time budgets
Generate a policy schema from MCP tools	cedar-for-agents
Detect an agent drifting from its normal behavior	Watchlight (drift/anomaly detection)
Act on a decision — quarantine, terminate a run, sever a sub-agent tree, revoke trust	Watchlight
Confine a sub-agent to a strict subset of its parent's authority	Watchlight
Govern by declared intent and goal (escalate, require justification)	Watchlight
Route an action to a human and track the approval	Watchlight
Produce a signed, tamper-evident record of what happened and why	Watchlight
Inject credentials the agent never sees; gate outbound calls	Watchlight
Run multi-tenant, with roles and per-tenant policy	Watchlight

On temporal policy specifically

Dogwood and Watchlight both care about behavior over time, and it's worth being precise about how they differ, because they're complementary rather than overlapping. Dogwood lets you write a temporal rule as policy — an explicit "at most five per hour." Watchlight comes at the same concern from two other angles: it learns each agent's normal shape and flags deviations (drift detection), and it enforces time budgets across a run and its sub-agents.

Because Dogwood is backward-compatible with Cedar — any valid Cedar policy is a valid Dogwood policy — and Watchlight already embeds Cedar, declarative temporal policy is a layer that composes cleanly with the runtime rather than competing with it.

In one line each

• Cedar decides a single call.
• Dogwood expresses rules over a sequence of calls.
• cedar-for-agents generates the policy schema from your tools.
• Watchlight is the runtime that enforces those decisions on a live agent and adds the behavioral detection, containment, confinement, lineage, and human-in-the-loop around them.