Agentic actions with approval gates: the human signs

The moment an AI assistant is allowed to change a record rather than describe one, it becomes a user, and a user with unusual properties: fast, tireless, occasionally confidently wrong, readable by anyone who can put text in front of it, and not qualified under any standard. An integrity program cannot give that user the same rights as an inspector. It also should not refuse it every right, because drafting a finding from a photo, scheduling an inspection from a computed interval, or updating a work pack from a spoken note is exactly the work worth handing off. The approval gate is how you get the work without giving up the signature. This paper covers which actions to allow, how the gate should behave, what to block, and what the record has to show.

What is an agentic action and how is it different from an answer?

An answer changes nothing. The assistant retrieves records, summarizes them, cites them, and the records are as they were. An agentic action changes something: a finding is created, a work order is updated, an inspection is scheduled, a crew member is assigned, a report is generated. The distinction is the basis for every control that follows, because the risk profiles are different in kind.

Actions in an inspection platform fall into recognizable categories:

• Create. New findings, work orders, inspection tasks, notes.
• Update. Status changes, field edits, reassignments, reschedules.
• Schedule and assign. Inspections against computed intervals, crew against work packs.
• Generate. Reports, exports, summaries.
• Query and navigate. Read-only, and treated as answers rather than actions.
• Delete. Removal of records, single or bulk.

In a metadata-driven platform these actions can be derived from the record definitions themselves: if a finding has a status field with defined transitions, "move this finding to on hold" is an action the system knows how to express and validate. That is powerful and it is exactly why the gate has to exist, because a system that can express every action will be asked to perform every action.

Why does the human have to sign?

Three reasons, each sufficient on its own.

Accountability. Under API 510, 570, and 653, and under most site procedures, changes to an inspection record are made or approved by a qualified person whose name is on them. An assistant holds no certification and carries no accountability. The approval puts a named person on the change, which is what the standards and the auditors require.

Error. The assistant will sometimes propose the wrong change: the wrong CML, a status transition that skips a required step, a schedule based on a misread interval. A person who reviews the proposal against the record catches the ones that matter, and the ones that get through are at least attributable.

Manipulation. The assistant reads documents, and documents can contain text designed to steer it. A contractor report with an embedded instruction to close a finding is a realistic attack. Prompt-injection detection and retrieved-content scanning reduce this; the approval gate is what makes it survivable, because a proposed action that nobody signs does not execute.

None of these is an argument against agentic actions. They are arguments for a specific shape: propose, review, sign, execute, record. The signature is not friction added to an automation. It is the step that makes the automation admissible. The identity and access model that backs the signature is described in the Trust Center.

Which actions should be gated, and which blocked outright?

The default answer is simple: every create and every update requires approval unless a tenant deliberately relaxes it for a specific low-risk action. Reads do not. That leaves the harder question of what should not be available even with approval.

Block outright:

• Bulk delete. No single approval should authorize the removal of many records, and no approval flow is safe against a confident request at the end of a long shift. The action should not exist for the assistant.
• Security and permission changes. Role assignments, permission grants, tenant configuration. The assistant should never be a path to elevate anyone, including itself.
• Anything irreversible across many records. Mass status changes, mass reassignments, mass edits to design-basis fields.

Gate with approval:

• Single-record creates and updates.
• Scheduling and assignment.
• Report generation that will be distributed.

Allow without a gate, at the tenant's option:

• Drafts that are invisible downstream until a person promotes them.
• Read-only queries and summaries.

The line between "gate" and "block" is blast radius. If the worst case of a wrongly approved action is one bad record that can be undone, gate it. If the worst case is a day of recovery, block it and require a human to do it through the normal interface, with the normal permissions. The compliance posture this supports is the subject of intelliCOMPLY.

How should approvals expire and escalate?

An approval request that sits open indefinitely is a standing authorization waiting to be clicked by the wrong person against a record that has changed since the request was made. An approval request that silently dies is a stalled workflow nobody notices. Both are avoided with two timers:

