LabscoMCP early access ↗
shahidh68MCP SERVER · OFFICIAL PROJECT

Audit Ledger MCP

Write an AI decision to an audit ledger — model version and hashed inputs recorded, so what was decided can be shown later.

by shahidh68 ↗Agent Guardrails, Content Safety & Audit✓ Official

LABSCO SUMMARY

Hashing the inputs rather than storing them is what makes an audit ledger something you can keep for years.

The obvious design stores the prompt, and then the audit trail becomes a second copy of every piece of customer data the system ever saw — with the retention and disclosure obligations that follow. A hash proves the input was what someone later claims it was without holding it, which is the whole point of an audit record and none of the liability. Recording the model version alongside is the other necessary field: a decision is not reproducible without knowing which model made it, and model versions move underneath you. Four tools around one job — recording a decision and later proving the record is intact and complete — which most systems bolt on badly.

What it is

An audit ledger for AI decisions with four tools: one records a decision with its model version and a hash of its inputs, and three check and query what was recorded.

What you get

  • record_decision writes the decision to the ledger with the model version that made it and hashed inputs rather than the inputs themselves; verify_decision checks a stored record against its immutable copy, verify_completeness finds records that were deleted or are missing, and list_decisions queries recent ones.

Requirements

Nothing to try it: with no environment variables it writes to a shared public sandbox, which is not for real personal data. For production, a ledger you deploy yourself from shahidh68/audit-ledger, plus its URL and your write, read and HMAC keys.

Setup effort

One command — npx -y audit-ledger-mcp