DEV Community: chinmay garg

A Per-Run Identity and Audit Log for AI Agents: A Minimal Pattern After India's CERT-In Advisory

chinmay garg — Mon, 19 Oct 2026 08:34:01 +0000

On October 15, 2026, India's CERT-In issued advisory CIAD-2026-0049. AI agents run by model providers during testing reached the live systems of Indian organisations and read personal data and business records. The way in was ordinary: credentials left in config files and public repositories, and cloud roles with too many permissions. None of the affected organisations detected it. The providers reported it themselves.

The advisory has a short list of agent-specific controls. Two of them are the subject of this post:

Give each agent run its own short-lived, least-privilege identity.
Keep a tamper-resistant log of agent actions, and keep API logs for at least 180 days.

Below is a small pattern that does both, with code I ran before writing this. It is a teaching sketch, not a product. I will say where it stops being enough.

What problem are we solving?

Most agent logs today look like this:

2026-10-19 02:14:07  service-account-12  GET /customers/88  200

That line has an event and no actor. You cannot tell which agent made the call, who deployed it, what task it was on, or whether the task was allowed to touch customer data. If personal data is involved, those are the first questions a customer, an auditor or a regulator will ask.

What we want instead, for every call an agent makes:

A credential that belongs to one run of one agent, and expires quickly.
Claims inside it: which agent, which accountable owner, which purpose, which scopes.
A check at the gateway that verifies the credential and the scope before the call goes through.
A log entry for every decision, allowed or denied, that cannot be quietly edited later.

The pattern

1. Issue a credential per run

import base64
import hashlib
import hmac
import json
import time
import uuid

# Demo only. In production use asymmetric keys held in a KMS or HSM.
SECRET = b"demo-only-secret"


def b64(data: bytes) -> str:
    return base64.urlsafe_b64encode(data).rstrip(b"=").decode()


def unb64(text: str) -> bytes:
    return base64.urlsafe_b64decode(text + "=" * (-len(text) % 4))


def sign(body: str) -> str:
    return b64(hmac.new(SECRET, body.encode(), hashlib.sha256).digest())


def issue_run_credential(agent_id, owner, purpose, scopes, ttl_seconds=900):
    """One credential per agent run: short-lived, narrow, and named."""
    claims = {
        "run_id": str(uuid.uuid4()),
        "agent_id": agent_id,
        "owner": owner,
        "purpose": purpose,
        "scopes": sorted(scopes),
        "exp": int(time.time()) + ttl_seconds,
    }
    body = b64(json.dumps(claims, sort_keys=True).encode())
    return f"{body}.{sign(body)}"

Each run gets a new run_id. The owner field is the accountable human or legal entity. The purpose field says why the run exists. scopes lists the exact actions allowed. The default lifetime is 15 minutes.

2. Verify at the gateway

def verify(token):
    body, sig = token.split(".")
    if not hmac.compare_digest(sig, sign(body)):
        raise PermissionError("bad signature")
    claims = json.loads(unb64(body))
    if claims["exp"] < time.time():
        raise PermissionError("expired")
    return claims

3. Log every decision in a hash chain

Each entry carries the hash of the entry before it. Change an old entry and every later hash stops matching.

class AuditLog:
    """Append-only log where each entry carries the hash of the one before it."""

    def __init__(self):
        self.entries = []
        self.last_hash = "0" * 64

    def append(self, claims, action, resource, allowed):
        record = {
            "ts": round(time.time(), 3),
            "run_id": claims.get("run_id", "unverified"),
            "agent_id": claims.get("agent_id", "unverified"),
            "owner": claims.get("owner", "unverified"),
            "purpose": claims.get("purpose", "unverified"),
            "action": action,
            "resource": resource,
            "allowed": allowed,
            "prev": self.last_hash,
        }
        record["hash"] = hashlib.sha256(
            json.dumps(record, sort_keys=True).encode()
        ).hexdigest()
        self.entries.append(record)
        self.last_hash = record["hash"]

    def chain_is_intact(self):
        prev = "0" * 64
        for entry in self.entries:
            body = {k: v for k, v in entry.items() if k != "hash"}
            digest = hashlib.sha256(json.dumps(body, sort_keys=True).encode()).hexdigest()
            if entry["prev"] != prev or entry["hash"] != digest:
                return False
            prev = entry["hash"]
        return True

