CRITICAL INFRASTRUCTURE

OPERATIONAL
Authority for AI, automation and critical systems

Arximus applies explicit runtime authority to consequential machine-driven operations. Trusted actor identity, delegated operational authority, exact asset scope, the exact proposed operation, current operational state and authoritative external facts determine whether the operation may proceed to customer-controlled execution.

Explore Enterprise Explore security

OT ASSETS OPERATION AUTHORITY SAFETY STATE MAINTENANCE AUTHORITATIVE STATE LOCK EVIDENCE

OPERATIONAL AUTHORITY MODEL

Technical capability does not create operational authority.

A machine actor may have network access, credentials or technical capability to affect infrastructure without being authorized to perform this operation on this asset under the current operating conditions. Arximus turns that distinction into explicit runtime authority.

01 ACTOR Establish trusted actor identity

Resolve the service, application, automation, operator or AI agent through trusted identity and delegation rather than self-asserted claims.

→

02 SCOPE Resolve delegated operational authority

Determine which sites, systems, assets, zones and operation classes the actor is actually authorized to affect.

→

03 OPERATION Evaluate the exact proposed operation

Normalize the target asset, destination, action and protected parameters into a typed operation rather than treating a generic command as authority.

→

04 AUTHORITATIVE STATE Verify current operational conditions

Bring required maintenance, change, safety, process and other authoritative operational facts into authorization.

→

05 DECISION Authorize, hold or refuse

Deterministic policy decides whether the exact operation remains inside delegated authority before it can proceed to protected execution.

CONSEQUENTIAL OT & INFRASTRUCTURE ACTIONS

Consequential operational changes require explicit authority.

Customer-defined operation classes place authority around the actions that can change infrastructure, production or physical state. Each class can carry exact asset scope, protected parameters, operating conditions, approval requirements and its own execution boundary.

CONFIG

Configuration changes

Bind protected configuration changes to the exact asset, parameters, change authority and current operational conditions that authorized them.

asset.configure

MAINTENANCE

Maintenance operations

Constrain automated maintenance by exact asset, site, maintenance window, work order, delegated authority and current state.

maintenance.perform

PROCESS

Operational parameter changes

Bind authorization to the exact resource and protected values for machine-driven changes that affect operational behavior.

process.modify

ACCESS

Remote operational access

Require explicit authority before AI or automation reaches protected operational services, gateways, engineering systems or remote interfaces.

ot.access

ISOLATE

Asset isolation

Constrain machine-driven isolation and containment actions by asset scope, current operational state and customer-defined emergency authority.

asset.isolate

CHANGE

Production change release

Require exact destination, approved change authority, protected values and current change window before the operation reaches customer-controlled execution.

change.release

AUTHORITATIVE OPERATIONAL STATE

Current operational state becomes part of authorization.

Static access does not establish whether an operation remains authorized under current maintenance, change, process or safety conditions. When customer policy requires operational state, approved external systems establish the facts and deterministic Arximus policy decides what those facts mean for the exact operation.

ASSET

Asset identity & classification

Resolve the exact asset, site, operational class and customer-defined criticality associated with the proposed operation.

CHANGE

Change-management state

Require the approved change record, maintenance ticket or other authoritative workflow state that applies to the exact operation.

WINDOW

Maintenance window

Confirm that the current time and operational mode remain inside the window authorized for the requested operation.

SAFETY

Safety or interlock state

Require current customer-authoritative safety state when policy makes that state a condition of operational authority.

OPERATOR

Operator or service authority

Verify that the current human, service or automation authority applies to the exact asset and operation class.

PROCESS

Current operating state

Bring required process, facility or system state into authorization when current conditions determine whether the operation may proceed.

OPERATIONAL HOLD & RE-AUTHORIZATION

A valid change can become invalid when operating conditions change.

An operation does not inherit authority from an earlier operational state. When a required authoritative condition is not satisfied, the operation remains on HOLD. When that condition changes, Arximus re-authorizes the complete operation against current policy, authority and state.

01 / REQUEST Maintenance automation proposes a protected change

The service is trusted, the target asset is known and the operation belongs to a class delegated under its maintenance authority.

02 / CHANGE AUTHORITY Approved work order exists

The authoritative change-management source confirms an approved work order that applies to the exact target asset and operation.

03 / AUTHORITATIVE STATE Required maintenance condition is not active

The current operational source reports that the asset has not entered the state required by customer policy for this change.

ARXIMUS DECISION HOLD

The operation is not released. When the required condition becomes valid, Arximus re-evaluates the exact operation against current authority, policy and operational state before deciding again.

AUTHORITY ACROSS OT & IT

Operational authority remains explicit across IT and OT boundaries.

Critical infrastructure spans business IT, cloud services, engineering environments, operational networks and physical systems. Arximus applies one actor-neutral authority model across those boundaries without treating technical access, network reach or machine credentials as authorization for the exact operational action.

IDENTITY

Authority begins with trusted identity

Machine, service, application and operator identity must come from trusted mechanisms rather than claims made by the requesting actor.

Service identity
Application identity
Delegation chain

SCOPE

Authority remains inside defined asset scope

