Utility API & AI Security: Exposing Data Without Exposing Control

by Kevin Hood

August 20, 2026

TL;DR

Utilities need operational and customer data in dashboards, portals, mobile apps, and AI tools. Every new integration is also a new potential path into systems that control physical infrastructure.
The requirements are consistent regardless of vendor: no inbound exposure of source systems, every request bound to a real identity, least privilege down to the field, credentials never in the client, rate limits, full audit logging, and enforcement that runs on infrastructure you control.
Joint guidance from CISA, NCSC-UK, and the FBI says this directly: don't let IT or external systems query OT directly. Broker access through a gateway and query a secure, strongly authenticated HTTP API instead.
Getting this wrong in a utility is not just a data-breach problem. In 2026, operators in at least seven U.S. states reported losing monitoring and control of internet-facing PLCs. And because customer and smart-meter data is personal data, a single over-permissioned integration can start both a sector-regulator and a GDPR reporting clock.
DreamFactory is a self-hosted data gateway that auto-generates governed REST APIs from your databases, with role-based access control, identity passthrough, rate limiting, and audit logging enforced on your own infrastructure.

Every utility is being pulled in two directions. Operations, engineering, and customer-facing teams all want data in modern applications: outage maps, field-service apps, asset-health dashboards, regulator reporting, and increasingly AI assistants that can answer questions about generation, load, or maintenance history. At the same time, the security team's job is to make sure none of that convenience becomes a path into systems that open spillway gates, trip breakers, or control pressure.

For an operator running hydroelectric dams, substations, or treatment plants, that tension is not abstract. The consequence of a compromised control system isn't a regulatory fine; it's water, power, or public safety. This post looks first at what any utility should require from a data-access layer, then at what the consequences look like when that layer is wrong, and finally at how a self-hosted API gateway like DreamFactory addresses those requirements.

What to require from an API layer when the data is operational

This section is deliberately vendor-neutral. If you are evaluating any approach to getting data into a front-end application — a purpose-built gateway, a hand-built API, a managed cloud service — these are the questions worth asking first.

1. Can the source system stay unreachable from the front end? The most important property is architectural, not a feature checkbox: the application should never hold a network path to the database or control system. The January 2026 joint guidance Secure Connectivity Principles for Operational Technology — led by NCSC-UK with CISA, the FBI, and partner agencies in Australia, Canada, Germany, the Netherlands, and New Zealand — makes the pattern explicit. It recommends removing inbound port exposure so OT is never directly reachable, brokering access through a gateway, and, where operational data must be shared, having IT systems query a DMZ-side historian through a secure HTTP-based API with strong authentication rather than reaching into OT directly.

2. Does every request carry a real identity? Shared service accounts are convenient and they destroy accountability. If ten applications and two AI agents all authenticate as svc_reporting, no log can tell you who actually read a record. Identity should travel with the request, and downstream audit trails should reflect the actual user.

3. How granular is authorization — and where is it enforced? Table-level permissions are rarely enough. You want per-endpoint, per-HTTP-method, and per-field control, plus the ability to constrain which rows a caller sees. Critically, enforcement must be server-side. The 2026 State of API Security report found that nearly 20% of analyzed cases relied on the client application to enforce security, which means the API was exposed the moment anyone called it directly.

4. Can personal data be limited and masked at the field level? Utilities hold a great deal of personal data — customer accounts, consumption and smart-meter readings, outage reports, employee and contractor records. Under GDPR, Article 5(1)(c) requires that data be limited to what is necessary for the stated purpose, and Article 25 expects data-protection by default, so that only the personal data needed for each purpose is processed at all. In practice that means an outage dashboard should receive a service address and status, not a name, national ID number, and billing history. The access layer should be able to mask, redact, or simply omit fields by role, without asking the application team to change code — otherwise minimisation depends on every consumer voluntarily ignoring data it can see.

5. Can the caller send arbitrary queries? An endpoint that accepts raw SQL, or builds queries by concatenating client input, hands the caller far more reach than intended. Injection remains one of the largest categories of real-world API vulnerabilities. Queries should be constructed by the layer itself from validated parameters, with row limits and timeouts, so a malformed or malicious request can't become a full table dump.

