The destination is not yours. The risk still is.
In July and August 2026, water and wastewater utilities across at least a dozen US states reported cyber incidents. US intelligence agencies assessed Iran as the likely source of the Minnesota wave – more than 30 community systems in that state alone – and a leaked industry memo tied the activity to the same campaign CISA had already been warning about. Formal public attribution has not been issued.
Federal agencies broadened the OT alert as more operators reported a loss of monitoring and control, boil-water notices, and a drop back to manual operations. The tactics rhyme with earlier campaigns against internet-exposed programmable logic controllers that still used default passwords.
That is an operational-technology story, and it should be treated as one. Disconnecting exposed PLCs from the internet, replacing default credentials, and limiting remote access to trusted devices are the controls CISA is asking for. A proxy in front of a SaaS API does not harden a pump controller.
The reason the campaign belongs in this series is the sentence boards and ministers actually have to live with: systems you depend on, run by vendors you do not control, are still your incident. Water utilities, energy operators, transport agencies, and health services already sit on a stack of third-party APIs around the OT – vendor cloud telemetry, billing, citizen portals, maintenance platforms, identity providers, GIS, the contractor’s ticketing system. Those integrations often fall outside the security perimeter the organisation knows how to draw, and they are the integrations that quietly accumulate standing credentials, unreviewed scopes, and no durable record of who called what.
When a campaign like this is in the news, the question that lands on a government operator is not “are we running the same PLC firmware?” It is “can we show what our organisation has been sending to systems we do not own?”
Ownership of the API is the wrong boundary
Inbound API gateways protect the APIs you publish. Identity programmes protect the people and service accounts you issue. Neither automatically covers a call your environment makes to a vendor’s host. The vendor’s permission model is whatever they shipped. Their logging is whatever they will give you after an incident, on their timeline, in their format. Their patch cycle is not yours.
That is an uncomfortable fact for critical infrastructure, because so much of the modern plant is a vendor relationship. The SCADA historian has an HTTPS API. The maintenance contractor’s platform is a SaaS tenant. The public health dashboard pulls from a third-party data service. An AI agent booked to summarise outage tickets will happily call all three with whatever credential it was given. None of those destinations will install your policy.
Governance that only applies to systems you wrote is governance of a shrinking fraction of the estate. The durable version does not care who owns the destination. It cares who owns the call.
Governance and audit, without the vendor’s cooperation
Three artefacts make an outbound integration governable. They are the same artefacts this series has been building, restated in the language a risk committee already uses.
An inventory that is the traffic, not a spreadsheet. Every third-party API you call is a target with a name, a base URL, and a region. Every caller is a proxy bound to that target. GET /clients/{clientId}/proxies is the catalogue. Integrations that are not on it are not sanctioned, and once the vendor credential lives only on the gateway, unsanctioned callers fail in the open instead of succeeding in the dark.
A grant you can show a reviewer. Deny by default. Allow the methods and paths the function requires. A telemetry puller that needs to read tank levels does not need to write setpoints, even if the vendor’s API key would allow both:
{
"effect": "allow",
"ruleActive": true,
"methods": ["GET"],
"path": {
"path": { "pattern": "^/v1/sites/[^/]+/(levels|alarms)$" },
"presence": "must_exist"
},
"notes": "Vendor telemetry: read levels and alarms only. No writes."
}That JSON is the access policy. It is reviewable, diffable, and still true at 3am when nobody is watching the agent. A meter on the same proxy is the expected operational envelope – the difference between a scheduled poll and a weekend of unexplained writes.
A record that does not depend on the vendor returning your call. Every outbound request through the proxy is logged with method, path, time, whether policy allowed it, and whether it was forwarded. The query is the same one in AI agent audit logs:
GET /clients/{clientId}/proxies/{proxyId}/requests
?processedAfter=2026-07-26T00:00:00Z
&processedBefore=2026-07-28T00:00:00ZWhen a minister, an auditor, or an incident coordinator asks what left the organisation toward a named vendor last weekend, the answer is that result set – not a request to the vendor’s support desk, not a reconstruction from a contractor’s laptop. For retention measured in years rather than weeks, archive those records into storage you control.
What this does not claim
It does not replace OT security, air gaps, or CISA’s advice on exposed controllers. It does not make a vendor API “accredited” by sitting in front of it. It does not satisfy a whole ISM or Essential Eight programme on its own. Those programmes still have to be done on the systems they name.
It does claim something more specific, which is what buyers who think in governance terms actually need: you can enforce least privilege and keep an audit trail on calls to APIs you will never patch, without waiting for the vendor, and without changing the calling application. For an agency that is already being asked to account for AI assistants, contractor integrations, and standing vendor credentials, that is the part of the estate that currently has the weakest evidence.
Next steps
List the vendor and third-party APIs that operational, corporate, and AI systems already call. For each, ask whether you can produce the grant and last week’s call record without asking the vendor. The ones where the answer is no are the protect surface – the same selective logic as Zero Trust at the seam you can actually control, applied where a public incident would land on you even though the host is not yours.
This is post 6 of APIs You Don’t Own. The rest of the series: least privilege, blast radius, Zero Trust at the seam, token rotation, audit logs. RequestRocket is runtime access control for AI agents and apps calling APIs you don’t own – every call gets a least-privilege credential, a policy check, and an audit record, with no code changes. Read the documentation, or start for free.