Book Your 20-Minute Assessment
Security and control

Autonomous action inside your boundaries.

AIMMS acts only through the identities, roles, data, models, tools, approval rules, spend limits, safety policies, and write permissions the customer defines.

The control loop

  1. Ground
  2. Verify
  3. Approve if required
  4. Act
  5. Record
Book Your 20-Minute Assessment
high-voltage substation with protection cabinets, disconnects, and restricted service access
A substation environment. AIMMS reads permitted context and issues no control command.
Authority, made concrete

Who can do what, and what gets recorded.

Autonomy in AIMMS is a permissions model, not a promise. This is how authority typically maps across common actions. Pilot workflows update the internal AIMMS record only. External business-system writeback is customer-specific and activates only after approved mapping, permissions, integration, and validation.

Action AIMMS authority Human owner Recorded evidence
Read a SCADA event or historian trend Read-only Operations Source and timestamp
Recommend the next check Allowed Technician decides Cited evidence and procedure
Draft a work order or supplier RFQ Allowed Reviewer where required Draft content and sources
Reserve a stocked part Configurable Maintenance lead Transaction receipt
Send approved supplier outreach Configurable Named approver Message, rule, and approval
Approve spend Human required Named approver Approval record and threshold
Update the internal AIMMS pilot work record Configurable Workflow owner AIMMS record and action receipt
Write to an external CMMS, EAM, or ERP After pilot Customer policy and integration owner Target-system receipt after activation
Write to PLC, DCS, or SCADA or execute a setpoint, restart, interlock, or actuator command Prohibited Qualified customer personnel Outside AIMMS authority
Identity, data, and model controls

Enterprise identity in. Customer controls throughout.

Nothing here is aspirational. These are the controls implemented in the product today, named individually so a security reviewer can check them one at a time.

Access follows enterprise identity and role.

  • Customer single sign-on, your identity provider authoritative
  • Direct FIDO2 and WebAuthn enrollment for accounts you do not federate
  • Phishing-resistant hardware security keys available to every user
  • Recovery by registered second credential, with a named break-glass path
  • Role-based access control by action
  • Authentication, access change, and deprovisioning events recorded

Data and model controls, stated plainly.

  • Encryption in transit
  • Encryption at rest
  • Data-retention controls
  • Model-provider controls
  • Customer-managed keys
  • Post-quantum cryptography controls

Everything on this page is a product control we implement and can walk through during your security review. It does not represent a third-party certification, audit, or independent attestation, and we will not describe it as one.

Operational technology boundary

Use operational context without giving AI control authority.

Read-only inputs

  • Permitted SCADA events
  • Historian context
  • Alarms
  • Inspections
  • Asset records

Permanent no-write boundary

  • PLC, DCS, or SCADA writes
  • Setpoint or restart commands
  • Interlock commands or bypasses
  • Actuator commands
  • Relay, protection, or switching commands
power generation and storage plant with turbine hall equipment, pumps, and control cabinets
A generation and storage plant. SCADA events and historian trends reach AIMMS as read-only context; the plant keeps every control action.

Qualified customer personnel and existing procedures retain operational, safety, engineering, and return-to-service authority.

For a first deployment, AIMMS builds its Data Twin from a customer-controlled data mirror and permitted read-only context. Source systems remain authoritative.

Safe exception handling

When a dependency fails, AIMMS stops safely and leaves the work legible.

A missing fact, failed connection, denied permission, or rejected approval never becomes an invisible workaround. AIMMS contains the issue, preserves the record, and returns the decision to the authorized owner.

One deterministic safe-stop sequence

  1. Stop

    Hold only the affected action and its dependent steps.

  2. Expose

    Name the blocker, source, owner, and current state.

  3. Preserve

    Keep the evidence, prior verified state, and action receipts.

  4. Route

    Send the exception to the person authorized to resolve it.

  5. Revalidate

    Resume from a verified checkpoint only after the blocker is cleared.

Five conditions that stay visible

Normal work continues where it is independent of the blocker.

  1. Condition

    Stale or missing data

    Safe response

    Hold the dependent recommendation or action. Show the source, timestamp, and missing fact instead of filling the gap.

    Resume gate

    Revalidate the required facts. The last verified state remains unchanged until new evidence is accepted.

  2. Condition

    Integration unavailable

    Safe response

    Do not represent the transaction as complete. Record the failed attempt and route it to the integration owner.

    Resume gate

    Reconnect, recheck permission and payload, then continue from the last verified checkpoint.

  3. Condition

    Permission denied

    Safe response

    Stop before the action. Record the denied scope and route it to the identity or workflow owner. Never switch identities or bypass policy.

    Resume gate

    Retry only with a valid authorized identity and after confirming that the underlying facts have not changed.

  4. Condition

    Approval held or denied

    Safe response

    Keep the action unexecuted. Preserve the decision and any reason supplied. A denial is never treated as a delay.

    Resume gate

    A modified action returns for a new review. The original approval cannot be stretched to cover changed facts.

  5. Condition

    Partial execution

    Safe response

    Stop dependent downstream steps. Preserve receipts for completed steps and identify the first unconfirmed step.

    Resume gate

    An authorized owner chooses reconciliation, retry, or target-supported rollback. AIMMS does not erase completed real-world events.

Permanent OT boundary

AIMMS never writes to PLC, DCS, or SCADA and never executes setpoints, restarts, interlocks, or actuator commands. Qualified customer personnel retain operating, safety, engineering, and return-to-service authority.

First-deployment boundary

Pilot workflows update the internal AIMMS work record only. External CMMS, EAM, ERP, inventory, and procurement writeback is customer-specific and requires approved mapping, permissions, integration, and validation before activation.

No silent substitution  /  No permission bypass  /  No unverified completion

Approvals and evidence

Approvals you configure. Evidence you can inspect.

You decide where people approve and where policy is enough.

Approval requirements can be configured by action type, asset criticality, role, spend, supplier, safety condition, data confidence, and write target. Available decisions: approve, modify, hold, reject, escalate.

Drift protection: AIMMS revalidates material facts before a previously approved action is completed. Approval permits the reviewed action. It does not authorize changed facts.

Every permitted action is explainable, attributable, and reviewable.

  • Action logs and action receipts
  • Backup and disaster recovery
  • Vulnerability scanning
  • Incident-response process

Each receipt records

  • Source facts
  • Actor
  • Governing rule
  • Approval
  • Time
  • Attempt
  • Result
  • Evidence
Deployment and integration

Only available modes. Only validated connections.

Deployment options

Implemented single-tenant cloud · Implemented hybrid

First-deployment data path

Customer-controlled Data Twin / data mirror · Permitted read-only operating context

Implemented connector coverage

Outlook · Gmail · SCADA events · Historians · CMMS · EAM · ERP · Inventory · Procurement · GIS · Vendor portals

Customer activation

Mappings · Identity · Permissions · Network access · Customer approval · Validation before external writeback

critical-facility cooling plant with chilled-water pumps, headers, and electrical cabinets
A critical facility. Every customer connection is mapped, permissioned, and validated in that environment before it carries work.

Product connector capability and a customer's activated connection are distinct. Every customer connection is configured and validated in that environment. Pilot workflows use internal AIMMS writebacks only.

Put your security and control requirements on the table.

Bring your IT, OT, and security stakeholders. We will walk the identity model, data handling, OT boundary, approval configuration, and deployment options against your requirements.

Book Your 20-Minute Assessment