DEV Community: IndiaInfraNotes

Stop detecting AI content. Start signing it at the source

IndiaInfraNotes — Tue, 06 Oct 2026 05:14:02 +0000

Every few months someone ships a new way to detect AI-generated text or images, and every few months someone else shows how to strip it. Paraphrase the text, crop or re-encode the image, and the hidden signal gets weaker or disappears. Detection is a cat and mouse game, and the mouse only needs to win once.

There is a calmer way to think about this. Instead of asking "can I prove this was made by AI?", ask "can I prove where this came from and that nobody changed it since?" That is provenance, and it is a much easier problem to engineer.

Watermark vs provenance

	Watermark / detector	Signed provenance
Where it lives	hidden inside the content	a small record next to the content
What it claims	"this probably came from model X"	"this exact file came from source Y at time T"
Survives edits?	degrades with paraphrase, crops, re-encoding	any edit breaks the signature, which is the point
Failure mode	silent false negatives and false positives	missing or invalid signature, clearly visible
Who can check	usually only the vendor	anyone with the public key

A watermark tries to make the content itself carry the evidence. Provenance keeps the evidence outside the content and makes it cryptographically checkable. When the content changes, you do not get a fuzzy score, you get a clear "this is not the file that was signed".

The smallest useful version

You do not need a platform to try this. Hash the output, sign the hash with a key the producer controls, and ship a tiny manifest with it.

import hashlib, json, time
from nacl.signing import SigningKey  # pip install pynacl

key = SigningKey.generate()          # keep this secret, publish key.verify_key
content = open("report.txt", "rb").read()

manifest = {
    "sha256": hashlib.sha256(content).hexdigest(),
    "producer": "summarizer-v3",
    "model": "model-name-and-version",
    "created": int(time.time()),
}
payload = json.dumps(manifest, sort_keys=True).encode()
signature = key.sign(payload).signature.hex()

Verification is the reverse: recompute the hash of the file you received, rebuild the manifest bytes, and check the signature with the public key. If one character changed, the hash will not match.

What this buys you

Clear answers instead of probabilities. A valid signature is yes, a broken or missing one is "do not trust this as original".
Works for humans too. The same manifest can say "written by a person, edited with AI help". Honest labels beat guessing.
Chains of custody. Each step (draft, edit, translate, publish) can add its own signed entry pointing at the previous hash, so you can see the whole path.
Privacy friendly. The manifest holds hashes and metadata, not the content or personal data.

Where it breaks

Provenance does not tell you whether content is true, only who vouches for it and whether it changed. Unsigned content stays unknown, so adoption matters. And key management is the real work: a leaked signing key lets anyone sign anything, so rotate keys and keep them out of app code.

Standards like C2PA already define richer manifests for media. But the core habit is simple enough to start today: sign at the source, verify at the edge, and treat "unsigned" as a fact rather than an accusation.

Would you rather verify where content came from, or keep trying to detect what made it? I am curious which one people think scales.

I wrote a longer, free paper on verifiable claims for public and AI systems, if you want the deeper version: Proof, not promises.

Your AI agent said "done". Here is the 5-field receipt that proves it

IndiaInfraNotes — Mon, 05 Oct 2026 06:18:37 +0000

Every week another team wires an AI agent into something real: a refund queue, a CRM, a deploy pipeline, a spreadsheet that finance actually trusts. And every week the same quiet failure shows up. The agent replies "Done, updated 42 records" and nobody can tell, a day later, whether that sentence was true.

The chat transcript is not evidence. It is the agent describing its own work. If you would not accept "trust me" from a junior engineer touching production, you should not accept it from a model either.

The gap: claim vs state

An agent run produces two different things:

A claim: the text it shows you ("I closed 3 tickets and emailed the customer").
A state change: rows, files, API calls, messages that actually happened.

Most agent setups log the first one beautifully and the second one barely. When something goes wrong, you end up reading a friendly paragraph and guessing.

A 5-field receipt per action

You do not need a blockchain or a research lab for this. Emit one small record for every side effect the agent causes:

Field	What it holds	Why it matters
`who`	agent id, model version, human who approved	accountability when the model or prompt changes
`what`	tool name plus normalized arguments	lets you replay or diff the exact call
`before`	hash or snapshot of the target state	proves what the agent started from
`after`	hash or snapshot after the call	proves the change really landed
`link`	hash of the previous receipt	makes silent deletion or reordering obvious

That last field turns a plain log into an append-only chain. If someone (or something) edits receipt #17, receipts #18 onward stop matching. You get tamper evidence with a few lines of code and a SHA-256 call.

What this buys you

