Skip to main content

Guide · Control specification

Human approval of ERP writes, control by control.

Human-in-the-loop approval means a named person authorizes a consequential write before it reaches the ERP.

It applies whoever proposed the write, a colleague or a model. This page states what it takes, as eight controls.

OWASP Gen AI Security Project lists it among the mitigations for excessive agency: “Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken.”

As of . Production status follows our next production verification.

Specification

The specification puts eight controls between a proposal and a write.

Each row gives what the control requires, the test files behind it and its status in our repository. Each identifier links to its row in the claims register.

The status column is the state of our repository, not of the service we run today. Production status follows our next production verification.

Control specification: 8 controls, each with its test files, its status in our repository, and its production line
ControlWhat it requiresTest filesRepository statusProduction
Separation of dutiesSOD-01An approval by the proposer on record must be refused, at approval and again at dispatch.
  • db-proposal-lifecycle.test.ts
PartialUntil a pending migration is applied, a member can set who is on record.Follows our next production verification.
An authorization bound to the writeAUTHZ-01A write must be dispatched only under a server-recorded human authorization. It must bind the exact proposal and payload, and meet the policy’s quorum.
  • replay-rollback-routes.test.ts
  • engine-preflight-gate.test.ts
  • execution-authorization.test.ts
VerifiedFollows our next production verification.
Replay under the same authorizationAUTHZ-02A replay must not re-run a write that was never approved, was revoked, or no longer matches its authorization.
  • replay-rollback-routes.test.ts
VerifiedFollows our next production verification.
A second approverAUTHZ-03When policy requires it, a second, distinct person must approve. Policy requires it for a high-risk, irreversible write, or one at or above an amount threshold.
  • approval-rule.test.ts
  • replay-rollback-routes.test.ts
VerifiedFollows our next production verification.
Revocation up to the sendAUTHZ-04A revoked authorization must dispatch nothing. That includes a revocation recorded after the check and before the send.
  • engine-preflight-gate.test.ts
VerifiedFollows our next production verification.
A halt without a deployKILL-01Execution must be haltable for one organization or for all, without a deploy. A halt that cannot be read must count as a halt.
  • kill-switch.test.ts
  • engine-preflight-gate.test.ts
  • execution-control-route.test.ts
  • replay-rollback-routes.test.ts
VerifiedFollows our next production verification.
Executed only on confirmationEXEC-01A write must be recorded as executed only when the provider confirms it. Otherwise it must be recorded failed, with evidence that nothing was written, or unknown.
  • restlet-contract.test.ts
  • testimony-corroboration.test.ts
  • connector-egress.test.ts
  • compensation-sent-outcome.test.ts
  • replay-rollback-routes.test.ts
  • execution-uncertainty.test.ts
VerifiedFollows our next production verification.
No settlement on one person’s wordEXEC-02One operator’s finding must not settle whether a write landed. A second, distinct operator who is not the proposer must agree, or a provider lookup must settle it.
  • testimony-corroboration.test.ts
  • decision-lifecycle-evidence.test.ts
  • execution-evidence.test.ts
  • reconciler-run.test.ts
  • member-look-bound.test.ts
  • db-execution-look-claims.test.ts
  • reconciler-claims.test.ts
  • execution-account-binding.test.ts
VerifiedFollows our next production verification.

Reading the status

The status is our repository’s, not the service we run.

Verified means a test or a reading shows the control holds in our repository.

Partial means part of it holds. The row says which part does not yet.

The full register, with each test and its evidence, is shared on request under NDA.

Downstream

Authorization inside the ERP still matters.

OWASP Gen AI Security Project also advises: “Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.”

These controls govern what a service may send. The ERP’s own roles govern what the connected account may do. Keep that role narrow.

The NetSuite guide compares the approval patterns inside and outside NetSuite.

Vendor review

Any vendor can be asked the same eight questions.

For each one, ask for the test that shows it, and its status in the service you would use.

  1. Is an approval by the proposer on record refused, at approval and again at dispatch?
  2. Is the authorization bound to the exact payload, and checked again at the send?
  3. Can a replay re-run a write that was never approved, or was revoked?
  4. Can policy require a second, distinct approver?
  5. Does a revocation stop a write that is about to be sent?
  6. Can execution be halted without a deploy?
  7. Is a write recorded as executed only when the provider confirms it?
  8. Can one person’s word settle whether a write landed?

Sources

The outside source is quoted from this page.

It was read on 9 October 2026. Facts about Nervos come from our claims register.

To correct a fact, write to hello@thenervos.com.

  1. 01

    LLM06:2025 Excessive Agency

    OWASP Gen AI Security Project. Read 9 October 2026.

The claims register

Each security claim, and where it stands.

The register gives the status of each of our security claims in our repository. Production status follows our next production verification.

Read the claims registerNetSuite approval patterns