In-process hash chains cannot be independent. That is not a bug in AGT; it is a boundary the design cannot cross.
Microsoft AGT is a good piece of open-source engineering. It also records audit data inside the same process that runs the agent. That one fact determines what the record can and cannot prove, and this page explains exactly what that means.
A hash chain is a chain of SHA-256 digests: each record includes the hash of the previous one, so any alteration breaks the chain. That is a real and useful integrity property. It catches storage corruption, accidental truncation, and a careless operator who edits a file by hand.
What it cannot catch is a deliberate rewrite by the party who holds the chain. If the process that computes the chain also has write access to the records, it can alter a record and recompute the chain over the altered version. The result is a valid chain. Nothing fails. There is no way to distinguish it from an unaltered chain.
This is not a flaw in AGT's SHA-256 implementation. It is a structural property of in-process recording: the auditor and the agent share the same trust boundary.
What AGT's chain protects against
AGT does real work here. The SHA-256 hash chain in AGT's audit and compliance module catches accidental corruption, file-system errors, truncation, and an operator who edits a record carelessly without updating the chain. It also ships with zero-trust identity, policy enforcement, sandboxing, and a OWASP Agentic AI Top 10 mapping. For a team that trusts its own infrastructure and needs a lightweight, MIT-licensed governance layer with Azure-native integration, AGT is a solid choice and may be all you need.
What the chain cannot protect against
The AGT documentation describes its audit trail as "tamper-evident" and that is accurate for the scenario above. The boundary it cannot cross is this: if the party who ran the agent is also the party a third party needs to be protected from, in-process recording does not help. The chain is recomputable by the same process that writes the records. There is no independent party who observed the records before they could be changed.
This matters in practice when:
A client wants to verify what an AI contractor's agent actually did, without trusting the contractor's own logs.
A regulator inspects a high-risk AI system's event log and needs to know the deployer did not alter it after an incident.
A counterparty in a contract dispute produces an agent activity record and the other side cannot simply accept it on trust.
An insurer or auditor requires evidence that a specific automated decision happened as described, not reconstructed from memory.
In each of these, the question is not "was the log corrupted accidentally" but "can the operator prove to someone who does not trust them that the log was not altered deliberately." A chain that can be recomputed by the operator does not answer that question.
Three mechanisms together produce a record that can be verified by a party who trusts neither the agent nor Provenrail:
Ed25519 signing at capture. Each record is signed with a device key before it leaves the agent process. The key is held by the agent's machine, not by the sink. A sink that never held the key cannot forge a record it did not receive, and cannot produce a valid signature for an altered version of one it did receive. (src/provenrail/chain.py, src/provenrail/keys.py.)
Independent server receipt chain. The sink chains arriving records on its own as they land. A client-side deletion or reordering is visible because it breaks the server's independent chain, not just the client's. A hostile agent cannot rewrite what already reached the sink. (src/provenrail/chain.py docstring: "the server independently re-chains records on arrival so a hostile agent cannot delete or reorder what already landed.")
External anchoring to independent time sources. The sink periodically computes a Merkle root over a batch of receipt hashes and sends it to a third-party RFC 3161 timestamp authority. The TSA signs a token that commits to that root and the time, using a key Provenrail does not hold. A verifier can check the token with any RFC 3161 library, with no dependency on Provenrail. Beyond the TSA, a transparency log records a checkpoint and accepts witness cosignatures from independent third parties using the C2SP wire format. (src/provenrail/anchor.py, src/provenrail/tlog.py.)
Honest scope. The device key is a static Ed25519 key, not a forward-secure key. If the key is compromised after the fact, past signatures cannot be forged, but future ones under a stolen key could be. The server receipt chain and external anchors carry the primary tamper-evidence property. The comment in keys.py says this plainly: "The MVP's teeth come from the off-box append-only server receipt chain, not from this key." The browser verifier (web/verify.js) checks Ed25519 signatures and hash chains in your browser; it reports RFC 3161 tokens as present but does not validate the CMS structure, which requires a library not yet available in browser WebCrypto. Full RFC 3161 validation runs in the CLI verifier.
The anchor-only trust service: self-host everything, keep the independence
Some operators cannot or will not send their agent records to any third party. Provenrail ships a purpose-built answer for that case: the anchor-only service.
The customer runs the AGPL sink on their own infrastructure and keeps every record. When they want an independent anchor receipt, they compute a Merkle root over their own record hashes and send Provenrail only that root, plus a coverage count. Provenrail timestamps the root via RFC 3161, stores an append-only sequence of roots, and makes each anchor publicly retrievable by ID so an auditor can check it with no account and no contact with the customer.
Because a SHA-256 root over record hashes is not personal data and is not reversible to any record, this arrangement does not make Provenrail a GDPR data processor. The customer holds all evidence; the independent anchor receipt is separate from it. (POST /v1/anchors in src/provenrail/server/app.py; tests/test_anchor_only.py verifies the endpoint structurally cannot accept a record.)
AGT has no equivalent. There is no independent third party in its design, so there is nothing to separate from the data.
Use AGT when your threat model is accidental corruption, not a disputing counterparty.
Your team runs the agent and is also the auditor. No outside party needs to verify the log.
You are on Azure and want native policy enforcement, zero-trust identity, and sandboxing with no additional vendor relationship.
You need OWASP Agentic AI Top 10 coverage and a well-documented MIT-licensed starting point.
Budget for a managed service is zero. In-process SHA-256 chains cost nothing and catch real problems.
You can satisfy your compliance requirement with a hash chain and a vendor badge. For many internal enterprise deployments this is true.
If none of the cases below apply to you, AGT is probably simpler and sufficient.
When you need more than AGT
There is a specific set of situations where in-process recording is not enough, regardless of how well it is implemented:
A client or counterparty needs to verify what your agent did without trusting you. A contractor delivering AI-generated work to an EU client, a SaaS vendor whose agents take actions in a customer's environment, or any situation where the verifier and the operator are different parties.
A regulator or auditor examines a high-risk AI system. EU AI Act Article 12 (in force December 2027 for standalone Annex III systems) requires retained event logs. A log that can be altered without detection by the party being audited has limited evidentiary value. The regulation does not prescribe a method, but an independent timestamp from a third-party TSA is a defensible position; an in-process chain is not.
An incident occurred and you need to prove what happened, not just describe it. Insurance, legal proceedings, or a customer SLA dispute may require a record that survives a challenge. A chain that can be recomputed by your own process does not survive "you could have altered this."
You want independent anchoring without sending records to anyone. The anchor-only service is specifically for this: keep every record yourself and send only a hash root to be timestamped by a third party.
Provenrail is overkill for a team that only needs to debug its own agent or satisfy an internal compliance checkbox. It is designed for the cases above, where the independence of the record matters to someone outside your organization.
See it for yourself
The verifier runs in your browser. Nothing is sent anywhere. Open a real record, then watch the same record fail after it has been altered.
No. AGT is a well-built, free, MIT-licensed tool that ships real governance features for Azure environments. The point is narrower: in-process hash chains cannot produce an independently verifiable record, and that is a structural property, not a quality failure. Use AGT when you do not need an independent third party to verify the log. Use Provenrail when you do.
Can I run both?
Yes. AGT handles policy enforcement and sandboxing at runtime; Provenrail captures an independently verifiable record of what happened. They are not substitutes for each other in those roles. You would run the Provenrail SDK alongside AGT, the same way you would run it alongside any other governance layer.
What exactly does "independent verification" mean?
A third party can confirm the record is intact and correctly dated using an open-source verifier, with no account, no network call to Provenrail, and no trust in the agent or the sink. The proof travels with the record. For RFC 3161 timestamps, the verifier uses the TSA's public certificate chain, which is published by the TSA, not by Provenrail.
Does the anchor-only service mean I never send Provenrail my records?
Correct. You self-host the AGPL sink, keep every record on your infrastructure, compute a Merkle root over your record hashes locally, and send only that root to the anchor service. Provenrail timestamps it and stores the root in an append-only sequence. An auditor can retrieve the timestamped root by ID with no account. The root is not reversible to any record. Nothing Provenrail stores is the content of your agent's activity.
What is the AGT source?
The AGT open-source announcement was published by Microsoft on 2 April 2026. The audit and compliance design is described in the AGT tutorial documentation. Provenrail is not affiliated with or endorsed by Microsoft.