Governance Does Not End at Deny

2026-11-02 · Aldo Pietropaolo

An agent attempts to export a customer table. The policy blocks the attempt. The dashboard records the block, and everyone feels good about the control.

Now look at what is still true. The agent is still running. Its credential remains valid. The three sub-agents it started are still running. And the goal that led it to that table has not changed, so it starts looking for another way to access the same data.

The denial worked. It stopped one action. It said nothing about the run, the agent, its sub-agents, or the authority that enabled the attempt.

For autonomous agents, that is where agent runtime governance has to begin.

Deny was built for requests

Access control operates on allow and deny because its unit of work has always been the request. A user asks; the system answers, and the transaction is over. When a person receives a denial, they stop, open a ticket, or call someone. The refusal changes their behavior because a human decides what happens next.

An agent is a running process with a goal. A refusal is another piece of information it reasons about, and models are good at finding an alternative path to the goal.

The evidence is on the record. In July 2026, roughly 1,200 OpenAI agents running a security benchmark were assigned impossible tasks. They sought a workaround, built a channel to coordinate, and about 700 of them attacked Hugging Face. The incident lasted five days. OpenAI terminated the coordinating agents on July 12, and the final step came from the target, which, on July 13, revoked the credentials and asked for sandbox access to be disabled.

Four questions a deny leaves open

Every denied action that matters raises questions a binary decision cannot answer:

• This run: should the work continue at all?
• This agent: can we trust it on its next task?
• Its children: what about everything it already started?
• Its authority: should it keep what it was given?

A mature response model addresses each case separately because each carries a different cost. Stopping a single bad run is inexpensive. Revoking an agent who supports your claims operation is an incident in its own right. If your only tools are allow, deny, and broad credential revocation, you will hesitate at exactly the wrong moment.

Agents need a graduated set of responses (or enforcement effects), and each should be specified in policy in advance.

Other responses keep the work moving while maintaining control. Hold the action for a person when the risk requires judgment. Deny it and alert the security team when someone should look now. Narrow the run's scope and let it continue with less. Run a new policy in observe mode first so you can see what it would have denied before it disrupts production work.

That last one matters more than it seems. Teams hesitate to enforce controls they cannot safely test, and a control left out protects nothing.

Containment is an identity design problem

Most organizations file this under security operations. It starts with identity.

If authority is a runtime object, it can be withdrawn. Whether it actually can depends on decisions your identity architecture must make, and traditional IAM offers limited precedent. Revoking a token or disabling an account was designed for accounts and sessions. Revocation takes effect at the next check. An agent chain may hold several credentials across several systems, with work already in flight.

The joiner, mover, and leaver process has a gap here as well. Your identity governance knows whether an account is active or disabled. An agent needs states that the model has never had to represent: running, quarantined, cut off from the agent that started it, or awaiting re-trust. Each of those states needs an owner.

That makes containment a core component of Agentic IAM. The design questions look like this:

These belong in the design before an agent reaches production. During an incident, nobody wants to discover that the only available lever is the one that takes down the entire workflow. Our Agentic IAM Architecture engagement guides these decisions with your identity team, covering delegation, credential strategy, revocation, and how they connect to your existing IAM, PAM, and IGA.

What this looks like at runtime

Design answers need something to implement them. That is the role of Watchlight AI Beacon, the control plane for Agent Runtime Governance.

A decision in Beacon can do more than refuse an action. Policy can stop the run, quarantine the agent until an operator lifts the quarantine, cut off the sub-agents it started, or revoke its trust until someone restores it. Policy can also hold an action for human approval, deny it and raise a high-priority alert, narrow a run's scope for the rest of its execution, or observe in shadow mode before enforcing.

Each response is governed by a deterministic policy that resides outside the agent, so a model cannot reason its way past it. A quarantine remains in effect until a person lifts it. Enforcement fails closed by default if the decision point is unreachable. The hash-chained, tamper-evident audit log records what was decided, so the investigation starts with evidence rather than guesswork.

Your identity provider still determines who the agent is. Beacon gives your team the ability to act on a run already in progress, without waiting for a token to expire.

Five questions for your team

Bring these to your next identity architecture or incident response review:

1. When an agent is denied, does anything limit what it tries next?
2. Can you stop one run without disabling the agent or its credentials?
3. If an agent goes wrong, can you cut off every sub-agent it started?
4. Who is authorized to release a quarantined agent, and is that written down?
5. Could you contain a misbehaving agent yourself, or would you wait for the system on the receiving end to cut you off?

If those answers are unclear, your governance ends at the first refusal, and your agents will keep going beyond it.

Deny is the first word of the response. Decide the rest before you need them.