Runtime Governance for Always-On AI Agents: Controls Worth Building Before an Incident Forces the Question

One implication of agents running around the clock across a sprawl of platforms is that governance cannot end with pre-deployment approval. A useful question for decision-makers is what would stop an agent from taking an action outside its authorized scope while it is running.¹

SiliconANGLE’s report on Dell Technologies’ AI Leadership Symposium describes the challenge: controls built for deterministic software were not designed for agents operating continuously across platforms.¹ Pre-deployment approval can establish intent, but it does not by itself show whether actions during execution stayed within policy.

Why pre-deployment approval isn’t enough for AI agent runtime governance

Pre-deployment review can set intended permissions, approved use cases, and ownership. Runtime governance, by contrast, examines behavior during execution. The report distinguishes defining what an agent is allowed to do from assessing its behavior while it operates.¹

A broad task description can obscure a consequential step. Shiv Agarwal, Singulr AI’s co-founder and CEO, cited reaching out to the internet for data and sending email to a private account as actions that may be hidden inside an agentic workflow.¹ Permission to complete a task should not automatically be treated as permission for every action along the way.

A practical approach is to re-check permissions at meaningful steps, rather than treating authorization as a gate cleared once at launch. As a proposed control, inspect an action before it reaches a tool or destination, compare it with policy, and then allow, hold, or deny it.

That approach also suggests tying stated purpose to execution evidence. For example, a support-agent evaluation could check whether an agent approved to summarize a case touches an unapproved data source or sends information outside the intended workflow. This is a proposed test scenario, not a description of a specific deployed agent.

What AI agent monitoring should record

Monitoring should give an investigator enough context to reconstruct what the agent attempted and what the control decided. Agarwal described the challenge as reconciling enterprise intent with actual runtime state, rationalizing overlapping controls, and checking whether they work in practice.¹

A proposed event record for each meaningful step could include:

• Agent identity and the responsible user or service owner.
• Task context, model and provider, and any material change to them.
• Tool invoked, data requested, destination, and resulting action.
• Policy decision and the rule that produced it.
• Cost and escalation state, such as paused, denied, or referred for approval.

These are proposed fields for an evaluation schema, not items specified in the report. The goal is to make decisions auditable; a raw log of tool calls may not be enough to explain why an action was permitted or blocked.

As proposed test criteria, flag an unexpected external data request, communication to a private account, a new endpoint or tool, a change in model or provider, repeated denied actions, or activity outside the agent’s declared pattern. The first two are drawn from the report’s examples; the rest extend them as evaluation scenarios.¹

Monitoring may also need to cover activity beyond centralized infrastructure. Agarwal said Singulr extended its agent governance to local AI tools on employee endpoints.¹ That suggests an inventory limited to centrally hosted agents could miss activity in other environments.

Which enterprise AI agent controls can constrain an agent while it’s running

A control that records a violation only after the fact supports investigation, but does not prevent the action. As a proposed design principle, put enforcement where it can inspect a tool call, data path, destination, or model route before execution. Candidate controls include provider and model allow-lists, destination restrictions, tool-specific permissions, network egress rules, human approval gates, and spend limits. Buyers comparing orchestration products may find it useful to treat production controls as the buying test.

For sensitive actions, consider controls that can deny, pause, redact, or route an action for approval, rather than only logging it. An external data request and an email to a private account are useful acceptance tests because the report identifies them as examples of actions that can be hidden inside an agentic workflow.¹

Where model calls happen matters to some organizations. Sri Viswanath said some CIOs want agent and large-language-model calls kept inside their virtual private clouds because they do not know where data goes once it leaves.¹ The report does not prescribe how to weigh that preference against other operational needs. Teams can document their required data paths, then test whether their routing controls enforce those paths and record the decision.

A multi-provider enterprise AI gateway could serve as one enforcement point, but it would not replace endpoint, network, or tool-level controls where those are needed. Evaluate each control by asking what it can inspect, what it can block, which environments it covers, and what evidence it emits. A routing policy that governs only calls passing through one gateway would not govern calls that bypass it.

Handling a detected policy violation

A policy decision needs an owner and response path, not just a log entry. One proposed sequence is to block or pause the action, preserve the event record, notify the responsible platform or security team, assess affected data and destinations, and decide whether to resume, restrict, or disable the agent.

Set escalation authority before deployment rather than during an incident. An agent owner could investigate an expected exception; security or privacy teams could handle suspected data exposure; and platform operators could be responsible for revoking credentials, changing routing, or disabling a tool. These are proposed operating responsibilities; the report does not specify roles.

Match the response to the assessed risk. A lower-risk deviation might generate a review event. An attempted private-account email, an unapproved external request, or repeated policy failures could trigger a block and suspension of the relevant credential or tool. Decide in advance which conditions require immediate intervention and who can authorize a restart.

Cost belongs in the same operating model: cost and control were recurring concerns at the Dell symposium.¹ As a proposed safeguard, a runtime response could enforce a budget boundary or halt unexpected activity, with an owner reviewing the cause before service resumes. For a closer look at one cost risk, see testing for retries that cost money in unattended agents.

Proving runtime controls work across environments

A policy document describes intent; it does not demonstrate that enforcement works across platforms, endpoints, providers, and agent versions. Agarwal called for checking controls in practice and reconciling enterprise intent with actual runtime state.¹

As a proposed evaluation, test the same permitted and prohibited actions in each environment in scope. Include the report’s examples—an agent attempting to reach the internet for data and an agent attempting to send email to a private account¹—along with a model or provider swap, a substituted tool, a denied action retried through another path, and a request crossing a designated data boundary.

For each test, retain evidence of:

• Whether the action was allowed, blocked, or paused.
• Which policy produced that decision.
• What context was captured for investigation.
• Whether an escalation reached the responsible team.
• Whether the result was consistent across environments.

Test failure behavior as well. For example, simulate an unavailable policy service, logging path, model provider, or approval channel, then check whether the agent fails closed, pauses, or continues under a defined fallback. These are proposed tests, not procedures specified in the report.