6. Are credentials ever exposed to the caller? Database credentials in a mobile app, a browser bundle, or an AI tool's config file are credentials in the wild. The layer should hold them and never hand them out.

7. Is there a rate limit and a query budget? Utilities have bursty, machine-driven traffic and legacy back-ends that don't tolerate table scans. Per-user, per-role, and per-endpoint limits protect the source system from both runaway automation and deliberate bulk extraction.

8. Is every call logged, and do the logs stay with you? For an incident review or a compliance audit, "who accessed what, when, from where" needs a real answer. Regulators on both sides of the Atlantic are converging on the same expectation. In North America, NERC CIP-015-1 — approved by FERC in Order No. 907, effective September 2025, with phased compliance starting in 2028 — requires internal network security monitoring inside electronic security perimeters, an explicit acknowledgment that perimeter logging alone won't detect an adversary already inside. In Europe, NIS2 places energy in Annex I, making energy companies essential entities subject to the strictest tier of supervision, with cybersecurity risk-management obligations, management-body accountability, and incident reporting on a 24-hour early-warning and 72-hour report cycle. GDPR adds its own 72-hour breach notification under Article 33 — and you cannot characterize which records were exposed, or reliably conclude that none were, without access records tied to identities.

9. Do you know how many APIs you have, and does the documentation stay true? Undocumented, forgotten endpoints are a recurring theme in breach analysis, and hand-written documentation drifts from reality the first time a schema changes. An inventoried, automatically documented set of endpoints that tracks the underlying schema is far easier to govern — and to hand to an auditor — than a decade of one-off integrations written by different contractors.

10. Can the whole thing run where you already control everything else? For a utility with an air-gapped or heavily segmented environment, a SaaS control plane is often a non-starter — not because cloud vendors are careless, but because the data path, the enforcement point, and the audit trail would all leave your custody. For European operators this doubles as a data-residency answer: if enforcement and logging never leave your own infrastructure, cross-border transfer questions largely don't arise.

What's at stake when the path isn't secure

The consequences can be physical. In July 2026, CISA urged operators to remove publicly exposed PLCs from the internet after actors changed device passwords and IP addresses, causing boil-water notices and manual operation; a joint FBI and EPA advisory counted utilities in at least seven states. No exploit chain was needed — only a reachable device and weak authentication.

The attack surface is credentials and access paths, not zero-days. Verizon's 2026 DBIR attributed 94% of utility breaches to system intrusion, basic web application attacks, and social engineering. The API layer shows the same pattern: Wallarm's 2026 API ThreatStats analysis attributed 52% of the API breaches it examined to broken authentication and 27% to unsafe consumption of APIs. These are governance failures — precisely the failures a well-designed access layer exists to prevent.

The blast radius compounds. An over-permissioned integration leaks more than its intended data. Configuration files, network diagrams, and asset inventories are what an adversary needs to understand a physical process well enough to disrupt it.

Personal data is in scope too. Customer accounts, smart-meter readings, and outage reports are personal data under GDPR — up to €20 million or 4% of turnover, with 72-hour notification. One bad integration can start two reporting clocks: the sector regulator and the data protection authority.

The applicable regime depends on where you operate. In the U.S., NERC CIP covers the bulk electric system (so hydroelectric generation and control assets are in scope; municipal water is not). In the EU, energy operators are essential entities under NIS2, and electricity operators face a second layer in the Network Code on Cybersecurity, which designates high-impact and critical-impact entities — and compliance with either can evidence the other. UK operators sit under NIS Regulations 2018, now being expanded by the Cyber Security and Resilience Bill.

Fines are the smaller problem in every one of those jurisdictions. The larger one is that a utility which cannot show who accessed what will struggle to prove an incident was contained.

How DreamFactory addresses these requirements

The following describes DreamFactory's documented capabilities, drawn from docs.dreamfactory.com and wiki.dreamfactory.com.

It runs entirely on your infrastructure. DreamFactory is self-hosted by design. Per the platform reference, it deploys on-premises, behind corporate firewalls, or in air-gapped environments where data cannot leave the network, via Linux, Windows/IIS, Docker, or Kubernetes with an official Helm chart. Enforcement and audit logging happen inside your perimeter — there is no vendor control plane in the data path. For AI work this is the deciding factor: a local LLM can query utility data without any of it crossing to an external model provider.

