A Tool-Call Check Is a Feature. Governing Delegated Authority Is an Architecture.

A year ago, "runtime authorization" was a phrase a small group of us used while the market conversation was somewhere else. This year every identity, PAM, cloud, MCP, and agent-security vendor claims it. Agent identity, per-tool-call authorization, runtime policy checks, and least privilege for agents are now table stakes.

We read that convergence the way a category creator should: as validation of the problem we defined, not as evidence that it has become a commodity. It does mean one thing, though. "We check the action at runtime" is no longer a differentiator, and the real question has moved to harder ground.

Here is the sentence that frames where it moved:

Identity establishes who the agent is and what it can access. Watchlight governs whether, how, and under whose delegated authority the agent may act, enforces it where actions execute, and preserves the lineage of what follows.

What a single check answers, and what it misses

A per-tool-call authorization check answers a real and useful question: is this agent, with this token, allowed to call this tool. Get that right and you have closed a genuine gap. Every serious vendor is now racing to close it.

But hold that check up against what an autonomous agent actually does, and the gaps are structural.

It does not ask under whose delegated authority the agent is acting. An agent is almost never acting for itself. It is acting on authority delegated from a human, and the legitimacy of an action depends on that grant, not just on the token the agent happens to hold.

It does not ask how far that authority has narrowed. When an agent hands work to a sub-agent, the child should be able to do less than the parent, never more. A per-call check on the child has no memory of the parent's grant, so it cannot enforce that the authority only shrank.

It does not ask where in the chain the action sits. A single call looks fine in isolation. A sequence of individually-allowed calls can still add up to something no one authorized, and a check that sees one action at a time cannot see the sequence.

And it does not preserve what follows. Once the action executes, a per-call check is finished. It cannot tie the action back to the human who set the work in motion, and it cannot inform the next decision or contain a chain that has gone wrong.

None of this is a criticism of doing the check. The check is necessary. It is just not the architecture.

The architecture: authority, execution, lineage

Governing delegated authority across an agent's execution is a different discipline, and it has parts that a runtime check does not.

Delegated authority. Model who or what granted authority, for which task, with which constraints, and how that authority narrows through every downstream delegation. The grant, not the token, is the unit of governance.

Deterministic execution governance. Make the decision before the action executes, using identity, delegated authority, the declared task and goal, the action arguments, execution state, policy, and risk context. And make it deterministically. If a language model is anywhere in the authorization decision, a persuasive justification can talk its way past the control, and it is no longer enforcement. This is the single sharpest question to ask any vendor: is a model in your trust path.

Authority propagation. Track agent-to-agent delegation, prevent authority from expanding as it flows down the chain, and preserve the relationship back to the original human principal, so a sub-agent three hops down still cannot exceed what the person authorized.

Execution lineage. Preserve the causal chain from human intent through delegation, decisions, actions, downstream agents, and effects. Not as an after-the-fact log, but as a record that can inform the next authorization decision and support containment.

Runtime effects. Move beyond allow and deny. When an execution chain has to be contained, the response has to include terminating a run, quarantining an agent, severing a delegation subtree, and revoking authority.

Independent enforcement. Do all of this with two independent control points, in-process inside the agent framework and on the wire, so that bypassing one does not defeat governance, and without requiring one agent platform, cloud, or gateway.

Put those together and you are no longer performing a check. You are governing the exercise, propagation, and consequences of delegated authority across the whole execution lifecycle.

Why the category creator can still claim the ground

We did not add a runtime check to an existing product. We defined Agent Runtime Governance as a category, published the 12 Non-Negotiable Principles as its architectural framework, and submitted a 37-page technical architecture with 20 sequence diagrams to NIST's National Cybersecurity Center of Excellence as part of its work on AI agent identity and authorization.

The vendors converging on runtime authorization are, in effect, implementing pieces of that architecture. That is a good thing for the industry, and it is exactly why the differentiation is no longer the idea. It is the completeness. Watchlight AI Beacon was built around the whole problem, deterministically, framework-independent, and sovereign, with a Developer Edition that puts the same enforcement primitive directly in the build and execution path where agents are made.

The question to standardize on

When a prospect says they are evaluating runtime authorization, the honest reframe is this. A per-call check is a feature, and you can now buy it from many places. Governing delegated authority across an execution chain, deterministically, with lineage that informs the next decision and effects that can contain a chain, is an architecture, and it is the one we defined.

Identity establishes who the agent is and what it can access. Watchlight governs whether, how, and under whose delegated authority the agent may act, enforces it where actions execute, and preserves the lineage of what follows.