Authorization Before Action: Plan, Act, Observe in AI Agent Runtime Governance

Every action an AI agent takes proceeds through three stages: Plan, Act, Observe. Watchlight AI Beacon attaches at each, resolving authorization decisions before the action commits resources or modifies state.

Bottom line for CISOs. Authorization at the network gateway is necessary but late. By the time a request reaches the wire, the agent has already chosen the action, committed cognitive resources to it, and queued downstream side effects. Plan-stage authorization is the decisive control: it decides before any of that happens. Watchlight AI Beacon evaluates every agent action at the moment of intent, at the moment of execution, and at the moment of observation. Two enforcement layers (plugin and proxy) close the evasion paths neither could catch alone. This piece is the architecture behind AI Security Is Not Enough: The Case for Agent Runtime Governance.

A Wednesday Morning Post Mortem

The control point was correct. The control timing was wrong.

This scenario is illustrative, not a real customer incident. It describes a failure mode our design-partner conversations indicate is likely as enterprises scale agentic workloads.

On Wednesday, a customer's data agent decided, internally, to perform a cross-tenant lookup. By the time the request hit the customer's API gateway, the agent had already invested cognitive resources in the plan, committed downstream tool state, and queued five follow-up actions that depended on the lookup's result. The gateway returned 403. The agent retried, failed differently, replanned, attempted lateral workarounds, and ultimately consumed half a day of operational engineering attention.

The post-mortem flagged the right control (the gateway denied the action) and the wrong control point. The decision was made before the request was sent. The governance happened after.

Authorization at the gateway is necessary. Authorization only at the gateway is late. By the time the request reaches the network, the agent has already committed to the action and corrupted its own state preparing for it. The right control point is earlier.

The Visibility Problem in Agent Runtimes

No single integration point captures every agent action. Stage matters as much as framework.

Traditional API governance assumes a network choke point. That model works for service-to-service traffic. It breaks for agentic workloads, where the most consequential decisions happen in-process during planning, before any network call is made.

Different agent frameworks expose different surfaces. Some offer in-process extension points. Some emit observability streams. Some are reachable only over the network. There is no single integration point that captures every action.

The challenge is not "instrument one framework well." The challenge is complete coverage across every stage of every framework an enterprise runs in production.

Stage matters as much as framework. An agent's tool call has three distinct moments: when it is decided, when it is executed, and when its result is observed. Governance attached only at the execution moment is the security equivalent of auditing a transaction only after the money has moved.

The Three Stages of Every Agent Decision

Plan. Act. Observe. Three stages, three governance questions, one lifecycle.

Every action an AI agent takes proceeds through three stages. It Plans (forms an intent, selects a tool, structures the call). It Acts (executes the tool, sends the request, modifies state). It Observes (receives the result, updates its internal state, decides what to do next). Even non-deterministic LLM reasoning happens within a stage, not between them.

This three-stage lifecycle is the structural ground truth for the rest of this post. It is also codified as Principle 5: Plan-Act-Observe Lifecycle in the 12 Non-Negotiable Principles for Agent Runtime Governance.

Stage	Governance question	What Watchlight AI Agent Runtime Governance does
Plan	Is this plan allowed for this agent? Does the declared intent match the underlying goal?	Authorize the plan before any action executes. Block, allow, or require human approval. Pre-decision governance.
Act	Is this specific action permitted right now? Does it cross a tenant boundary? Does it satisfy temporal constraints (for example, "approval within 60 seconds")?	Policy evaluation. Rate limiting. Per-action enforcement at the point of execution.
Observe	Did the result match what was authorized? Did the action have unexpected side effects? Is the record complete enough for forensic review?	Update execution history. Produce the structured record set required for downstream review and audit.

Governance attached only at the Act stage catches violations but not decisions. Plan-stage governance catches the agent before it commits to a wrong action. Observe-stage governance produces the structured record that lets the SOC team see the full execution narrative.

Preflight Authorization: Deciding Before Acting

Watchlight AI Beacon evaluates the agent's intent before any tool call hits the wire. Denied plans burn no tokens, corrupt no state, and trigger no side effects.

