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

Aniketh — Thu, 26 Mar 2026 12:31:10 +0000

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..."
}

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.

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

$ bash VERIFY.sh evidence/
  Timestamps: 2 / 2 verified
  Signatures: 2 verified, 0 failed
  Flagged: 1 out-of-policy

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.

Stop Letting Your AI Agent Forge Human Approval

Aniketh — Fri, 27 Feb 2026 01:07:36 +0000

2:47am. Your support agent issues a $500 refund. Compliance asks: "Who approved this?"

You check the logs. Valid OAuth token. Agent was authorized to access Stripe. But nothing says a human approved this specific refund.

That's the gap. Session auth proves capability. It doesn't prove approval.

I built AgentMint to close it.

How it works

Human clicks approve → AgentMint signs a token:

{
  "sub": "alice@company.com",
  "action": "refund:order:123:max:50",
  "exp": "60 seconds",
  "jti": "f1268944-..."
}

Agent includes token in the API call. Downstream verifies:

Signature valid? (Ed25519, can't forge)
Expired? (short-lived, can't hoard)
Already used? (JTI tracked, can't replay)

Passes → action executes, audit log updated.
Fails → blocked.

~3ms verification. Single-use. Cryptographic proof of who approved what, when.

Who needs this

Industry	Blocked action	Why they're stuck
Fintech	Refunds, credits	Can't prove human approved specific transaction
Healthcare	Record amendments	HIPAA audit trail requirements
Legal tech	Contract modifications	Need proof of attorney approval
DevOps	Prod deploys	Change management requires human sign-off

Common pattern: The agent works. Legal says no because there's no proof a human approved this specific action.

What this unlocks

Your support agent goes from "I can suggest a refund" to "I can issue the refund with Alice's signed approval attached."

Your deploy agent goes from "PR ready for review" to "Deployed to prod with engineer sign-off token verified by CI."

The agent gets write access. Compliance gets attribution. Everyone moves faster.

Does it scale?

Current prototype: single-node, in-memory JTI tracking.

Production path:

JTI store: Redis or DynamoDB with TTL expiry. Lookup stays ~15μs.
Keys: HSM-backed signing (CloudHSM, GCP HSM). Rotation with grace periods.
Throughput: ~300 req/s per instance at 3ms/verify. Horizontal scaling with shared JTI backend.

The primitives are simple. Scaling is standard distributed systems work.

SDK or proxy?

Two integration paths:

SDK approach: Agent calls agentmint.verify(token) before executing sensitive actions. Explicit, fine-grained control. You decide where verification happens.

Transparent proxy: AgentMint sits between agent and downstream API. Strips and verifies token from header, forwards request if valid. Zero agent code changes.

Current prototype supports both. Proxy is faster to adopt. SDK is more flexible.

MCP integration is next — verification as a tool server that agents call through the protocol.

Run it

git clone https://github.com/aniketh-maddipati/agentmint
cd agentmint
cargo run

~500 lines of Rust. Ed25519 signatures. Replay protection. Audit log.

If you're building agents that need write access and keep hitting the "legal won't sign off" wall, I want to hear what's blocking you.

Repo: github.com/aniketh-maddipati/agentmint

DEV Community: Aniketh