DEV Community

Aniketh
Aniketh

Posted on

What Delve Got Wrong: Why Compliance Evidence Needs to Be Cryptographically Provable

#ai #sec #programming #security

In March 2026, Delve.co was found to have fabricated 494 SOC 2 reports. Pre-written auditor conclusions. Identical templates across hundreds of clients. It went completely under the radar because the evidence was a PDF. You either opened and trust what you read or you didn't.

That's not a Delve problem(though what people did find in those reports is truly wild). That's an architecture problem. Compliance evidence today can't prove itself. It can and should, by design.

Built pip install agentmint for teams to build their own receipts:

The Receipt

AgentMint generates this for every agent action — allowed or blocked:

{
  "receipt_id": "7d92b1a4",
  "agent": "sre-bot",
  "action": "delete:database:production",
  "in_policy": false,
  "reason": "no scope pattern matched",
  "signature": "Ed25519:a3f9c8e2...",
  "prev_hash": "sha256:e7f2a1b3...",
  "timestamp_rfc3161": "MIIb3gYJKoZI..."
}
Enter fullscreen mode Exit fullscreen mode

Three things make this unfakeable:

Ed25519 Signature — covers the entire receipt. Change one character, signature breaks. Verifiable with the public key alone. No API call. No vendor. No internet.

SHA-256 Hash Chain — each receipt includes the hash of the previous one. Gaps, insertions, or reordering break the chain. Delve's 494 reports had no linkage — no way to detect if a report was modified or fabricated after the fact.

RFC 3161 Timestamp — an independent authority signs the receipt hash with its own clock. Proves the receipt existed at a specific time, even if your servers are compromised.

What Happens When Someone Tampers 

$ # Receipt says action was denied (in_policy: false)
$ # Attacker changes it to look approved
$ sed -i 's/"in_policy": false/"in_policy": true/' receipt.json

$ python3 verify_sigs.py

  ✓ c391e43c  read:logs:prod  (in policy)
  ✗ FAILED  7d92b1a4  delete:database:production  (in policy)

  Signatures: 1 verified, 1 failed
  ↳ One bit changed. Signature broken. Receipt tampered.
Enter fullscreen mode Exit fullscreen mode

The math is mathing or it isn't. No trust required.

What's NOT in the Receipt

Same principle as Merkle trees — the chain is all hashes and metadata, never the underlying data. Which agent, what action, in-policy or not, timestamps, signatures. No customer data. No PII. No credentials. Nothing confidential.

Delve leaked a Google spreadsheet with confidential client reports. AgentMint receipts contain nothing that can be leaked.

How It Maps to Compliance

One receipt chain covers the common denominator across frameworks: who did what, when, was it authorized, and can you prove it.

SOC 2, HIPAA, EU AI Act, AIUC-1, ISO 27001, GDPR — the same signed, hash-chained evidence satisfies audit trail requirements across all of them. Full mapping in COMPLIANCE.md.

Try It 

from agentmint import AgentMint

mint = AgentMint(quiet=True)
plan = mint.issue_plan(
    action="read:reports:quarterly",
    user="admin@company.com",
    scope=["read:reports:*"],
    delegates_to=["analytics-agent"],
)

result = mint.delegate(plan, "analytics-agent", "delete:reports:quarterly")
# result.status.value → 'checkpoint_required'
# result.receipt — signed denial, hash-chained, timestamped
Enter fullscreen mode Exit fullscreen mode 
$ bash VERIFY.sh evidence/
  Timestamps: 2 / 2 verified
  Signatures: 2 verified, 0 failed
  Flagged: 1 out-of-policy
Enter fullscreen mode Exit fullscreen mode

pip install agentmint — GitHub

If Your Compliance Evidence Can't Survive the Vendor Disappearing, It Was Never Evidence

AgentMint is open source. The receipts are yours. They verify with openssl alone and never expire — even if AgentMint does.

If you were affected by Delve or need compliance evidence that proves itself, I embed with your team and get this running in 2-3 weeks. You keep everything.

Book 15 min · DM me on LinkedIn

Built by Aniketh Maddipati. NYC. Runtime enforcement for AI agents.

Top comments (0)