Engineering walkthrough · 18 September 2026

An audit trail for AI-agent actions: a Git-tag walkthrough

A tool's success message leaves several questions unanswered: what operation was proposed, why was it permitted, and did the resulting state match the intended outcome?

RMT Platform makes those questions inspectable for operations submitted through its governed gateway. Its local showcase uses a disposable Git repository: propose creating a tag, inspect the decision, resolve any approval hold, and later propose removing the tag. The client is deterministic. No model produces the proposals, so readers can examine the control flow without setting up an LLM.

The example below comes from a recorded local run, with its transcript and audit records available. It is an operator walkthrough using one identity. Approval inputs were automated for the recording.

1. Establish scope before proposing an operation

The client requests a grant through POST /agent/authority/grant, naming the operation and target tag. That gives the following proposal a concrete scope. Being able to describe another operation does not make the earlier grant suitable for it.

The grant belongs to the agent-facing admission flow. It does not replace the policy, risk, approval, and execution authorization decisions that follow. These stages answer different questions and should remain distinguishable when investigating a result.

2. Preview without confusing prediction with execution

Next, POST /agent/act/preview returns a prediction of policy, risk, and approval requirements. In the captured run, creation was classified as medium risk and required manual approval. Preview did not create the tag or consume the grant.

A preview helps an operator understand what is likely to happen when a proposal is submitted. It is not an execution receipt, and it does not establish that the intended state exists.

3. Read a hold as a pending decision

Submitting the proposal through POST /agent/act returned hold. Both execution_id and verification_status were absent. An independent check confirmed that the tag did not yet exist.

The client then used the approval endpoint. The response reported execution success and verified_success. A subsequent check found the tag present. That sequence connects the proposed action, the approval continuation, and an observed result instead of treating a pending hold as a completed operation.

4. Preserve the actual refusal reason

The walkthrough next attempted removal using the earlier creation grant. RMT returned no_authority with grant_consumed. There was no third execution audit record.

This attempt changed the operation and reused a consumed grant, so it does not isolate every grant rule. The useful evidence is the refusal actually returned. A refusal before governance is also not evidence that a new governed execution receipt was written.

5. Separate execution from verification

A new removal grant allowed the client to submit the removal proposal. That proposal was held too, with the tag still present before approval. After approval, the response reported success and verified_success; an independent check found the tag absent.

Other environments can produce different decisions or unavailable observations. An adapter may fail after invocation, and an executed action may lack enough evidence for verification. Keeping these outcomes distinct helps an integrator decide whether to inspect, wait, or seek operator input.

What this example does not prove

The same operator credential grants authority, proposes work, and submits approval in this client. It does not demonstrate separation of duties. Human involvement must not be inferred from an automated recording.

The supported deployment uses one backend process. A shared HTTP continuation lock mitigates the reviewed concurrent-approval race at that boundary; concurrent direct Core calls and multiple processes remain outside that control. RMT does not offer a general exactly-once or automatic rollback guarantee.

The recording predates the later security fixes. Current fixes include strict authentication configuration parsing and aborting approval when the client's stdin closes. Their separate tests and deployment evidence are in the remediation report. This article does not reclassify the older recording as a new security test.

Try it and tell us what is missing

Follow the showcase prerequisites using a disposable backend and scratch repository. The Python client uses the standard library, but the backend must already be installed and configured. Do not target a production repository.

Useful feedback is specific: where did setup become unclear, which response field was hard to interpret, and what evidence would you need to investigate an unexpected result? Share it in GitHub Discussions, or take a small documentation issue.

Prepared with AI assistance from the repository's API contract, recorded demo, and security evidence. This is a technical project introduction, not an independent security certification.