Agentic FabriqSeparate access to IT, operational technology, and customer environments.
The IT/OT boundary is enforced per action, so an analytics agent never inherits a path into control systems.
SOLUTIONS / Energy & Utilities
Apply strict boundaries to agents interacting with critical infrastructure
Control agents working across field operations, assets, grid systems, customers, and regulated infrastructure.
01 / IDENTITY02 / POLICY03 / AUDIT
01 / THE CONTEXTRead the grid freely.
Read the grid freely.
Switch it only with authority.
Energy and utility agents can assist with outage management, maintenance, forecasting, field service, customer support, and compliance. These systems span corporate IT, operational technology, regulated customer data, and safety-critical assets.
02 / IN PRACTICE
Autonomy, with accountability.
SWITCHING ORDER SO-2214 · FEEDER F-207Illustrative · field-agent, acting for a control-room operator
- Asset
- Feeder F-207 · northern region
SnowflakeInside the region this operator holds. Read, and read only, to build the order. - Present state
- Closed — taken from telemetry, not from memoryEvery value on this order names the system it came from.
- Crew
- Restoration crew briefed on the plan
Microsoft TeamsNotifying people is work the agent may finish on its own. - Steps 1–4
- Isolate · earth · test dead · permit to workDrafted in full, in the order the procedure requires.
- Adjacent substation SS-118
- Not read, not includedAnother region’s control system. Outside this operator’s authority, so the agent cannot see its state, let alone put it on an order.
not authorised
The order is complete. Execution is a separate act, and it is not the agent’s to make.
PREPARED BYfield-agentno authority to operate
AUTHORISED BYan authorised operator, before a single switch moves
Example order. The regions, authorities and procedures are the ones you set.
03 / WHAT CHANGES
Control, in the details.
Restrict agents by asset, facility, region, crew, and operating role.
Operational geography becomes access geography — a crew’s agent works its territory and assets alone.
Keep control changes, dispatches, shutdowns and safety-sensitive actions out of every grant.
Actions that touch the grid, the field or safety are not in the tool list an agent receives, so an authorized operator takes them.
Limit contractor and vendor agents to specific assets and engagement periods.
Third-party access is limited to specific assets and time-limited, ending with the engagement rather than lingering.
Narrow an agent’s grant the moment conditions change.
Grants are editable and the next call resolves against the new set, so an agent’s reach can be cut back in one place exactly when the system is most fragile.
Keep a complete record for operational, safety, and regulatory review.
Every operational action carries whose authority it ran on and the verdict — evidence for reliability, safety, and commission reviews alike.
THREE LAYERS. ONE DECISION.
The boundary travels with the work.
Explore the context attached to every request.
What is this agent allowed to do?
field-agent has a defined purpose and a bounded set of tools.
Whose authority travels with it?
The request acts for authorized operator, using that person’s permissions.
Where does the action land?
The policy applies to the requested action within Asset systems, before the tool executes.
04 / WAYS TO PUT IT TO WORK
Built for your real workflows.
01Outage response
Response agents assemble outage context and draft restoration steps; switching and dispatch stay with operators.
Identify→Authorize→Record
02Field-service coordination
Coordination agents work their region’s orders and crews; assigning safety-sensitive work is not an action they hold, so dispatch does it.
Identify→Authorize→Record
03Asset maintenance
Maintenance agents read asset histories and schedule work within their facility scope; intervening on an asset is not in their grant.
Identify→Authorize→Record
04Demand forecasting
Forecasting agents consume telemetry read-only, with no route from analytics into control settings.
Identify→Authorize→Record
05Customer service
Service agents answer from the authenticated customer’s account, separated from operational systems entirely.
Identify→Authorize→Record
06Regulatory reporting
Reporting agents compile filings from unalterable operational data; a named officer submits, because the agent sends as that officer and nothing wider.
Identify→Authorize→Record
QUESTIONS
A closer look.
Can we add this without modifying grid systems?+
Yes. Fabriq drops in in front of IT, OT, and customer environments — the systems themselves are unchanged. Every agent action against them is checked per request, and control changes and dispatches can be left out of every grant so no agent can reach them.
What happens during an emergency?+
Reach narrows rather than widens. A grant can be cut back in one place and the next call resolves against the smaller set, so faster automated response never comes at the cost of an agent holding authority it should not.
Where do system credentials live?+
In the vault, injected server-side per call — nothing pasted into scripts or control-room machines, with immediate cutoff on disconnect.
Can authority differ per operator, crew, and region?+
Yes. Reach resolves from the acting person and their operational role, so a crew’s agent works its own territory and assets, a contractor’s agent sees only its engagement, and an operator’s authority is exactly their own.
What evidence exists for regulators?+
A single trail with both identities and the verdict on every action — filterable by system, person, and time window, and exportable for review.
Can we keep higher-risk changes in human hands?+
Yes — grant the reads and the reporting and leave the rest out, per operator and per action. What an agent was not granted never reaches its tool list, and every verdict is logged.