Watchlight — Developer Edition

Govern an AI agent in five minutes. One install, zero infrastructure, same API as production.

Watchlight puts a policy decision point in front of every action your agents take. It authorizes each tool call and records a value-free audit trail.

The Developer Edition runs the real authorization engine in-process, inside your own program. You do not need a server, a database or an account. You get a governed ALLOW / DENY on your laptop, from the same code you ship to production.

pip install watchlight        # Python 3.9+, prebuilt wheels
npm install @watchlight/sdk   # Node 18+, the compiled engine comes with it

Quickstart

Python — save as agent.py, run python agent.py:

from watchlight import govern, configure_default, Denied

configure_default(agent="research-agent")                # the name on every record

# Permit ONLY "research". Fail-closed: everything else is denied.
govern.allow('permit(principal, action == Action::"research", resource);')

@govern.tool(intent="research")
def web_search(query: str) -> str:
    return f"results for: {query}"

@govern.tool(intent="transfer")           # governed, but no policy permits it
def transfer_funds(to: str, amount: int) -> str:
    return f"sent ${amount} to {to}"      # never runs — denied first

print(web_search("watchlight docs"))      # ALLOW → the body runs
try:
    transfer_funds("mallory", 1000)       # DENY → refused before the body runs
except Denied as e:
    print(e)

TypeScript / Node — the same program ("type": "module" or a .mjs file):

import { govern, configureDefault, Denied } from "@watchlight/sdk";

configureDefault({ agent: "research-agent" });

govern.allow('permit(principal, action == Action::"research", resource);');

async function webSearch(query: string) { return `results for: ${query}`; }
async function transferFunds(to: string, amount: number) { return `sent $${amount} to ${to}`; }

const search   = govern.tool(webSearch,     { intent: "research" });
const transfer = govern.tool(transferFunds, { intent: "transfer" });   // nothing permits it

console.log(await search("watchlight docs"));   // ALLOW → the body runs
try {
  await transfer("mallory", 1000);              // DENY → refused before the body runs
} catch (e) {
  if (e instanceof Denied) console.log(e.message);
}

Both lanes print the same decisions:

watchlight: governing 'research-agent' (dev mode, in-process engine)
watchlight: ALLOW  research  tool/web_search
results for: watchlight docs
watchlight: DENY   transfer  tool/transfer_funds     not authorized
watchlight denied intent 'transfer' on tool/transfer_funds: not authorized

Node names the same tools tool/webSearch and tool/transferFunds. Both also print a one-time note that no audit sink is configured.

That DENY is the product. The transfer_funds body never ran, and the decision is already on disk in .watchlight/audit.jsonl.

What you can govern

The table below shows what to install, and which call to use, for each kind of thing you might want to govern, first for Python and then for Node.

pip install "watchlight[all]" is one install for the whole Python lane, and every Python example in the documentation runs after it. On the Node lane @watchlight/sdk is the only install you need.

Both lanes write .watchlight/audit.jsonl, and watchlight dev tails it:

watchlight dev            # → http://localhost:7000

Who is acting, and on whose behalf

A governed call keeps two identities apart: the runtime that is acting (the agent), and the person or system it is acting for (the subject). A policy can look at either one, or at both. In the example below, the flight-booker runtime may book on behalf of any user:

// this runtime may book for any user — whoever it acts for
permit(principal is User, action == Action::"book", resource)
when { context.actor == "flight-booker" };

The table shows where each part of that answer lives in the request that a policy sees.

That is what separates a policy from an if: it names whichever runtime is acting and whoever it acts for. The SDK sets context.actor itself and refuses a caller-supplied value that disagrees, so a policy can trust it.

Where to go next

→ The documentation index — every page, and when to read it.

Runnable programs live in examples/ — start with governed_research_agent.py or ts/examples/agent.mjs. Copy-paste policy recipes for the high-stakes decisions — spending money, deleting things, messaging the outside world, stopping a runaway agent — are in examples/patterns/, each one run through the real engine.

A note on identity

The Developer Edition authorizes the principal you assert — the agent you construct the governor with, or the Watchlight-Agent-Id on a governed MCP request. It does not cryptographically prove the caller. On your own machine, running both sides, that is the right trade.

Bind any non-loopback listener behind something that authenticates the caller — a reverse proxy doing mTLS or OIDC, or the Enterprise plane.

Identity hardens as you grow, without changing your policies:

• Developer Edition — the principal is asserted (cooperative, local dev).
• Next — an optional signed session token binds the principal to a key your process holds, so a prompt-injected sub-agent cannot rewrite a header to escalate. It still needs no external infrastructure.
• Enterprise — identity is attested: federated (OIDC) and workload (mTLS), verified across the fleet.

Only how strongly the principal is proven changes. The policies do not.

Developer Edition vs Enterprise

Enterprise points the same code at a running control plane, so there is nothing to rewrite. What changes is what happens around the decision. The first table lists what the Developer Edition already does and Enterprise keeps; the second lists what only Enterprise does.

What the Developer Edition does, and Enterprise keeps

What only Enterprise does

Everything the Developer Edition leaves out needs state outside your process: a fleet to revoke across, a plane to quarantine into, or a key to sign lineage with. It keeps every guarantee that fits in one process, and those work identically in both editions: fail-closed semantics, strict-subset attenuation bounded by a configurable delegation-depth limit, explicit scopes, and a value-free audit trail.

→ The platform · email sales@watchlight.ai

Govern locally. Manage centrally.

You already have the decision. Cloud gives you everything around it — central policy, decision history that outlives the container, an inventory of every agent, environments, and a team that can see all of it.

The authorization decision stays in your process — same engine, same latency, and your agents keep deciding if Cloud is unreachable. It attaches to the options you already have: audit_sink, counter_source, approval_store. Nothing to rewrite, and no upgrade needed.

Open source, and the license

Everything you write against is open and Apache-2.0 — the govern decorator and scope attenuation, the CLI and the watchlight dev dashboard, the framework plugins, the MCP PEP's transport layer, and every example here.

You do not have to trust a black box to trust the decisions. Policies are standard Cedar — open, formally specified, and deterministic. The integration layer is readable, so you can see exactly what the engine is asked and what it returns. And every ALLOW / DENY lands value-free in a file you can grep.

The decision engine ships as a compiled wheel — watchlight-engine and the watchlight-mcp runtime — under the Watchlight Developer Edition license. Both are free to use, including in production and commercially. A commercial license is needed only to re-offer the engine itself as a hosted authorization service.

Want the engine source, an air-gapped build, or to govern a fleet in production? email sales@watchlight.ai.