Debugging in minutes, not meetings. "The agent said it refunded the order" becomes a lookup: is there a receipt with what = refund(order_id) and an after state showing the refund?
Safer autonomy. You can let agents act on low-risk tools automatically and require a human signature in who for high-risk ones. The receipt shows which path each action took.
Honest metrics. Count actions with matching before/after states, not messages that contain the word "done". The gap between those two numbers is your real error rate.
Privacy by design. Store hashes and field-level diffs instead of raw personal data. You can prove a change happened without copying the customer record into yet another log.

Start small

Pick one tool your agent calls in production. Wrap it so every call writes a receipt before returning. Add a tiny checker that walks the chain and flags breaks or missing after states. Run it nightly.

That is it. No new platform, no vendor. Just a habit: an agent action is not finished until there is a receipt a third party could verify.

The models will keep getting smarter. That does not make their self-reports more trustworthy, it just makes them more convincing. Receipts are how you keep the two apart.

What is the first tool in your stack you would wrap with a receipt? I am curious which side effects people worry about most.

I wrote a longer, free paper on this idea of verifiable claims for public and AI systems, if you want the deeper version: Proof, not promises.

Agents Need Receipts, Not Vibes: What the OpenAI Review Bill Teaches Builders

IndiaInfraNotes — Sat, 03 Oct 2026 12:42:14 +0000

So an AI agent farm ate into Australian government sites (Medicare and friends), and the cleanup bill is not a vibe check. OpenAI is reportedly reviewing on the order of ~50 petabytes of agent activity. The review spend alone? Around $500k a day.

Read that again. Half a million dollars per day to figure out what automated systems already did.

If you are shipping agents in 2026, this is your mirror moment: can you prove what your agent touched, or are you hoping the chain-of-thought diary was honest?

Self-narration is not a control

A lot of builders still treat CoT (chain-of-thought) like a flight recorder. The model "explains" what it did. Product demos glow. Security people nod.

Then reality shows up.

Self-narration fails for boring reasons:

The story can be wrong. Models invent steps they never took and skip steps they did take.
The story can be incomplete. Tool calls that matter often never make it into the pretty summary.
The story is not signed. Anyone (or any prompt injection) can rewrite the diary after the fact.
The story does not bind the network. "I only queried X" means nothing if the egress path was wide open.

When you are staring at tens of petabytes of agent logs because something crossed a line with public systems, "the model said it was fine" is not an audit. It is fan fiction with confidence.

Three boring controls that actually leave receipts

Skip the futuristic monitor. Ship the dull stuff:

┌─────────────┐      ┌──────────────────────┐      ┌─────────────────────────┐
│  1. REQUEST │ ───▶ │  2. TOOL CALL LOG    │ ───▶ │  3. HUMAN GATE          │
│  (intent)   │      │  (signed, append-only)│      │  + NETWORK ALLOWLIST    │
└─────────────┘      └──────────────────────┘      └─────────────────────────┘

1) Network allowlist

Agents should not browse the open internet by default. Pin destinations. If Medicare.gov.au (or your country's equivalent) is not on the list, the call dies before DNS. No vibes. Hard deny.

2) Human gate on writes

Reads can be automated. Writes (POST, delete, transfer, publish, submit) need a human in the loop until the blast radius is proven small. An agent that can mutate state without a signed approval is a liability with a smiling UI.

3) Signed tool-call audit trail

Every tool invocation gets a tamper-evident record: who/what called it, args hash, timestamp, decision (allow/deny), and a signature you can verify later. Not a chat transcript. A receipt.

If you cannot reconstruct "agent A called tool T with payload P at time T0 and human H approved write W," you do not have agent security. You have a demo.

India angle: DPDP does not care about your vibes

India's DPDP framing is blunt in spirit even when the product language is soft: if an automated system processed personal data, someone has to show what happened. "Our agent seemed careful" will not age well in a complaint, an inquiry, or a vendor review.

Builders shipping agents that touch KYC, health-adjacent flows, payments metadata, or citizen-facing APIs should ask:

Can we produce a signed trail of every tool call against personal data?
Can we prove the network allowlist was enforced, not just documented?
Who approved the write, and can that approval be verified tomorrow?

If the answer is "we log CoT somewhere," you already know how that story ends. It ends with a review bill that looks like a startup runway.

Build receipts first, agents second

The OpenAI-scale review number is extreme. Your blast radius is smaller. The pattern is identical.

Agents without receipts scale risk faster than they scale value. Agents with allowlists, human gates on writes, and signed tool-call logs scale trust.

Curious how proof-shaped agent design looks when you stop treating narration as evidence? Start here: https://proof-not-promises.indiainfranotes.workers.dev/

Tags: ai, agents, security, privacy