It replaces direct database access with a governed API. Point DreamFactory at a database and it introspects the schema and generates a documented REST API — endpoints for tables, views, and stored procedures, with an OpenAPI/Swagger spec generated automatically. Applications and AI tools call that API; they never receive a database connection. Legacy SOAP services can be exposed the same way, which matters for utilities running aging SIS, GIS, or ERP interfaces. A built-in MCP server means on-premises LLMs and AI assistants consume the same governed endpoints under the same policy.

Every API is closed by default. Per the platform overview, clients must present an API key before any endpoint is reachable, and that key is bound to an RBAC policy restricting which endpoints, HTTP methods, and data fields the caller can touch. Role configuration can scope a role to a single table and a single verb — a genuinely read-only API is a configuration choice, not a code review. Row-level control comes from server-side filters using placeholders like {user.id}, which the client cannot override or omit. An AI agent gets its own role and its own key, so its reach can be narrower than any human user's — and can be revoked without touching another consumer.

Personal data can be limited per role, not per application. Permissions extend to the field level natively: the wiki's platform reference describes administrators defining exactly which tables, fields, and operations each role can access, so the same customer table can present a service address and outage status to a dashboard role and a fuller record to a billing role. Where you need transformation rather than exclusion — partially masking an account number, redacting a field for one role but not another — event scripts in PHP, Python, or Node.js run on the response side and apply that logic centrally. The architecture reference notes that scripting is used for exactly this class of work, including field validations and access control. Either way, GDPR data minimisation gets enforced in one layer instead of trusting every downstream consumer — including LLMs, where a masked field never enters the model's context in the first place.

Callers don't get a query surface. Applications and agents call generated endpoints with validated parameters rather than submitting SQL — there is no connection over which to send a crafted query in the first place. The architecture reference describes the request path: access-control middleware checks authentication via API key or session token, then authorization against the caller's role, then usage limits, and a failure at any point ends the call before it reaches a service. Only then does the platform compose the query itself through its database drivers. Filtering, sorting, and pagination happen through a documented query syntax, which is what allows row limits to be enforced rather than requested politely. Injection defense here is a property of the layering, not a feature bolted on top. It applies equally to an agent composing its own queries, which is the newer version of the same risk.

Identity travels with the request. DreamFactory authenticates callers against your existing identity infrastructure — SAML 2.0, LDAP, Active Directory, OAuth, OpenID Connect, Okta, and Entra ID — and supports identity passthrough, so the authenticated user's identity is forwarded to the downstream data source and database-level audit logs reflect the real user rather than a generic service account. Database credentials stay with the gateway — and never appear in an AI tool's configuration file.

Traffic is limited and logged. Rate limits can be set per instance, per user, per role, and per endpoint. Audit logging captures calls with user identity and timestamp, with Logstash/ELK integration — and because the platform is self-hosted, those records stay in your custody rather than a vendor's. Limits matter more with AI in the mix, since agent traffic is bursty and parallel in ways human-driven traffic isn't, and every model call lands in the same audit trail as everything else.

Custom logic doesn't require a new service. Event scripts in PHP, Python, or Node.js run pre- and post-request, so validation, field masking rules, or approval workflows can live at the gateway instead of in a new application nobody wants to maintain.

Utility and energy use cases this enables

With a governed gateway in place, integrations that would otherwise be hard to approve become routine:

Operational dashboards and outage maps reading from a DMZ-side historian or replica through a read-only, field-limited API, with no inbound path to the control network.

Field-service and mobile apps where each technician's requests are scoped by role and filtered to their own work orders and assets.

Asset-health and reliability analytics over maintenance, SCADA-historian, and warehouse data, with sensitive fields masked or excluded by role.

Natural-language querying for staff — enrollment-style questions applied to load, outage, or work-management data, scoped to what each role may see, with every AI query logged against a real user.

Regulator and partner data sharing through per-consumer roles, rate limits, and audit logs rather than one-off extracts and SFTP drops.

Legacy modernization — exposing aging Oracle, DB2, mainframe-adjacent, or SOAP systems as clean REST endpoints without replatforming them.

