An infrastructure owner authorizes an AI agent to investigate a transformer.
The agent can read the asset record, review inspection images and examine maintenance history. It can prepare a recommendation for the operations team.
Everything appears to be working as intended.
Then the agent sends the transformer’s inspection imagery, BIM geometry and protection configuration to an external AI model.
The agent has not opened a valve, dispatched a crew or changed a setting. Yet an important boundary may already have been crossed.
The question is no longer just “Can this agent access the asset?”
It is also “Where is this agent allowed to process information about the asset?”
As AI moves into infrastructure operations, that distinction deserves a place in the design of every digital twin and agent workflow.
Access is only the first decision
Let us take a fictional example: Transformer T17 in a utility network.
An agent is asked to investigate whether the asset needs an inspection. It has legitimate access to several sources:
- A BIM model showing the transformer and surrounding equipment.
- Thermal images from the latest inspection.
- Maintenance records describing previous faults.
- Protection-system configuration.
- A public basemap showing the wider network area.
A conventional access check might confirm that the agent can retrieve these records. But the records do not necessarily have the same sensitivity.
The public basemap may be suitable for processing by an approved cloud service. The thermal imagery may require a restricted environment. Protection settings may be subject to stricter operational or contractual controls.
The exact classification depends on the organization and its obligations. The point is that authorization to retrieve information should not automatically become authorization to send every part of it to any model.
This distinction matters even when an agent is only preparing a recommendation. The movement and processing of information can carry consequences before any physical action takes place.
NIST’s generative AI risk guidance identifies data privacy, information security and the use of third-party components as areas requiring governance. The infrastructure-specific question is how to apply those principles to asset data, imagery, spatial context and operational workflows. nvlpubs.nist.gov
Two forms of authority
In recent discussions on physical AI, I have focused on what an agent is allowed to do in the physical world.
Can it recommend an inspection? Draft a work order? Dispatch a team? Change an operating setting?
Those are questions of action authority.
But an infrastructure agent also needs information authority:
- What information may it use for this task?
- Which model or service may receive that information?
- Where may the processing occur?
- What restrictions apply to retention, onward sharing and reuse?
- What record must be kept?
These authorities should be connected but evaluated separately.
An agent might be permitted to analyze an image but only within an approved environment. It might be allowed to draft a work order but not issue it. It might be able to share a limited summary with another service while the original image remains inside the owner’s infrastructure.
A valid instruction to investigate T17 does not resolve all those decisions by itself.
A practical way to define the boundary
One approach is to introduce a Compute Trust Zone: a defined environment where certain data, agents and models are allowed to operate under specified conditions.
A zone might be a private cloud, an on-premises system, a sovereign cloud, an edge device or an isolated environment. Each comes with different controls and operational trade-offs.
For the T17 investigation, the owner could define rules such as:
Information - Illustrative classification - Example processing rule
Public basemap - Open - Approved external service may process it.
BIM geometry - Internal - Process only in approved enterprise environments.
Thermal imagery - Restricted operational - Process within an approved private or on-premises zone.
Protection configuration - Critical operational - Process only in a specifically authorized environment.
These are examples, not universal classifications. Each organization needs to determine its own rules based on risk, contracts and applicable law.
The zone should specify more than location. It should also identify the permitted models and agents, network access, retention conditions, administrative control and audit requirements.
A model hosted in a particular country does not, by that fact alone, resolve every governance question. The organization still needs to understand who operates the service, what data travels to connected services, which contractual terms apply and how processing is logged.
The policy must travel with the context
A digital twin brings together information from many systems: GIS, BIM, inspections, sensors, maintenance platforms and field applications.
That makes it valuable. It also makes the flow of information harder to see.
Imagine that T17’s thermal image is retrieved from one system, enriched with its BIM location from another, and combined with maintenance history before being sent to a model.
Each source may have its own restrictions. The combined package may also reveal more than any individual item.
The digital twin therefore needs a way to preserve context such as:
- Identity and classification: What is this information, and how sensitive is it?
- Purpose and permission: Why is it being used, and which processing environments are approved?
- Provenance and handling: Where did it come from, what transformations occurred, and what retention rules apply?
A label on a record helps, but a label alone does not enforce a boundary. The agent workflow needs a control point that checks the proposed data, destination, model and purpose before the transfer occurs.
If the proposed route is not authorized, the system should block it, choose an approved route where one exists, or ask an authorized person to review the request. It should not quietly send the same material to a fallback model simply because the preferred model is unavailable.
What happens when the preferred model is outside the boundary?
Suppose the agent’s default model is an external service, but T17’s imagery is approved only for a private environment.
The workflow has several possible responses:
- Route the task to an approved private model, if one is available and capable of performing it.
- Limit the information shared, if a reduced or transformed version is explicitly approved and still useful for the task.
- Pause for human review, if no suitable route is authorized.
- Collect different evidence, if another approved observation can answer the operational question.
Data minimization can help, but it is not a guarantee. Removing an asset name, for example, may not prevent a location or distinctive image from revealing the site. Any transformed data still needs to be assessed against the relevant policy.
The choice should also be visible to the operator. If the agent uses less information or a different model, that may affect the quality and limitations of its recommendation.
The audit trail must explain the decision
A useful audit record should answer more than “the agent ran.”
For the T17 task, it should show:
- Which agent requested the analysis and for what purpose.
- Which asset records and evidence were selected.
- Which policy and permissions were checked.
- Which model and processing environment were used.
- Whether information was withheld, transformed or blocked.
- Whether a person approved an exception.
- What output was produced and what limits were attached to it.
The audit trail itself needs appropriate protection. A log that copies sensitive prompts or asset details into an unrestricted system could recreate the very exposure the controls were intended to prevent.
This is where the Asset Graph, Evidence Graph and Authority Graph can work together. The asset relationship identifies what the information concerns. The evidence relationship records its origin and use. The authority relationship defines who or what may process it, for which purpose and under what conditions.
The names of these components matter less than the operational outcome: a decision can be traced to both its evidence and the authority under which that evidence was used.
Model choice will change. The boundaries must remain clear.
Infrastructure owners are unlikely to rely on one model or one computing environment for every task.
A field team may need an edge model when connectivity is limited. A utility may require private processing for operational imagery. A planning team may use an approved external service for less sensitive analysis.
That mix will evolve as models, contracts and infrastructure change.
The physical knowledge layer should therefore remain usable across approved models, while the organization’s rules continue to govern which information can move to each one. This is an architectural goal, not something a digital twin achieves automatically.
For owners and operators, the commercial value is clear: more flexibility in choosing AI tools, with clearer control over operational knowledge and a more defensible record of how recommendations were produced.
The next step in AI governance for infrastructure is to make information authority part of the workflow itself.
An agent may be trusted to investigate an asset. That trust should come with a clear, enforceable answer to where the investigation is allowed to happen.
