Enforce Inside the Framework, Before the Action Runs
In-process plugins sit inside your agent frameworks and evaluate declared intent and every tool call at the Plan and Act stages. A drop-in install, a few configuration values, and no agent code changes.
Request a DemoThe Semantic Gap
A wire-level control sees requests. It cannot see the reasoning behind them. Governing an autonomous agent means governing the decision, not only the request it produces.
Intent Is Invisible on the Wire
By the time an action reaches the network, the agent has already decided to take it. Nothing has evaluated the agent's declared intent or authorized the plan before it started spending time, tokens, and money.
The Framework Holds the Richest Signal
Agents declare goals, select tools, spawn sub-agents, and move through Plan, Act, and Observe stages inside the framework. Governing only outside it leaves the agent's own lifecycle, the clearest signal you have, unused.
Per-Agent Instrumentation Does Not Scale
Teams want governance without rewriting agents. Hand-instrumenting each agent is brittle and inconsistent across teams and frameworks, and it breaks the moment a developer ships a new one.
How the Plugin Governs
Semantic governance inside the framework, at the moment the agent decides, not after the request is already on the wire.
Plan-Stage Authorization
The plugin evaluates the agent's declared intent and plan before any action runs. A bad plan is denied at zero cost, before it spends a dollar or touches a system.
Every Tool Call, Governed in Context
At the Act stage, each tool invocation is checked against current policy, the active goal, and the delegation chain, evaluated inside the agent's own runtime and denied before it executes.
Drop-In, No Agent Code Changes
Installation is a few configuration values. The plugin registers with the framework's lifecycle and applies consistently across every team that runs that framework.
One Policy, One Audit Trail
The plugin enforces the same deterministic policy and emits the same canonical audit events as the enforcement proxy, so an agent on any framework feeds a single governance plane.
Frameworks We Govern
One plugin per framework, all reporting to the same governance plane. Coverage per framework depends on what its lifecycle exposes.
LangGraph
Full lifecycle: Plan, Act, and Observe
Claude Agent SDK
Drop-in plugin, two enforcement boundaries
Claude Code
NewConfig-only hook: deny before every tool call
Google ADK
Full lifecycle: Plan, Act, and Observe
AWS Bedrock Agents
Act and Observe enforcement (Bedrock exposes no external plan stage)
Microsoft Agent Framework
Observe-stage lineage today; Plan and Act enforcement on the roadmap
Pydantic AI
Drop-in plugin, action authorization
DeepAgents
Drop-in plugin for long-running agents
OpenClaw
Drop-in plugin for long-lived agents
NVIDIA OpenShell
NewRuntime integration: Beacon decides every request inside OpenShell’s supervisor, alongside the in-agent plugin
MCP servers
Act and Observe enforcement at the tool boundary
Custom & in-house agents
Full lifecycle via a documented integration contract
One of Two Enforcement Layers
The plugin governs the agent's intent in-process, at the Plan and Act stages, and denies a bad action before it ever runs. The enforcement proxy governs every outbound request on the wire, whatever code path produced it, catching actions that step outside the framework through a spawned subprocess, an unapproved HTTP client, or a compromised dependency.
Both layers enforce the same deterministic policy and emit the same audit events, and they catch different evasions. An unauthorized action has to clear both. Bypass the plugin, and the proxy still stops you.
See the enforcement proxyKey Outcomes
Grounded in Governance Principles
Every capability traces back to the 12 non-negotiable principles for Agent Runtime Governance.
Common questions
How does Watchlight secure agents built on the Claude Agent SDK?
The Watchlight AI Beacon plugin for the Claude Agent SDK authorizes every tool call against current policy before it executes, and can require human approval when policy calls for it. When an agent spawns a subagent, Beacon governs the subagent as its own actor under its own scoped authority, so delegation never becomes privilege escalation. Every authorization decision, tool call and subagent spawn is recorded as tamper-evident execution lineage.
What are the two enforcement boundaries for the Claude Agent SDK?
The plugin runs inside the agent process, at the semantic layer, where it sees the agent’s identity, its actions, its subagents and the lifecycle of the run. The second boundary is Watchlight’s network proxy: when enabled, the agent’s outbound traffic routes through it with no change to agent code. An action that evades one boundary still meets the other. The plugin is available through Watchlight today and will be published to npm as it reaches general availability.
How does Watchlight govern the Model Context Protocol (MCP)?
Beacon discovers and registers every MCP server with its trust state, then enforces policy at the tool boundary: each governed MCP call is authorized before it reaches the server, and the call and its outcome are recorded in the same audit trail as every other agent action. Watchlight Developer Edition includes an MCP policy enforcement point that authorizes every governed call in-process, so a denied call never executes.
Do the framework plugins require changes to agent code?
No. Installation is a few configuration values. Each plugin registers with its framework’s lifecycle, applies consistently across every team that runs that framework, and enforces the same deterministic policy and emits the same audit events as the enforcement proxy. For Claude Code, it is a configuration-only hook that denies before every tool call.
Govern the Decision, Not Just the Request.
Authorize the plan before it runs, on the frameworks your teams already use.