Why this also accelerates delivery

Security is the reason a utility adopts a gateway; speed is why the pattern sticks. The slowest part of most utility data projects is not the front end, it's the secure plumbing behind it: someone has to write the API, wire up authentication, implement authorization, add logging, and document it — then do it again for the next system.

Auto-generated APIs with live OpenAPI documentation collapse that work from weeks to a configuration session, and the API stays in sync with the schema. More importantly, governance becomes reusable infrastructure rather than a per-project tax. Once the gateway, identity integration, and role policies exist, every subsequent project inherits them. That is what lets a security-conscious operator say yes to a pilot: the guardrails are already in place, and the answer to "what can this thing reach?" is a role definition rather than an investigation.

Facts about DreamFactory

Secure, self-hosted data gateway that auto-generates governed REST APIs from a database schema, with no backend code.
Deploys on-premises, behind firewalls, or fully air-gapped via Linux, Windows/IIS, Docker, or Kubernetes (official Helm chart).
Connects to 20+ database types including SQL Server, Oracle, PostgreSQL, MySQL, MongoDB, Snowflake, IBM Db2, and SAP HANA, plus file storage, email, cache, and legacy SOAP services.
APIs are private by default: an API key is required, and each key is bound to an RBAC policy governing endpoints, HTTP methods, and fields.
Row- and record-level access control through server-side filters, including {user.id} placeholders the client cannot override.
Field-level permissions applied by role, with masking and redaction logic implemented through server-side event scripts; controls designed against the OWASP Top 10 and privacy regimes including GDPR.
Identity passthrough with SAML 2.0, LDAP, Active Directory, OAuth, OpenID Connect, Okta, and Entra ID; database credentials never leave the gateway.
Rate limiting per instance, user, role, and endpoint; audit logging with Logstash/ELK integration in the Enterprise edition.
Built-in MCP server so AI assistants and on-premises LLMs use the same governed endpoints as applications.
Available as open-source Community Edition (Apache 2.0) and a commercial Enterprise edition that adds SSO, identity passthrough, field-level RBAC, commercial connectors, and ELK audit logging.

Frequently asked questions

Does a gateway like this touch our OT network? It doesn't have to, and generally shouldn't. The recommended pattern in the joint OT guidance is to replicate operational data outward into a DMZ and have IT-side consumers query that copy through an authenticated HTTP API. DreamFactory sits on the IT or DMZ side of that boundary and exposes the replica, not the control system.

Can we run this with no internet connectivity at all? Yes. DreamFactory is self-hosted and documented as supporting air-gapped deployment behind corporate firewalls, with no requirement for the platform to call out.

Does it make us compliant with NERC CIP, NIS2, or the Network Code on Cybersecurity? No product does. DreamFactory provides controls that map to what all three expect of a data-access path — on-premises deployment, least-privilege role-based access, identity-level audit logging, encrypted credentials, and rate limiting — but scope determination, evidence, and operation remain your responsibility. Because NIS2 and the NCSC's Cyber Assessment Framework are outcome-based rather than prescriptive, a governed API layer is generally easier to evidence against them than a set of hand-built integrations. Treat it as a control you can point at during an audit, not a compliance checkbox.

How do we stop an AI agent from doing something destructive? Give the agent its own role. Because RBAC is per-endpoint and per-HTTP-verb, an agent can be restricted to GET on named tables and specific fields, with its own rate limit, while human users on the same data get different policies. Every call is logged against the agent's identity.

How does this help with GDPR specifically? Two ways. Field-level permissions let you enforce data minimisation once, at the access layer, so a dashboard or AI agent only ever receives the personal data its purpose requires — and where a field needs masking rather than removal, a server-side script applies that rule centrally instead of in every consuming application. And because every call is logged against a real identity, you can answer what a data protection authority actually asks after an incident: which records were reached, by whom, and when. The platform is a processing control, not a compliance programme — lawful basis, retention, and data subject rights remain yours.

How long does it take to expose a database as an API? Minutes for the initial generation — connect the database, and endpoints plus OpenAPI documentation are produced automatically. The real work is deciding the role model, which is work you'd do for any approach.

Healthcare

Financial Services

Government

Manufacturing