Security

Keeping simulator files, engineering assumptions, and plant context secure is central to Reflux. This page outlines how we approach security for reviewed AI workflows across Aspen Plus, HYSYS, Aveva Pro II, and GWB.

Please submit potential vulnerabilities or security questions to support@reflux.sh. Start enterprise security reviews through the contact sales form.

# Security posture

Reflux is designed around reviewed automation rather than silent simulator control. The agent drafts a typed plan first, validates the target simulator family and case paths, and requires an explicit review gate before applying any native simulator changes.

When Reflux edits an existing case, the product is intended to preserve the original source file and write reviewed output artifacts separately. Native files, run summaries, and plain-language evidence travel together so engineers can audit what changed.

# Third-party assessments

Reflux is an early product and does not currently claim a SOC 2 attestation. For enterprise pilots, we can provide architecture notes, adapter boundaries, test coverage summaries, and review workflow details on request.

Formal external penetration testing and compliance reports are part of the security roadmap as Reflux moves from early access into broader enterprise deployment.

# Deployment and infrastructure

Reflux supports local-first simulator workflows because many process simulation tools run on licensed desktop or workstation environments. An Aspen Plus adapter, for example, can connect to a licensed desktop installation instead of uploading a native simulator file by default.

Simulator access is scoped by adapter. Aspen Plus, HYSYS, Aveva Pro II, and GWB integrations are isolated so a workflow can expose only the simulator actions it needs. Reflux favors explicit configuration, narrow tool methods, and path validation over broad shell access.

# Client and agent security

Agent requests are converted into structured plans before execution. Apply calls must include review confirmation and a matching plan fingerprint, which reduces the risk of an agent applying a stale or unintended simulator mutation.

Reflux separates explanatory text from native simulator work. Results are reported with the touched blocks, streams, components, convergence status, output paths, and warnings where available, so reviewers can distinguish a model suggestion from an executed run.

Current secure-use practices include:

• Run generated workflows against a copied or template-backed case first.
• Keep execution flags disabled until the reviewer confirms the plan.
• Limit each simulator integration to the adapter methods required for the workflow.
• Store native case files and run artifacts in customer-controlled locations.

# Data handling

Reflux is built for proprietary engineering data. The product direction is to let teams keep simulator files, plant assumptions, DCS context, and generated outputs in their own environment unless they explicitly choose to share them for support or an enterprise pilot.

Model-provider, retention, and training terms should be agreed with each customer before production use. Reflux can scope deployments so sensitive simulator artifacts remain local and only reviewed summaries or approved metadata leave the workstation.

# Enterprise administration

Enterprise deployments should define the permitted simulators, case roots, execution permissions, review requirements, and artifact-retention locations before enabling production runs.

The roadmap includes clearer policy controls for teams: approved adapter lists, audit-friendly run histories, and deployment patterns for local workstations, controlled lab machines, and internal agent clients.

# Vulnerability disclosures

If you believe you have found a vulnerability in Reflux, please send a report to support@reflux.sh with a description, affected surface, reproduction steps, and any relevant logs or screenshots. We will acknowledge reports as quickly as possible and prioritize fixes by severity and potential customer impact.