One Runtime Control Plane. Every Agent Action Governed.
Watchlight AI Beacon sits between your AI agents and the systems they act on. Every action passes through the same gate: discovered, authorized, enforced, and recorded, in real time, at the moment it happens.
The Lifecycle of a Governed Action
No action is trusted by default. Each one runs the same four steps before it can touch a resource. Each step is a capability you can explore in depth.
Discovery & Registry
“What AI agents do we even have?”
Beacon continuously discovers every AI agent and MCP server running across your environment, then registers, classifies, and tracks the trust state of each one. You cannot govern what you cannot see, so visibility comes first.
Explore SeeAgentic Policy Decision Point
“Is this agent allowed to do this, right now?”
Before an action runs, Beacon evaluates it against current policy: the right agent, an approved purpose, and authority that is explicitly scoped and time-bound. No blanket, always-on access and no standing privilege.
Explore AuthorizeRuntime Enforcement Proxy
“What actually stops a bad action?”
Beacon sits transparently between the agent and the resource and blocks anything outside policy before it executes, with content safety, guardrails, and granular kill switches at the agent, group, and system level.
Explore EnforceRuntime Containment
“What stops a run that is already moving?”
Behavioral drift is scored against the agent’s own baseline and the plan it declared. When the score crosses the threshold policy draws, Beacon acts on the whole run: stop it, quarantine the agent, sever the delegation subtree beneath it, or revoke the authority fleet-wide.
Explore ContainExecution Lineage
“Who authorized this, and what happened?”
Every decision is captured as execution lineage: a tree-structured chain from the human who authorized it, through each delegation hop and policy decision, down to the resource it touched. Reconstruct any chain from a single ID.
Explore RecordDelegated authority
A Tool-Call Check Governs a Request. Beacon Governs the Execution.
An agent almost never acts for itself. It acts on authority delegated from a human. A per-call check asks whether an agent may call a tool. Beacon governs whose authority is being exercised, enforces that it can only narrow as it propagates through a chain of agents, and holds that boundary for the length of the run.
Delegated authority, not the token
Beacon models who or what granted authority, for which task, and with which constraints. The grant is the unit of governance, so a legitimate credential is never mistaken for permission to do anything with it.
Strict-subset attenuation
When an agent delegates to a sub-agent, the child receives a strict subset of the parent’s authority. Beacon validates that every child is a subset of its parent and denies any attempt to widen, before the action runs. Authority can only narrow.
Preserved back to the human principal
The chain back to the original human is preserved in execution lineage, so a sub-agent three hops down still cannot exceed what the person authorized, and every decision ties back to who set the work in motion.
Authority narrows at every hop
A sub-agent that requests authority beyond its parent is denied, before the action runs.
One Plugin Per Framework. One Governance Plane.
Enterprises never standardize on a single agent framework. Beacon meets every team where it is: a drop-in plugin for each framework, all reporting to the same policy engine and the same audit trail, with no agent code changes.
LangGraph
Full lifecycle: Plan, Act, and Observe
Claude Agent SDK
Drop-in plugin, two enforcement boundaries
Claude Code
Config-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
Runtime 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
Defense in Depth: Plugin and Proxy
The plugin layer and the enforcement proxy catch different evasions and share one policy decision. Run both: an unauthorized action must clear both layers to proceed.
Plugin Layer
Enforces at the semantic layer, where it sees the agent's declared intent and the framework's lifecycle events. This is the only layer that can authorize a plan before any action runs.
Enforcement Proxy
Enforces at the wire, where it sees every outbound request regardless of the code path that produced it. An agent that bypasses framework instrumentation, through a spawned subprocess or an unapproved HTTP library, still cannot escape the proxy.
What Makes It Deployable
The same governance extends to the frameworks your teams already run, on a deterministic engine that can operate with no outbound connectivity.
Cross-Framework Consistency
A research agent on LangGraph and a production agent on Google ADK enforce the same policies, produce the same event shape, and feed the same compliance dashboard. One governance plane, whatever runs underneath.
Deterministic Policy Engine
A deterministic policy engine evaluates every action against formal, versioned rules. Decisions are consistent and explainable, not left to the interpretation of the model being governed.
On-Prem & Air-Gapped
Because the engine evaluates every action locally, Beacon runs fully on-premises, including air-gapped environments with no outbound connectivity. The most sensitive deployments never depend on a vendor cloud.
What This Architecture Delivers
Common questions
What are Beacon’s two enforcement layers?
An in-process plugin enforces at the semantic layer, where it sees the agent’s declared intent and the framework’s lifecycle events; it is the only layer that can authorize a plan before any action runs. An enforcement proxy enforces on the wire, where it sees every outbound request regardless of the code path that produced it. Both share one policy decision, so an unauthorized action has to clear both.
How does Beacon govern agent-to-agent delegation?
With strict-subset attenuation. When an agent delegates to a sub-agent, the child receives a strict subset of the parent’s authority, and Beacon denies any attempt to widen it before the action runs. The chain back to the original human principal is preserved in execution lineage, so a sub-agent several hops down still cannot exceed what the person authorized.
Is a language model part of the authorization decision?
No. A deterministic policy engine evaluates every action against formal, versioned rules. Decisions are consistent and explainable, and they are not left to the interpretation of the model being governed.
See the Runtime Control Plane in Action.
Walk through how Beacon governs a live agent action, from intent to enforcement to lineage.