The three tools split cleanly: record_action seals what happened together with authorized_by and reasoning, query_actions reads it back filtered by agent or action type, and verify_chain shows that nothing in between was altered by checking that each entry's SHA-256 hash still contains its predecessor's. The tool text is explicit that record_action belongs after every significant action — sending emails, modifying files, running queries, making API calls — which puts the burden on the calling agent rather than on the server, and an action nobody recorded leaves no trace here. What you get in return is narrower and more checkable than a log: a record whose modification is both detectable and locatable.
An audit-trail server of 3 tools: recording an action with its reasoning and authorisation, querying the recorded history, and verifying the SHA-256 hash chain linking the entries.
- Records that carry why, not only what: record_action takes action_type, action_params, agent_id, authorized_by and reasoning, so a sealed entry states who authorised the action and on what grounds.
- History readable by agent or by kind of action: query_actions filters on agent_id and action_type under a limit, for checking what has already been done before doing it again.
- Tamper evidence instead of trust: each entry's SHA-256 hash includes the previous entry's hash, and verify_chain walks a given agent_id's chain and reports where the break is if a record was modified.
An AgentSeal API key, supplied as AGENTSEAL_API_KEY.
One command plus a key — npx -y agentseal-mcp, then supply credentials