• Escalation. If the requested approver has not acted within a short window (minutes), the request is raised to a second approver or a wider group. The work does not stall on one person's attention.
• Expiry. If nobody has acted within a slightly longer window, the request expires and the proposed change is discarded. Executing it later would require a fresh proposal against the current state of the record.

The windows should be short. Ten minutes is a reasonable expiry for a field action, with escalation at half that. The reasoning is that the approver is meant to be looking at the same situation the assistant proposed against; an hour later the technician has moved on, the record may have been edited, and the approval would be of a proposal about the past.

Expired and escalated requests are events, not silence. They belong in the audit trail and in the tenant's operational view, because a pattern of expiries on a particular action says either that the action is not useful or that the approver is not available, and both are worth knowing.

What does segregation of duties look like with an assistant in the loop?

Segregation of duties rules exist so that no single person can both create and approve a consequential change. An assistant complicates this in one direction and simplifies it in another.

It complicates it because the assistant acts on behalf of a user. If the technician asks the assistant to create a finding and then approves the assistant's proposal, the technician has effectively created and approved their own record with one extra click. The gate has to know who the requester is and apply the same rules it would apply to that person acting directly: the approver of an assistant-proposed change should be someone other than the person who asked for it, where the tenant's rules require that separation.

It simplifies it because the assistant's proposals are explicit and structured, which makes the rules enforceable at the point of approval rather than discoverable at audit. "Author cannot approve their own" is a rule a gate can check on every request. The permission model underneath does the rest: the assistant can propose only actions the requesting user is permitted to perform, on records the user is entitled to reach, and nothing in the assistant's path lets anyone exceed their own role. A permission change should also invalidate any pending proposal made under the old permissions.

What must the audit trail and undo log show?

An agentic action produces a chain of events, and every link has to be in the record:

1. The proposal. What the assistant proposed, against which record, on whose request, and what it retrieved or read to arrive there.
2. The decision. Who approved or rejected, when, and, for rejections, why.
3. The escalation or expiry, if either happened.
4. The execution. What actually changed, with the before and after values.
5. The undo path. Enough to reverse the change, and the reversal itself as an event if it happens.

These events belong in the same tamper-evident audit trail as human edits, not in a separate AI log that can be pruned or that auditors have to reconcile. An auditor asking "who changed this finding's status" should get the same shape of answer whether a person or an assistant made the edit, with the assistant's proposal and the approver's signature both visible.

The undo log is the safety net under the gate. Approvals will occasionally be wrong. A recorded, reversible mutation turns a wrong approval into a corrected record with a visible history rather than a silent error in the asset's past. The grounding and citation controls that govern what the assistant reads are covered in the companion paper on Spectra.

How intelliSPEC handles it

Spectra exposes 59 agentic actions in 9 categories, generated from the platform's metadata so that the actions available match the record definitions the tenant actually runs. Create and update actions require approval by default. Bulk delete is blocked outright and is not available to the assistant under any approval. Approval requests escalate after 5 minutes and expire after 10, so a pending proposal is never a standing authorization and never a silent stall.

Every mutation that executes is written to an undo log, and every create, update, and delete that results is an event in the hash-chained audit trail with actor, tenant, request id, IP, and user agent, in the same per-tenant SHA-256 chain as human edits. A verify routine recomputes the chain for auditors, and audit events are never auto-deleted.

The gate sits on top of the platform's access control: 991 permission entries in 25 categories, seven default roles per tenant with custom roles and templates, node-level data entitlement over the asset graph, and two segregation-of-duties rules today (no self-elevation to tenant admin, and a calculator author cannot approve their own). Permission changes invalidate stale tokens. Prompt-injection detection runs on inputs and retrieved-content scanning on the documents the assistant reads, and groundedness and red-team evaluation suites exercise the assistant against adversarial inputs. The assistant drafts and proposes; the person with the role signs.