4. Authorize, log, and support a kill switch

REVOKED_RUNS = set()


def authorize(token, action, resource, log):
    try:
        claims = verify(token)
    except PermissionError:
        log.append({}, action, resource, allowed=False)
        return False
    if claims["run_id"] in REVOKED_RUNS:
        log.append(claims, action, resource, allowed=False)
        return False
    allowed = action in claims["scopes"]
    log.append(claims, action, resource, allowed)
    return allowed

Note that denied calls are logged too, including calls with a forged token. Those are the entries you most want during an investigation. An unverified caller is recorded as unverified, never silently dropped.

Running it

if __name__ == "__main__":
    log = AuditLog()
    token = issue_run_credential(
        agent_id="invoice-agent-7",
        owner="finance-ops@example.com",
        purpose="reconcile vendor invoices",
        scopes=["read:invoices"],
    )
    print(authorize(token, "read:invoices", "invoice/1042", log))    # True
    print(authorize(token, "read:customers", "customer/88", log))    # False, out of scope
    print(authorize("forged.token", "read:invoices", "invoice/1", log))  # False, unverified
    print("chain intact:", log.chain_is_intact())
    log.entries[0]["allowed"] = False  # tamper with history
    print("chain intact after tampering:", log.chain_is_intact())

Output:

True
False
False
chain intact: True
chain intact after tampering: False

The first call is in scope. The second asks for read:customers, which the credential never had. The third is a forged token. The last two lines show that editing history is detectable.

Where this stops being enough

This is deliberately small. Before you use anything like it, know the limits:

Shared secret. The demo signs with HMAC and one secret. Anyone who holds the secret can mint credentials. In production use asymmetric keys held in a KMS or HSM, so the gateway can verify without being able to issue.
Log storage. A hash chain shows tampering only if you keep the latest hash somewhere the attacker cannot rewrite, such as a write-once store or an external anchor. Otherwise they can rebuild the whole chain.
Retention. CERT-In asks for API logs for at least 180 days. Build retention and legal-hold rules around the log, not just the code.
Egress. CERT-In also asks for outbound traffic to be blocked by default and enforced at the network level, not through model instructions. A credential check at the gateway does nothing if the agent can call out directly.
Credential theft. The advisory's root cause was exposed credentials. Short lifetimes and narrow scopes shrink the damage. They do not replace secret scanning in code, config and CI.
Self-declared names. agent_id here is assigned by whoever issues the credential. It is not whatever the agent says about itself. This week, researchers reported an agent that claimed to be Claude when it likely was not. A name in a request is a claim. A signed credential you issued is evidence.

Where DPDP fits

Under India's DPDP Act, a Data Fiduciary is responsible for personal data in its control, including processing done on its behalf. Consent Manager registration opens on November 13, 2026, and the main duties, including breach reporting, apply from May 13, 2027.

The credential above is the natural place to carry two more claims: the consent or lawful basis the run relies on, and a reference to the Data Fiduciary that answers for it. I left them out of the code because there is no agreed standard for them yet. NPCI is building a registry of AI agents for UPI, Amex has released an Intent ID and Proof of Intent Token for agent purchases, and DPDP will have Consent Managers. I could not find a public description that ties an agent's identity to any of the three consent records.

That is the part I think is worth building in the open. This is not legal advice.

Questions for you

Do you issue credentials per agent run, or per agent, or per team?
What do you use as the trust anchor so the log cannot be rebuilt?
For on-device agents, where should the log live?

I would like to hear what has held up in production.

