An AI that cannot write to your field equipment — by architecture, not by policy.

The problem with policy

Every commercial "AI for SCADA" product on the market today shares a common safety premise: the AI could write commands back to field equipment if it wanted to, but is restrained by access policy — IAM rules, RBAC, network ACLs, application-level guards. The premise of safety is that a person doesn't change the policy and an attacker can't bypass it.

That premise has a name in the security literature: policy-in-the-loop. It is the same trust model that has produced every major OT cybersecurity incident of the last decade. From Stuxnet to the 2021 Oldsmar water plant intrusion, policy boundaries were either misconfigured, bypassed, or simply not present where assumed. The defining characteristic of policy-in-the-loop is that the dangerous capability still exists in the system — it is merely gated.

The IL-9000 boundary

Aevus runs inside a dedicated AWS Organization unit. That OU is governed by a Service Control Policy (SCP) that denies the IAM actions required to publish writes to any account, network, or endpoint outside the Aevus boundary. The SCP is enforced by AWS IAM at the API gateway level — before any Aevus code executes — and cannot be modified by any principal Aevus operates under, including the Aevus application itself, the Aevus AI inference pipelines, an attacker who has compromised Aevus credentials, or an Aevus developer with full administrative access to the Aevus account.

Modifying the SCP requires the AWS Organization root account, which Aevus does not hold. The root account is operated by Intrepid Logic under separate, MFA-protected credentials, with no programmatic access keys, no API access, and no application-level reachability from the Aevus boundary.

What the boundary allows

• Telemetry ingestion (inbound): field equipment publishes telemetry to a dedicated MQTT / Kinesis ingress that lives at the Aevus boundary. Direction is field → Aevus only.
• Operator dashboard rendering (outbound, read-only): Aevus serves dashboards, alerts, and recommendations to the customer's operator interface. Direction is Aevus → operator only.
• AI inference (internal): all Aevus AI (predictive failure, anomaly detection, root-cause analysis) executes inside the boundary. It has access to telemetry and historian data. It has no path to the customer's field network.

What the boundary denies

• Any write, command, or setpoint change to the customer's field equipment, PLCs, RTUs, or control network.
• Any modification of the SCP that enforces the above.
• Any creation of new IAM principals, roles, or policies that could circumvent the above.

Why this is structurally different from policy-in-the-loop

The key property is locus of control. In every approach above except IL-9000, the safety boundary is enforced by a control that the Aevus organization can (in principle) modify. In IL-9000, the boundary is enforced by a control that Aevus, structurally, cannot reach.

Verifiability

The SCP is a few hundred lines of declarative JSON. It is reviewable by any security engineer with an hour and an AWS background. There is no proprietary or opaque mechanism. Aevus will share the SCP under NDA with any qualified evaluator during a pilot engagement.

Every API call made by Aevus principals is logged to AWS CloudTrail, retained per customer policy, and queryable. A denied write attempt — whether benign (a regression test) or adversarial (a compromise probe) — appears in the audit log as a deny event within seconds.

Compatibility with operator workflow

IL-9000 does not eliminate the possibility of any AI-recommended action being applied to field equipment. It eliminates the possibility of the AI itselfapplying it. When an Aevus recommendation requires action — e.g., a setpoint change, an isolation, a maintenance dispatch — the recommendation routes to the operator's existing control interface (HMI, work-order system, dispatcher console) for human approval and execution. The human-in-the-loop is preserved exactly where it should be: at the point of action, not at the point of analysis.

Standards alignment

IP status

IL-9000 is a USPTO provisional patent filing. The provisional covers the architectural pattern of enforcing AI write-prevention at the cloud-account organizational boundary, independent of application-layer policy. Conversion to non-provisional is planned within the 12-month statutory window. Aevus does not consider the pattern itself secret — the value is in the implementation, the operator integration, and the evidentiary audit trail.

What this brief is not

This is a technical positioning brief, not a security audit. It does not describe specific IAM policies, telemetry schemas, AI model architectures, or operator integration patterns. Those are shared under NDA during a pilot evaluation. This brief exists to answer the most common evaluator question — "How can the AI not also be the attack vector?" — at a sufficient level of architectural detail to justify a deeper conversation.

Engagement

Aevus is in active pilot conversations with midstream energy operators, municipal water utilities, and federal infrastructure programs. To begin a pilot evaluation, including review of the production SCP under NDA: