Sanitizing AI coding sessions before external review: the redaction workflow that ships

The day before an external review is the day you discover what is actually in your AI coding sessions. A real customer name buried in a tool input. A snippet of restricted code in a model response. A path that exposes more about your infrastructure than you wanted to share.

The wrong answer is to clean it up by hand. By-hand redaction breaks integrity. The right answer is a redaction workflow that produces a sanitized derivative bundle with sentinels in place of the redacted content, a recorded reason on every change, and a verification step before sharing.

This article walks Akmon's redact command end to end. The commands and the sentinel format are real Akmon v2.0.0 surface.

Why "I will edit it by hand" does not survive

Three reasons.

First, the audit chain is cryptographic. If you change a byte without producing a new chain, the chain stops verifying. Your auditor opens the file, runs audit verify, gets a failure, and the conversation is over.

Second, redaction without a reason is not auditable. The reviewer needs to know that this object was redacted on purpose, and why. A sentinel with a reason field is the record.

Third, ad hoc edits do not round-trip. If you produce a clean derivative bundle that re-imports cleanly and verifies offline, you have something portable. If you produce a one-off edit, you have something that might or might not survive transport.

The workflow below avoids all three failure modes.

The command

akmon redact <session-id> [OPTIONS]

A typical invocation:

akmon redact <session-id> \
  --output sanitized.akmon \
  --object <object-hash> \
  --reason "PII removal" \
  --format json

For multiple objects, repeat --object:

akmon redact <session-id> \
  --output sanitized.akmon \
  --object <hash1> \
  --object <hash2> \
  --object <hash3> \
  --reason "Removed customer names and one credential reference"

Find the right hashes with akmon inspect --resolve:

akmon inspect <session-id> --resolve | less

That is the loop: inspect, decide, redact.

The sentinel format

Every redacted object is replaced by a canonical CBOR sentinel. The payload looks like this in JSON form:

{
  "akmon_redacted": true,
  "original_hash": "<hex of original>",
  "original_size": 1024,
  "reason": "<text from --reason>",
  "redacted_at": "<RFC3339 timestamp>"
}

A reviewer reading the bundle can see that an object was redacted on purpose, can see why, and can confirm that the original size is what was expected. The chain still verifies because the sentinel hashes correctly.

This is a small but important design choice. The sentinel is not a placeholder. It is a record. The redaction is itself part of the evidence.

Verifying the sanitized bundle before sharing

Always verify before sending. The cheapest possible smoke test:

akmon bundle import sanitized.akmon --verify-only

This re-runs the AGEF verification on the derivative bundle. If anything is wrong (a missing object, a hash mismatch, a malformed manifest), the verifier fails loudly. Treat this as the gate before any handoff.

For deeper confidence, replay the sanitized session in a sandbox:

akmon replay <derivative-session-id> --mode strict --format json

A clean replay confirms that the bundle still tells a coherent story.

What to redact, and what not to

A practical rule of thumb. Redact what cannot leave the building. Keep what makes the session reviewable.

• Redact: customer names, account numbers, secrets that leaked into a tool input, snippets of code that fall outside the disclosure scope.
• Keep: tool IDs, policy decisions, structural events (SessionStart, UserTurn, ProviderCall, AssistantTurn, SessionEnd), provider identifiers, model versions, attempt statuses.

The structure of the session is what makes it auditable. The content is what makes it sensitive. Redaction is the line between them.

The exit code map

Code	Meaning
0	Derivative bundle written successfully
2	Usage error (output exists, invalid hash format, object not in session, missing required flag)
3	I/O or environment error (journal or session not found, write failure, unreadable referenced object)

For automation, treat anything other than 0 as a hard stop.

A small story from a tester

A friend who runs an embedded team for a medical device manufacturer ran me through their first audit using Akmon last quarter. The auditor asked for a representative session that touched the firmware build path. The team chose three sessions, ran inspect --resolve on each, and listed the objects to redact: two contained patient IDs from a test dataset, one contained an internal vendor name.

akmon redact $sid \
  --output "audit-pack/$sid.akmon" \
  --object $hash_patient_a \
  --object $hash_patient_b \
  --object $hash_vendor \
  --reason "PHI removal and vendor identification removal for IEC 62304 audit"

They verified each derivative bundle:

akmon bundle import "audit-pack/$sid.akmon" --verify-only

And handed the auditor the three bundles plus an executable verifier. The auditor verified each one offline and proceeded. The conversation took an hour, not a week. The team now treats the redaction step as a normal part of audit prep.

A common mistake to avoid

Do not redact more than you need to. Every redaction shrinks the auditor's ability to follow the session. If you redact AssistantTurn messages and ToolCall outputs aggressively, the bundle stops telling a story.

The right mental model: redact the smallest set of objects that removes the sensitive content. Keep everything else.

Stronger guarantees on top of redaction

Redaction provides selective content removal with documented reasons and verifiable structure. It does not provide identity attribution by itself. If your environment requires producer trust, layer external signing on top of the bundle. The AGEF spec is explicit that signing is expected in later versions; for now, signing is your job.

A practical approach: sign the bundle with your team's key, distribute the signature alongside, and document the verification procedure. The auditor verifies the signature first, then runs bundle import --verify-only.

Where this leaves you

After the redaction workflow is in place, three things are true.

First, you can hand any session to an external reviewer with a single bundle.

Second, the redaction is itself part of the evidence. The reviewer can see what was redacted and why.

Third, the integrity guarantees survive transport. The bundle verifies offline.

If you want to dig deeper into the policy side of the loop, the next post in this series goes deep on policy profiles and packs, the deterministic merge that controls what the agent can do.

The repo is at github.com/radotsvetkov/akmon. The format spec is at github.com/radotsvetkov/agef. The site is at radotsvetkov.github.io/akmon.