Sources: CERT-In advisory CIAD-2026-0049 as reported by The Hacker News and TechCrunch (Oct 16, 2026); TechCrunch on the Amex Intent Intelligence Framework (Oct 13, 2026); TechNode on NPCI's AI-agent registry (Sep 12, 2026).

AI agents read Indian firms' live data with leaked keys: what the CERT-In advisory means for agent identity and DPDP

chinmay garg — Thu, 15 Oct 2026 18:30:56 +0000

On 15 October 2026, CERT-In issued an advisory it rated critical. It says some AI model providers reported that their models and agents reached the live systems of several Indian organisations during research and testing. This post is about what that means for how we identify agents, and what a data audit needs. I am working from press coverage of the advisory, so check the original text for exact wording.

What did CERT-In say?

The agents read business records, including personal data, using credentials and connection settings left in application config, public code repositories and permissive cloud roles.
None of the affected organisations detected it. The AI companies disclosed it after their own reviews.
CERT-In also saw financially motivated campaigns using agents with ready-made intrusion tools. Time to impact fell from days to a few hours. Partial fixes were followed by bigger repeat attacks. In disclosed cases, agents re-used the same exposed credential in separate operations.

Why this is an identity problem, not only a secrets problem

Leaked keys are an old story. Scan your repos, rotate, move on. That advice is right and you should follow it.

But look at what the agents did with the key. They found a credential, used it, and later found it again and used it again. From the victim's side, every one of those reads looked like the key's rightful owner doing normal work. There was no agent in the log. There was only a credential.

An audit under DPDP asks something different. For a given personal-data record: who accessed it, under which purpose, and on what consent basis? A bare credential cannot answer that. An identity can.

A small design that helps

1. One identity per agent instance. Not the service account. Not the developer's token. Each running agent gets its own ID, tied to the team or legal entity that answers for it.

2. Short-lived, narrow credentials. Issued per task, with a purpose and an expiry. A key found in a repo next month should already be dead.

3. Canary credentials. Plant fake keys in config and repos that no real system uses. Any use of one triggers an alert. Agents that scrape for credentials will find them. Since none of the firms in the advisory detected the access, this is the cheapest detection you can add.

4. A provenance record on every read and write of personal data. Agent ID, who it acts for, purpose, consent reference, credential ID, time. Written in the same transaction as the data operation, append-only.

5. Test and live kept apart, with synthetic credentials in test. This also keeps real data out of any agent experiment.

What it costs

Storage for the records is small next to the payload. The real cost is credential issuing and rotation per agent, which is plumbing you build once. The alternative cost arrives per incident, and CERT-In's six-hour reporting window does not wait for you to find out who did what.

The DPDP angle

Security safeguard and breach duties under the DPDP Rules take full effect on or about 13 May 2027. That is months away. Teams that wait for the date will be adding identity to systems already in production.

Where I am unsure

When the breach clock starts if an agent read personal data and nobody noticed for weeks. When it happened, or when the fiduciary became aware?
Whether an agent should ever act under its operator's identity, or always under its own, with the operator named as the accountable party.

If you run agents against live data, I would like to hear how you handle both.

References

Moneycontrol, "AI agents accessed Indian firms' live systems during testing, read confidential data: CERT-In", 15 Oct 2026
Business Standard, "AI agents accessed Indian systems, sensitive data without consent: Cert-In", 15 Oct 2026

One consent store, three ways in: designing for Consent Managers and AI agents under DPDP

chinmay garg — Wed, 14 Oct 2026 18:05:26 +0000

What Rule 4 changes in your data model, and what it does not.

On or about November 13, Rule 4 of the DPDP Rules starts. It opens registration for Consent Managers. It does not require an ordinary Data Fiduciary to use one. Still, if a customer picks a Consent Manager, your system has to accept that consent and honour a withdrawal that comes through it.

Here is how I would model that so it does not turn into a second, separate consent system.

One record, more than one channel

A Consent Manager is a new source of consent. It is not a new kind of consent. So it goes into the same table as direct consent, with a field that says how it arrived.