Constrain delegated authority to specific sites, environments, asset classes, destinations and protected resources.

Asset scope
Site scope
Environment scope

ACTION

Network access is not operation authority

Authorize the exact operation class and protected parameters rather than treating connectivity or broad system access as permission to act.

Action schema
Parameter integrity
Destination binding

STATE

Current conditions bound current authority

Maintenance, safety, process, risk and change state determine whether delegated operational authority remains valid now.

Current state
Maintenance mode
Change window

POLICY

The requesting system cannot redefine its authority

Customer-defined deterministic policy remains independent of the AI or automation requesting the protected operation.

Explicit policy
Customer rules
Independent authority

EVIDENCE

Operational authority remains traceable

Preserve the actor, policy, authoritative facts, exact bound operation, release result and authoritatively reported execution result.

Decision reasons
Operation hashes
Reported result

PROTECTED EXECUTION & LOCK

Arximus controls the protected execution path. Customer infrastructure executes.

For protected operations, Arximus authorizes and binds the exact Protected Execution Function or submitted operation, target asset, protected parameters and approved destination before controlling what reaches customer-controlled execution. Operational credentials, infrastructure authority and local control remain inside customer systems.

01 AI / Automation

Requests a protected capability or submits the exact operational action it proposes to perform.

→

02 ARXIMUS Authorization

Evaluates trusted actor identity, delegated asset authority, exact operation, protected parameters and required authoritative state.

→

03 Authorized Release

Binds and releases only the exact authorized operation to the approved customer-controlled execution destination.

→

04 Customer Executor

Performs the actual operational action using customer-controlled credentials, infrastructure authority and local operational controls.

ARXIMUS LOCK

Bypassing the authorized path invalidates the protected operation.

Customer-controlled gateways, networks, service boundaries or executors enforce the trusted Arximus path and reject protected operations that arrive outside the required authorization boundary.

Arximus AUTHORIZE + BIND + RELEASE

Enforce trusted actor identity, delegated operational authority and deterministic policy.
Bind the exact asset, action, protected parameters and approved destination.
Reject changed or replayed release attempts.
Release only the operation that matches the authorization.

Customer ENFORCE + EXECUTE

Require the trusted Arximus path for designated protected operations.
Reject alternate paths outside the required authorization boundary.
Retain operational credentials, network authority and local control.
Perform the actual operation inside customer-controlled infrastructure.

Trusted release path Exact operation binding Customer enforcement Credential isolation Replay resistance

EXPLICIT FAILURE BEHAVIOR

Technical failure cannot create operational authority.

Required security dependencies have explicit failure behavior. Missing authoritative state, invalid policy or unavailable release authentication cannot silently convert a protected operation into an authorized one.

Failure Enforced Response Security Principle

Required verifier unavailable A critical operation remains on HOLD or is refused according to the configured failure policy. Missing authoritative state is not authorization.

Current policy bundle unavailable Runtime uses the last valid signed known-good policy bundle where that behavior is explicitly defined. Fallback authority remains controlled.

No valid policy available Authorization fails closed and protected release does not occur. No policy cannot equal ALLOW.

Required release authentication unavailable The protected operation cannot be released through that execution path. Release authority remains explicit.

Customer analysis unavailable The configured customer policy determines the defined failure behavior for that operation class. Failure behavior is explicit, not accidental.

SECTOR COVERAGE

Different infrastructure. The same underlying authority problem.

The actor-neutral Arximus authority model applies across different operational environments without treating those environments as identical. Each sector defines its own protected operation classes, authoritative facts, operating conditions, policies and customer-controlled execution boundary.

ENERGY

Generation, transmission & distribution

Constrain machine-driven operational changes by exact asset scope, delegated authority, maintenance conditions and current authoritative state.

MANUFACTURING

Industrial production

Control AI and automation actions that affect production assets, engineering configuration or protected process state.

WATER

Water & utility operations

Apply explicit authority to consequential operational changes while customer-controlled systems retain execution authority.

TRANSPORT

Transportation infrastructure

Constrain machine-driven operations by exact asset, route, zone, delegated authority and current operating conditions.

TELECOM

Network & service infrastructure

Authorize consequential automation across protected network changes, configuration, services and operational workflows.

FACILITIES

Physical & building systems

Govern protected machine operations affecting access, environmental controls, building automation and other critical facility systems.

TRACEABILITY & EVIDENCE

Authorization, release and execution remain distinct operational facts.

Integrity-protected evidence preserves trusted actor identity, delegated operational authority, policy version, authoritative verification facts, decision reasons, exact bound operation and release result. Execution is recorded only when the customer-controlled executor or another authoritative source reports the result.

AUTHORIZED Why was this exact operation authorized? actor / asset authority / policy / authoritative facts

≠

RELEASED What exact operation left Arximus? operation hash / protected parameters / destination

≠

EXECUTED What did the customer-controlled system report? acknowledgement / authoritative execution result

AUTHORIZED ≠ RELEASED ≠ EXECUTED. Arximus records each state separately so operational evidence reflects what was authorized, what Arximus actually released and what execution was authoritatively reported by customer-controlled infrastructure.