An AI agent has permission to adjust a cooling unit in a data center.
The request is valid. The asset is correctly identified. The agent’s permit is active.
But the backup cooling unit is unavailable, the grid has limited reserve, and another unit is already degraded.
Should the agent proceed?
My answer is no.
The authority to act tells us who may perform an action. It does not tell us whether the surrounding infrastructure can safely absorb its consequences at that moment.
That distinction will become increasingly important as AI agents move from answering questions to operating tools, engineering systems and physical assets.
Permission is only the first decision
Consider a pump serving a city’s water network.
An agent may be authorized to isolate the pump for maintenance. Under normal conditions, a redundant pump can maintain the service. But today, that redundant pump is unavailable.
The same action, performed under the same permit, could now interrupt supply to an entire service area.
This is the operational gap that concerns me: an action can remain authorized while the conditions that made it safe have changed.
The question for infrastructure owners is therefore not simply:
“Can the agent access the system?”
It is also:
“Can the system safely tolerate this specific action, here and now?”
That requires more than a list of permissions. It requires awareness of asset condition, dependencies, environmental constraints, available capacity and the possible consequences of acting.
From static permission to a live operating envelope
I think of the operating envelope as the set of conditions within which a particular action can be performed safely.
For a cooling adjustment, those conditions might include:
- The health and availability of adjacent cooling units.
- Backup power and cooling redundancy.
- Current load and available headroom.
- Ambient temperature.
- Equipment limits and site operating procedures.
For a drone mission, the relevant conditions might include weather, airspace restrictions, battery status and the location of people or other aircraft.
For a pump isolation, they might include network demand, alternative flow paths and the condition of redundant equipment.
These conditions are not fixed when a permit is issued. They can change minutes or seconds before execution.
That is why I would separate two decisions:
- Authority: Is this agent permitted to perform this action on this asset for this purpose?
- Admissibility: Given current conditions and the expected consequences, is the action acceptable now?
A valid permit is necessary, but it is not sufficient.
The result may be:
Permitted, but currently inadmissible.
This is a more useful response than a generic error. It tells the operator that the agent has the right authority, while identifying the condition that prevents safe execution.
Why digital twins matter here
Digital twins are often discussed as visual models of assets and facilities. Their greater value may lie in connecting information that changes the next decision.
A decision-ready twin could bring together:
- Asset context: Which equipment is involved, and is its identity reliable?
- Dependency context: Which systems and services depend on it?
- Current evidence: What do sensors, inspections and operational records indicate?
- Capacity context: What headroom and redundancy are available?
- Authority context: What is the agent allowed to do?
- Consequence context: Who or what could be affected?
This does not mean every digital twin can already answer these questions. Many cannot. A visually convincing model may contain stale asset data, incomplete relationships or assumptions that have never been checked against the field.
Nor should an AI model’s interpretation become the sole safety mechanism. For consequential operations, established engineering controls, interlocks, operating procedures and accountable human oversight remain essential.
The twin can make those controls more informed. It should not silently replace them.
The evidence must be good enough for the decision
A live operating envelope is only as trustworthy as the information behind it.
Suppose a sensor reports that backup cooling is available. Was the reading received seconds ago or yesterday? Does it reflect actual operating capacity, or merely that the equipment is powered on? Has the sensor itself been validated?
A responsible workflow should evaluate the age, source and reliability of the evidence not just the value displayed on a dashboard.
If a critical reading is stale, missing or contradictory, the system needs a defined response. Depending on the action and the hazard, that could mean holding execution, requesting another observation, or escalating to an operator.
A human approval should not automatically make an unsafe action safe. The person reviewing the request needs the relevant context, a clear explanation of the uncertainty and authority to choose an appropriate response.
And because conditions can change between a check and execution, critical constraints need to be enforced close to the point of action, with monitoring during the operation where appropriate.
A practical decision chain
For teams exploring agentic operations, I would start with a simple chain:
Request → Authority check → Current operating conditions → Consequence assessment → Action or hold → Verification
Each stage asks a different question.
Request: What exactly is the agent trying to do, to which asset, and for what purpose?
Authority: Does its identity and permit cover this action, location and time?
Operating conditions: Are the relevant assets, dependencies, resources and environmental conditions within acceptable limits?
Consequence: What could happen if the action succeeds, fails or produces an unexpected result?
Action or hold: Should the system proceed, wait, seek better evidence or request an accountable decision?
Verification: Did the intended change occur, and did the physical system respond as expected?
The final step matters. A successful software command is not necessarily proof of a successful physical outcome. A valve may receive an instruction without moving as expected; a model revision may be issued without the corresponding field change ever taking place.
The action, its evidence and its outcome should therefore be recorded together.
Agent access to engineering and geospatial tools is expanding
This is becoming a practical design question because agents are gaining access to more operational information and tools.
The Open Design Alliance has described MCP servers intended to let agents query CAD and BIM model information, including geometry, properties and structure. That makes engineering information more accessible but reading a model and approving a revision remain different responsibilities. Open Design Alliance
SkyFi has also introduced an MCP interface connecting AI agents to satellite imagery and selected geospatial analytics. That raises another governance question: if an agent can seek additional evidence, what type of observation may it request, within what budget, and who approves a consequential purchase or mission? SkyFi
These examples do not demonstrate that autonomous physical operations are already safe. They show why we need to define the boundaries before connecting more powerful actions to agent workflows.
A useful starting point is to distinguish observe, recommend, prepare and execute, with stronger controls as consequences increase. NIST’s work on agent identity and authorization similarly highlights the need to connect agent actions to accountable authority. nccoe.nist.gov
Refusal is an operational capability
A well-designed refusal should help the team move forward.
Instead of simply saying “action denied,” the system might report:
Action held: Cooling Unit C17 setpoint change is authorized, but backup cooling is unavailable and the adjacent unit is degraded. Current redundancy does not meet the required operating condition. Operator review and updated equipment status are required.
The operator can then investigate the constraint, restore redundancy, choose a different action or decide whether a formally governed exception is appropriate.
This makes refusal part of the workflow, with a reason, an owner and a path to resolution.
For owners and operators, the business value is clear: fewer preventable interruptions, better visibility into dependencies and a more defensible record of how consequential decisions were made. The value will depend on the quality of the underlying data, engineering rules and implementation not on the presence of an AI agent alone.
As physical AI develops, we should measure maturity by more than the number of tasks an agent can complete.
We should also ask whether it knows when the conditions for action have disappeared and whether the surrounding system can reliably stop it.