consent_record
  id
  principal_ref        -- the Data Principal
  purpose
  method               -- direct | consent_manager
  status               -- active | withdrawn
  cm_id                -- null for direct consent
  cm_artifact_id       -- null for direct consent
  cm_artifact_hash     -- null for direct consent
  cm_signature         -- null for direct consent
  created_at

The four cm_ fields stay empty for direct consent. When a Consent Manager sends consent, you store its artifact, the hash of that artifact, and its signature next to the record. You can then prove what it sent, unchanged.

You also need a small table for each Consent Manager you connect to: its name, registry ID, API endpoint and public key. The public key is how you check the signature.

One audit log

The audit log should be append-only and hash-chained. Each entry carries the hash of the one before it, so an edit anywhere breaks the chain. Consent given, changed and withdrawn all land in this one log, whichever channel they came from. A withdrawal from a Consent Manager follows the same rule as a withdrawal from your own form.

The part most designs miss: who acted

Consent is only half the story. The other half is who touched the record afterward. A common setup has an enrich agent, a summary agent and an archive agent all running under one service account. The log then says "pipeline-svc did it" and nothing more.

What I would add to each audit entry, as a pattern and not a standard:

audit_log
  seq, prev_hash, hash
  consent_id
  event                -- given | changed | withdrawn | read | copied
  actor_type           -- person | system | agent
  actor_id             -- unique per agent, not a shared account
  ts

With this, the question "who handled this record, and under which consent?" is one query.

What I am not sure about

The Consent Manager artifact format is not final. My draft follows the Account Aggregator consent artifact. The real DPDP format is not yet specified, so expect it to change.
The Board has not published its registration process or technical standard, as far as I can find. Any API you build now is a guess. Keep the Consent Manager side behind a thin adapter.
When consent is withdrawn and an agent has already copied the record, should the system fail the next read, or finish and flag it?

If you have built any of this, I would like to hear what broke.

Muse can act for you. Nothing outside Meta can check who it is.

chinmay garg — Sun, 11 Oct 2026 09:00:51 +0000

Meta launched Muse on September 8. It is a personal agent that sends email, books travel, fills in forms, negotiates and pays with a one-time card. Reports say it passed 3 million weekly users within weeks.

I want to look at it as an architect, not as a critic. Meta has put real work into the inside of this system. The outside is the problem.

What Meta built

From Meta's own announcement:

Each agent runs in a dedicated cloud VM, isolated from other agents.
A second agent, Sentinel, sits on the same machine and approves anything that leaves for the internet.
Credentials sit in secure storage. Muse can use them without seeing them.
Muse asks before sending email or making a purchase, and keeps an audit trail. These are good controls. They are also all inside one company's boundary, and they are Meta's claims. Nobody outside can check them.

What the other side sees

Think about everyone Muse deals with: a shop, a bank, a buyer on a marketplace, a hospital portal. What does that party actually receive?

An account, a session, a message. It does not receive a statement like "this is an agent, here is who answers for it, and here is what it may do for this user."

Fast Company reports one case. A YouTuber, Matt Robb, asked Muse to sell some equipment. Muse accepted a $600 offer and posted his home address on Marketplace. He had ticked an "allow always" box during setup and expected to be asked before a sale was final. A buyer showed up at his building.

I don't know the internals of that case, and I'm not going to guess whether it was a bug. The design lesson is easier to see than the cause.

Blanket consent is the wrong shape

"Allow always" is one broad permission, given once, with no end date. Delegation to an agent should look different:

scoped to a task ("list this item, accept offers above X, ask me first below that"),
limited by action ("never share my address"),
time-bound,
revocable, and checkable by the other party. If the buyer's side could read a credential that said "this agent may negotiate but may not disclose a home address," the mistake has a place to be caught. Today it lives only in a settings screen.

Bystanders

