Reading an inspection log, creating a maintenance order and changing a machine parameter are three different interventions. They should therefore trigger different approval procedures. If every step displays the same confirmation dialog, extra work accumulates while the decisive risks remain in the background.
Under priority P2, SupraWorx focuses on productising risk-based approval levels, clear allowlists and, where appropriate, mandatory two-person approval. The classification is medium effort with high expected impact. This is a qualitative prioritisation, not a validated effort estimate. This article describes the target model; it does not announce universal availability across all integrations.
Human Approval + Technical Safety Envelope as the foundation
Human consent establishes whether a specifically described action is intended from a process perspective. The technical envelope separately determines whether it is permissible on the target system. Both checks must pass. The supporting sources and the subsequent execution record must also remain visible for every action.
Risk depends on the potential effect: scope, reversibility, data sensitivity, operating state and proximity to physical processes. A read-only operation can require stringent controls if it exports sensitive data. A small parameter change can be consequential if it alters a critical machine state. An AI model must not be able to move its own action into a lower approval level through a free-form risk assessment.
Four levels for designing the process
- Level 0 — bounded observation: Already authorised, tightly scoped read access without additional external effects may proceed under predefined rules. Data access controls and logging remain mandatory.
- Level 1 — controlled preparation: Reversible drafts, such as a maintenance order that has not yet been approved, may be created within the defined workspace. The interface identifies the draft status; follow-up actions remain blocked.
- Level 2 — explicit individual approval: Changes to authoritative records, external transfers or defined device jobs require an authorised person to confirm the target, parameters and effect.
- Level 3 — independent second approval: For elevated risk, the process rule requires two different authorised people. Responsibility for preparation, technical or operational review, and approval is explicitly assigned. Technical execution checks remain an additional requirement.
The operator must assign actions to levels based on the specific process. Some interventions remain excluded from agentic execution altogether. Even two approvals cannot make a technically impermissible action executable.
Allowlisting must be more precise than a tool name
An allowlist should define a narrow operating scope: which tool, operation, target system, device identity, parameter ranges and company context are permitted. Permission to “use the API Gateway” would be too broad. A more meaningful permission allows a specific job type to be handed over to a registered device within validated parameter limits.
Every combination that is not explicitly allowed is rejected. Server-side validation prevents an agent from achieving the same prohibited effect through another URL, an alternative operation or a free-form tool instruction. Device commands and data exports each need appropriate boundaries.
An approval belongs to an unchanged action
The approval dialog must show the version that will actually execute: target object, parameter change, expected effect, source versions and validity. If a relevant parameter or the target device subsequently changes, the action must be checked again and, where necessary, approved again. Consent for a draft does not automatically apply to a later revision.
Roles, approval status, expiry and device state are checked again before execution. A permission revoked in the meantime or a changed operating state may block the job. Approval is therefore a limited mandate for a specific operation.
Two-person approval needs clear responsibilities
A second confirmation by the same person does not satisfy the two-person principle. The target model requires separate identities, appropriate qualifications and a visible review basis. Self-approval and changes to the underlying rules by the executing agent are excluded. If approval is rejected or not provided, the operation remains open or is ended in a controlled way; a timeout must not replace consent.
Example: From a maintenance alert to a device job
An agent identifies a maintenance need in approved measurement data. It first creates a draft with sources and a machine reference. The responsible person checks the scope and timing. If this is to become a device job, that job is evaluated as a separate action. Elevated risk adds an independent second approval. Only then does the device interface check the allowlist, parameters and current state.
If no unambiguous response is received after handover, the status is treated as unresolved. An automatic retry must not cause a duplicate effect. The integration therefore needs unique job identifiers, status reconciliation and defined error handling. The audit documents the proposal, approvals, policy version and outcome.
How to assess a productised capability
Acceptance testing includes attempts involving devices that are not allowed, changed parameters, expired approvals, self-approval and interrupted connections. Alongside processing time, relevant measures include blocked impermissible actions, ambiguous outcome states and the completeness of decision records. The objective is a process whose boundaries demonstrably work in day-to-day operation.
Your next step: Work with SupraTix to define a single tool or device process, including its risk level, allowlist and acceptance criteria. This provides a basis for a bounded pilot of responsible agentic work.