When an instrumented agent generates a plan, Watchlight AI Beacon learns about it immediately, before any tool call hits the wire. The authorization plane evaluates the declared intent and the next action synchronously, returning a decision: allow, deny, or require human approval. All of that resolves before the framework executes the action.

Four operational consequences:

Resource conservation. An agent denied at plan stage burns no LLM tokens, no third-party API costs, no retry overhead.
State preservation. Internal state is not corrupted by a half-completed action blocked downstream. The framework hears "denied" cleanly, mid-plan.
Side-effect prevention. External systems are not touched at all for denied actions. No compensating-transaction logic in downstream services.
Forensic clarity. The audit log records the agent's intent, not just what was blocked at the gateway. SOC analysts see "agent declared intent to do X," a richer signal than "request to /api/X was 403."

Plan-stage authorization runs against the same policy set as act-stage authorization. Same policies, same evaluation, same audit. This is Principle 7: Agent Runtime Policy Enforcement applied earlier in the lifecycle: every action evaluated against current policy, but at the moment of intent rather than the moment of execution. The earlier check is a strict superset; what is denied at plan stage would have been denied at act stage anyway, but for fewer downstream costs.

For high-risk agents (those holding financial, PII, or administrative authority), plan-stage authorization is the default. For low-risk read-only agents, it is optional. Governance posture is proportional to the operational impact of the agent if compromised, the discipline behind Principle 3: Authority Is Explicit, Scoped, and Time-Bound.

Coverage by Framework

One plugin per framework for the semantic layer. One proxy for the wire. Defense in depth by design.

Watchlight AI Beacon attaches to each agent framework through a plugin: a small piece of integration code that registers with the framework's lifecycle hooks, emits the canonical execution events, and applies enforcement decisions where the framework allows. One plugin per framework. Plugins are what make plan-stage coverage possible. Watchlight AI Beacon integrates with each supported framework at the highest-fidelity surface that framework exposes. Some frameworks support synchronous plan-stage governance natively; others require complementary network-layer enforcement. For the current plugin announcement and supported frameworks, see Announcing the Watchlight AI Beacon Plugin Suite.

Framework	Plan	Act	Observe
LangGraph	✓	✓	✓
Google ADK	✓	✓	✓
AWS Bedrock Agents	†	✓	✓
MCP servers	✱	✓	✓
Microsoft Agent Framework §	Planned	Planned	✓
Custom / in-house agents	✓	✓	✓
Additional frameworks	‡	‡	‡

‡ Plugin coverage expands on a systematic and disciplined cadence. The next plugins on the public roadmap are expected to include other widely adopted agent frameworks; new plugins are prioritized by customer demand and verified production patterns, and each must meet the same trust-boundary requirements as the existing set before it ships. Watchlight AI reserves the right, in its sole discretion, to adjust plugin sequencing and the roadmap at any time.

† AWS Bedrock Agents do not expose a plan stage during execution. The Bedrock runtime makes its reasoning and tool-selection decisions internally and emits act-stage and observe-stage signals only. Plan-stage coverage for a Bedrock-based workflow is not something the plugin can supply on its own. It requires a custom customer-designed agent orchestrator that declares intent and proposed actions before delegating to the Bedrock runtime, so that Watchlight AI Beacon can authorize the plan before the underlying agent executes.

§ The Microsoft Agent Framework plugin ships today as a canonical-event observe-stage integration: the same lineage and audit event schema as every other supported framework, ready for governance evidence, forensic reconstruction, and cross-framework compliance dashboards. Plan-stage and act-stage enforcement for Microsoft Agent Framework are on the roadmap and follow the same prioritization and trust-boundary requirements as new framework plugins.

✱ MCP servers are reached over the network and do not expose a plan stage to external observers. The decision to call an MCP tool happens upstream, in the calling framework. For full plan-stage coverage of an MCP-using agent, instrument the calling framework as well.

Defense in Depth: Plugin and Proxy