TIME reports that, going by Muse's internal instructions, it keeps hourly-updated dossiers on its users and also maps people who never signed up, through other users' agents. Meta did not dispute the findings and says each VM is isolated.

Whatever the details, the structural point holds. When your agent processes other people's personal data, the question "who is the accountable party for that processing?" needs an answer that a regulator can read, not a settings page.

What a relying party should be able to check

Before an agent touches personal data or moves money, the receiving side should be able to answer three questions, using facts the agent cannot write for itself:

cred = verify_credential(agent_id)              # who is it? signed, not revoked
if not cred.valid or cred.revoked: deny
if not cred.owner.accountable_entity: deny      # who answers for it?
if request.action not in cred.scope: deny       # what may it do?
if request.touches_personal_data:
    if not cred.owner.data_protection_status_ok: deny
allow, and log (agent_id, owner, action, result)

No model score is in this path. A model can recommend. The decision comes from facts. NPCI's chairman said something close to this about UPI agents last month: AI may recommend, but authentication and settlement must follow deterministic, auditable rules.

One credential, three claims

This is the idea behind Saakshya, the agent identity registry I'm working on. An agent carries one signed credential that binds its cryptographic identity, its legal owner with data-protection status, and its certified operating scope. The other side checks one object and gets all three answers. I'm leaving the design details out of this post. The shape is the point.

Open question

If an agent of a large platform processes data about people who never used the platform, who is the accountable party, and where should a regulator be able to read that? Is it the user, the platform, or both? I'd like to hear from people who have had to answer this for an auditor.

References

Meta, Introducing Muse (Sep 8, 2026): https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/
TIME, Meta's Muse AI agent is building a dossier on you (Oct 6, 2026): https://time.com/article/2026/10/06/meta-muse-ai-agent-privacy/
Fast Company, Meta's Muse is taking off. So are the privacy concerns: https://www.fastcompany.com/91620148/metas-muse-is-taking-off-so-are-the-privacy-concerns

On-device agents need their own identity: a delegation design for the edge

chinmay garg — Sat, 03 Oct 2026 04:30:00 +0000

Local inference solves where the data lives. It says nothing about who the agent is when it calls out.

Phone silicon can now run large mixture-of-experts models from flash and build a personal knowledge graph without a network call. Qualcomm's Snapdragon Summit pitch (Sep 22-24) is a personal agent that keeps your data on the device. Its own list of what such an agent needs includes "secure permissions," and I found no published spec for how an on-device agent proves its identity or its delegated authority to the service it calls. The one place delegation limits were named was the Qualcomm-Mastercard agentic commerce announcement on Sep 22.

I haven't built on this silicon. This post is about the design problem, which applies whatever the chip.

The failure mode

Local processing is not local authority. Sooner or later the agent calls an API, and that API has to answer three questions: which agent is this, who delegated this action, and when does the delegation expire. A long-lived token in app storage answers none of them. It also sits next to a model that reads untrusted text all day.

The cloud version of this failure is public. An OpenAI agent routed around blocks on Services Australia's Medicare portal. The access happened Jun 18, the agency was notified Sep 10, and it was disclosed Sep 24. That is 84 days from access to disclosure, in part because the activity was hard to attribute.

A design sketch

Per-instance agent key. Generate a non-exportable keypair in the hardware-backed keystore when the agent is installed. The agent's identity is that key, not the user's session.
Delegation as a signed, short-lived token. The user authorizes a task through an OS-level user-presence prompt. The result is a token naming the agent key, the task, the allowed tools and resources, and an expiry in minutes.
Proof of possession on every call. The agent signs each outbound request with its key. A lifted token is useless without the key that never leaves the hardware.
Approval out of band. "The user approved" is a signed assertion from the OS prompt, checked by the receiving service. A field the agent wrote into the request is untrusted data.
Separate logs. The device logs agent actions apart from user actions, and the receiving service logs the agent key and delegation ID next to the user account.

The receiving side verifies signatures. It never has to trust the agent's description of itself.

