MP-23 · Authorized Tool Loop

MP-23 is the fourth formally packaged Harness Engineering lab. It turns Chapter 11 into a build–break–measure–defend exercise around one production rollback tool.

Outcome

You will produce a content-addressed report containing:

• one strict, versioned external-write contract;
• one tenant- and policy-scoped principal grant;
• one parameter-bound human approval;
• one authorized invocation and verified execution;
• ten authorization, execution, and uncertainty mutations;
• independently replayable authorization and execution receipts;
• one stable report artifact.

Run the reference

cd rust/rust-ai-engineering
cargo test -p mosaic-tools contract
cargo run -q -p mosaic-tools --example authorized_tool_receipt

Artifact:

target/labs/mp-23/2ddf1a1f5c19567e5a23a64e597ab8cba52b7ad310e62b91d6d883ccc612216b.json

Expected:

authorization          authorized
execution              verified_succeeded
mutations              10 / 10
artifact bytes         2,122
artifact SHA-256       08c281cb7fdde28d181ed302c7587a491ceb478c112a1080c25dd3a1d9ed7099

Predict

Before running the example, classify tool-not-allowed, capability-missing, tenant drift, contract drift, missing idempotency, missing approval, approval-input drift, incomplete effect receipt, idempotency drift, and indeterminate effect. Name whether authorization, execution verification, or reconciliation owns each result.

Build this table:

Case	First responsible boundary	Expected result	Executor may run?
Exact valid call	authorization, then execution	verified success	yes
Tool missing from grant	tool allowlist	tool_not_allowed	no
Capability missing	capability intersection	capability_missing	no
Tenant drift	scope	tenant_mismatch	no
Contract digest drift	contract pin	contract_mismatch	no
Missing idempotency key	retry contract	idempotency_required	no
Missing exact approval	approval	approval_required	no
Approval input drift	approval integrity	approval_mismatch	no
Missing effect fields	receipt verification	write_receipt_incomplete	already ran
Unknown timeout outcome	reconciliation	reconciliation_required	unknown

Trace

Trace the contract identity through invocation, approval, authorization receipt, execution observation, and execution receipt. Then trace the same idempotency key through invocation and effect observation. Finally, trace tenant and policy through grant, invocation, and approval.

The important distinction is temporal:

proposed call
  -> deterministic authorization
  -> executor boundary
  -> observed outcome
  -> deterministic receipt verification
  -> reconciliation when outcome is uncertain

Authorization does not prove execution. A transport success does not prove the intended state change. A timeout does not prove failure.

Implement

Add one new tool:

• a read-only deployment inspector;
• a rollback preview that creates a draft;
• a reversible feature-flag write;
• or an irreversible credential revocation.

Do not copy the rollback metadata blindly. Choose its effect, capabilities, approval policy, idempotency mode, timeout, input/output bounds, and receipt requirements from first principles. Add ordinary, boundary, denial, replay, and uncertainty tests.

For the credential-revocation option, the contract must be irreversible and non-reversible. Require an exact approval, an idempotency key, an effect ID, and independently observable post-state. Do not call a second revocation merely because the response was lost.

Break

Temporarily allow external writes without exact approval-input binding. The approval-input-drift mutation must fail. Restore the comparison and retain the regression.

Then weaken contract identity to tool name alone. Demonstrate that a changed executor release or schema could inherit stale approval. Restore digest binding and add a stored-receipt mutation.

Measure

Benchmark 1, 8, 32, and 64 required capabilities and allowed tools. Record:

• contract/grant validation time;
• deterministic authorization time;
• stable serialization and digest time;
• execution-receipt verification time;
• receipt byte size;
• reconciliation lookup latency and attempts.

Separate local policy arithmetic from identity-provider, approval-store, executor, and target-system latency. Report medians and tails with the fixture and source revision. A faster path is invalid if it weakens exact binding or changes any mutation result.

Defend

Review:

• Can untrusted evidence influence a call without becoming authority?
• Can one tenant’s approval authorize another tenant’s target?
• Does the tool process hold broader credentials than its contract exposes?
• Can a model select its own approval or policy digest?
• What prevents a stale retry from applying twice?
• How is an indeterminate effect reconciled without repeating it?
• Which outcome fields come from the executor, and which are independently checked?

Failure investigation

Symptom: a rollback request timed out and a retry appears to have changed state twice.

Inspect the exact input and idempotency record, both transport attempts, executor release, effect ID, target generation, before/after state, authorization receipt, approval expiry, and execution receipt. Locate the first stage that stopped preserving one logical operation.

Write:

expected one-operation invariant
first divergent identity or state
why retry was considered safe
whether either response was lost
reconciled target truth
containment
code and data repair
proof of non-recurrence

Do not treat “request failed” as “effect did not happen.”

Evidence to submit

• unchanged reference artifact and SHA-256;
• your tool contract and threat classification;
• ordinary, boundary, denial, replay, and uncertain-outcome tests;
• one malicious or stale approval fixture;
• benchmark JSON and interpretation;
• one reconciliation failure investigation;
• a sequence diagram from proposal through post-state verification;
• a reviewer note stating what remains outside the guarantee.

Completion rubric

Score each dimension 0–2: contract, authorization, execution proof, tests, measurement, and security reasoning. A zero in authorization, execution proof, or security reasoning requires revision. Full completion requires at least 10/12 and no zero.

Continue to the replayable model loop only when every effect can be classified as verified success, verified no-effect failure, or indeterminate with an explicit reconciliation owner.