Coverage is strongest when both layers are in place. The plugin enforces at the semantic layer, where it sees the agent's declared intent and the framework's lifecycle events. The network proxy enforces at the wire, where it sees every outbound request the agent makes, regardless of which code path inside the agent produced it. The two layers catch different evasions. An agent that bypasses framework instrumentation (a spawned subprocess, an unapproved HTTP library, or a compromised third-party package) cannot escape the proxy. A request whose declared intent the proxy cannot see is still caught by the plugin at plan stage. For high-risk agents, run both in-process and network-layer coverage simultaneously.

The Plugin Trust Boundary

Plugins are trusted services in the governance plane. That trust is structured and verified, not implicit. Authenticated. Bounded. Observable.

The enterprise installs plugins inside its agent frameworks, and Watchlight AI Beacon accepts the events they emit; both sides depend on the plugin behaving as declared. Plugins are subject to the same verification posture as any other service in the governance plane.

Authenticated provenance. Every plugin emits events using its own authenticated identity. The audit log binds every event to the emitting service. A compromised plugin trying to emit events on behalf of a different framework is detectable. This applies Principle 1: Agent Identity Is Mandatory to the integration layer itself: every service in the governance plane has a verifiable identity.
No privilege escalation through the plugin. Plugins get a documented event-emission contract bound to a specific service identity. They do not get blanket access.
Plugin failures are observable. If a plugin stops emitting events, the absence is recorded and can be surfaced. Missing data is as important to record as any other observation.
Capability conformance. The registration-time declaration of an agent's capabilities and the runtime record of what tools it actually invokes are captured independently. Plugins cannot conceal capability divergence. This is the discipline of Principle 11: Tool and Service Governance, where tool capabilities are declared, scoped, and verified.

Treating plugins as trusted-but-verified actors is the same posture Watchlight applies to every other service in the platform. There are no implicit trust paths.

Coverage as a Compliance Artifact

The coverage matrix, the canonical event schema, and the tamper-evident audit log are the answer to your auditor.

Framework	Control or article	How coverage maps
SOC 2	CC6.1, CC7.1, CC7.2	Plan-stage events satisfy access-classification evidence; observe-stage events produce the record set needed for continuous-monitoring evidence; a unified tamper-evident log produces the per-action audit trail.
NIST CSF	Identify, Protect, Detect	Plan-stage maps to Protect (preflight authorization). Act-stage maps to Protect (enforcement). Observe-stage produces the event record set that maps to Detect.
ISO 27001	A.12.4 (Logging and Monitoring)	A single unified log surface across all instrumented frameworks.
EU AI Act	Article 12 (record-keeping), Annex IV (technical documentation)	Per-framework plugin documentation plus a canonical event schema.

If your auditor asks, "How do you demonstrate that every action by every agent in production is monitored and that decisions are reviewable?" the answer is three artifacts:

The coverage matrix: a documented map of which agent frameworks are governed and at which stages.
The canonical event schema: the versioned, documented contract describing every execution event the platform emits. The same event shape applies across every supported framework, so a tool call from a Google ADK agent and a tool call from a LangGraph agent produce comparable, queryable records.
The tamper-evident audit log: an integrity-protected record of every governed action and policy decision. Each entry carries a cryptographic fingerprint, so modifications to historical records are detectable through verification rather than trust.

Together, these three artifacts implement Principle 9: Observability and Auditability, the discipline that every governed action produces a record an auditor can reconstruct.

Evaluation Path

If you are running AI agents in production today and your governance plane is enforced only at the network gateway, after decisions are made, there is a structured way to get a coverage assessment.

The Watchlight AI design partner program maps your existing agent fleet against supported frameworks, identifies where preflight authorization is reachable today versus where it requires additional instrumentation, and produces a private report. The exercise runs one to two weeks. The report is yours regardless of outcome. To start a conversation, contact us with a brief description of your agent footprint and the frameworks in production.

Closing

Governance happens at decision points. Decision points are inside frameworks. Frameworks are diverse and do not share a common integration model. Watchlight AI Beacon bridges that gap by attaching governance at the plan stage, before the agent has chosen the action, committed cognitive resources to it, or corrupted its own state preparing for it.

With coverage at every stage, every decision is reviewable, every action is policy-evaluated, and every enforcement point is auditable.