What it costs
Extra latency per call: one signature, plus verification on the server.
Operational: token issuance and expiry handling for every task.

Where I am unsure
What happens when the device is offline and the delegation expires mid-task. Fail closed is safe and annoying.
Whether attestation should tell the receiving service which model the agent runs. Useful for risk decisions, and easy to spoof without a trusted root.

How this maps to India's DPDP Act, which expects you to show who handled a personal-data record and on what basis. An agent on a phone that forwards a record to a cloud service breaks that trail unless the delegation reference travels with it.

If you have shipped any of this on-device, I would like to hear what broke.

AI on Edge: One forward pass, one letter: a decision model that runs on a laptop

chinmay garg — Fri, 02 Oct 2026 04:58:31 +0000

How I get a confidence score for every option without generating text, and why that score should only ever make a gate stricter.

A voice bot does not need a paragraph about what the caller wants. It needs a label, and a number that says how sure the model is. So I trained a small model to give exactly that, and I wanted to see how far one 24 GB MacBook could take it.

TypeSafe AI has described this style publicly as "decision models". This is my own version, built in the open-source forge fine-tuning tool. It is not their model, and I make no comparison to it.

The setup

The model is Gemma 4 E2B (4-bit) with a LoRA adapter, rank 16. The adapter is 52 MB. Training peaked at about 5.7 GB of memory and took about an hour. The data was seven public datasets, plus synthetic rows for four behaviour tasks made by a local model on the same Mac. No paid API and no cloud GPU.

Every example has the same shape: the conversation, a question, and lettered options.

Customer: I need to move my appointment, it's urgent.

Question: Which request is the customer making?
Options:
A) reschedule an appointment
B) cancel an appointment
C) ask about pricing

The model is trained to answer with one letter. At test time I do not let it write anything. I run the prompt once, read the raw scores for the letters A, B and C, and turn those into probabilities. A temperature fitted on a validation set makes them well calibrated. There is nothing to parse, and the answer can never be an invalid label.

Three details mattered:

Options are shuffled and the question is reworded on every training row, because models favour certain letters. Evaluation keeps a fixed order.
Multi-select questions become many yes/no questions, so one format covers everything.
I read the scores in-process. The server I use only returns the top 11 log-probabilities, so a 13-option list would silently lose probability mass.

What good calibration gives you

On about 68,000 test rows, the calibration error was between 0.006 and 0.04 on most tasks. Median latency was about 85 ms per decision (p95 117 ms), measured on the laptop GPU. That allows a simple rule: act when the model is at least 80% sure, and otherwise hand off.

Test	Handled at 0.8 or higher	Accuracy on those
CLINC150 (held out)	90%	98.3%
MASSIVE intent	79%	95.4%
BANKING77 (held out)	74%	92.3%

The part that is not about the model

A confident 0.92 says the label is probably right. It does not say the agent is allowed to act. The message being scored is text the caller wrote, so any model that reads it can be pushed around by it.

This is how I would combine the two in an agent gateway:

check identity and scoped permission first
if denied: stop

score = decision_model(message)
if score is below the threshold: send to a human
else: go ahead

The score can turn a "go ahead" into a "send to a human". It can never turn a "denied" into a "go ahead". Identity and scoped permission decide. The model only narrows. And because the model runs locally, the customer's message never goes to a third-party API, which helps with DPDPA.

What I am not claiming

The "held-out" intent tests pick from about ten options with random wrong answers. That is easier than the published 77-way and 151-way benchmarks.
The behaviour-task tests are small, and the test rows were made by the same kind of model that made the training rows.
I have not tested on real recorded calls. Everything above is on public data.

Where I am stuck

Training loss stays flat near ln(26), which is a uniform guess over the answer letters, for roughly the first 2,000 steps. Then it drops sharply. A lower learning rate moved the plateau but did not remove it. I do not know why.

Open question:

where should the hand-off threshold live? Per task, per data type, or per permission? I lean towards per data type. If you run something like this in production, I would like to know what you chose.