DEV Community: chinmay garg

Check an AI Agent's Identity, Owner and Consent Before It Reads Personal Data

chinmay garg — Sat, 14 Nov 2026 04:46:49 +0000

On November 13, 2026, India's Data Protection Board opened registration for Consent Managers under the DPDP Rules. The same week, the Linux Foundation launched Agent Name Service, and Zetrix AI with CAICT announced a Know Your Agent service. Both give AI agents a verifiable identity tied to an owner.

That is two registries. One answers "did this person agree?" The other answers "which agent is this, and who owns it?" When an agent asks your API for personal data, you need both answers in the same request. Nothing connects them today, so the check has to live in your code.

This post shows a small gate that does it. About 120 lines, one dependency.

What the gate checks

Before any personal data leaves the system, the gate asks five questions in order:

Is the credential genuine? A trusted issuer signed it, it has not expired, and it has not been revoked.
Who is it? The caller proves it holds the agent's private key by signing the request. A name in a header is not proof.
Who owns it? The credential names an accountable legal entity. No owner, no personal data.
What may it touch? The request's purpose is inside the agent's allowed purposes.
Under whose consent? The request carries a consent reference.

Every decision, allowed or refused, is written as one log line with the agent, owner, purpose and consent reference. Under DPDP, breach reporting starts on May 13, 2027, and that line is what you will need to write the report.

The code

Install the one dependency:

pip install cryptography

"""Check an AI agent's identity, owner and data scope before it reads personal data.

A minimal pattern, not a product. Requires: pip install cryptography
"""
import json
import time
from dataclasses import dataclass

from cryptography.exceptions import InvalidSignature
from cryptography.hazmat.primitives.asymmetric.ed25519 import (
    Ed25519PrivateKey,
    Ed25519PublicKey,
)
from cryptography.hazmat.primitives.serialization import Encoding, PublicFormat


def raw_public(key: Ed25519PublicKey) -> str:
    return key.public_bytes(Encoding.Raw, PublicFormat.Raw).hex()


def canonical(data: dict) -> bytes:
    return json.dumps(data, sort_keys=True, separators=(",", ":")).encode()


# 1. The issuer: whoever your company trusts to vouch for agents.
issuer_key = Ed25519PrivateKey.generate()
ISSUER_PUBLIC = issuer_key.public_key()


def issue_credential(agent_public: Ed25519PublicKey, claims: dict) -> dict:
    body = {**claims, "agent_public_key": raw_public(agent_public)}
    return {"body": body, "issuer_sig": issuer_key.sign(canonical(body)).hex()}


# 2. The gate: runs before any personal data leaves your system.
REVOKED_AGENTS = set()


@dataclass
class Decision:
    allowed: bool
    reason: str


def check_request(credential: dict, request: dict, request_sig: str) -> Decision:
    body = credential["body"]

    # Is the credential genuine?
    try:
        ISSUER_PUBLIC.verify(bytes.fromhex(credential["issuer_sig"]), canonical(body))
    except InvalidSignature:
        return Decision(False, "credential not signed by a trusted issuer")

    if body["agent_id"] in REVOKED_AGENTS:
        return Decision(False, "agent credential revoked")
    if body["expires_at"] < time.time():
        return Decision(False, "credential expired")

    # Who is it? The caller must prove it holds the agent's private key.
    agent_public = Ed25519PublicKey.from_public_bytes(
        bytes.fromhex(body["agent_public_key"])
    )
    try:
        agent_public.verify(bytes.fromhex(request_sig), canonical(request))
    except InvalidSignature:
        return Decision(False, "caller does not hold this agent's key")

    # Who owns it? No named legal owner, no personal data.
    if not body.get("owner_legal_entity"):
        return Decision(False, "no accountable legal owner")

    # What may it touch? Purpose and consent must match the request.
    if request["purpose"] not in body["allowed_purposes"]:
        return Decision(False, f"purpose '{request['purpose']}' not in scope")
    if not request.get("consent_ref"):
        return Decision(False, "no consent reference for this personal data")

    return Decision(True, f"{body['agent_id']} acting for {body['owner_legal_entity']}")


def audit(credential: dict, request: dict, decision: Decision) -> str:
    # One line per decision: which agent, which owner, which data, which consent.
    return json.dumps({
        "ts": int(time.time()),
        "agent_id": credential["body"]["agent_id"],
        "owner": credential["body"].get("owner_legal_entity"),
        "purpose": request["purpose"],
        "consent_ref": request.get("consent_ref"),
        "allowed": decision.allowed,
        "reason": decision.reason,
    })


if __name__ == "__main__":
    agent_key = Ed25519PrivateKey.generate()
    cred = issue_credential(agent_key.public_key(), {
        "agent_id": "support-agent-07",
        "owner_legal_entity": "Example Retail Pvt Ltd",
        "dpdp_role": "processor for a Data Fiduciary",
        "allowed_purposes": ["order_support"],
        "expires_at": time.time() + 3600,
    })

    def signed(req, key=agent_key):
        return req, key.sign(canonical(req)).hex()

    cases = {
        "valid request": signed({"purpose": "order_support", "consent_ref": "CM-2026-1188"}),
        "wrong purpose": signed({"purpose": "marketing", "consent_ref": "CM-2026-1188"}),
        "no consent": signed({"purpose": "order_support", "consent_ref": ""}),
        "impostor key": signed({"purpose": "order_support", "consent_ref": "CM-2026-1188"},
                               Ed25519PrivateKey.generate()),
    }
    for name, (req, sig) in cases.items():
        print(f"{name:14} -> {audit(cred, req, check_request(cred, req, sig))}")

    REVOKED_AGENTS.add("support-agent-07")
    req, sig = cases["valid request"]
    print(f"{'after revoke':14} -> {check_request(cred, req, sig).reason}")

Output

valid request  -> {"ts": 1794628987, "agent_id": "support-agent-07", "owner": "Example Retail Pvt Ltd", "purpose": "order_support", "consent_ref": "CM-2026-1188", "allowed": true, "reason": "support-agent-07 acting for Example Retail Pvt Ltd"}
wrong purpose  -> {"ts": 1794628987, "agent_id": "support-agent-07", "owner": "Example Retail Pvt Ltd", "purpose": "marketing", "consent_ref": "CM-2026-1188", "allowed": false, "reason": "purpose 'marketing' not in scope"}
no consent     -> {"ts": 1794628987, "agent_id": "support-agent-07", "owner": "Example Retail Pvt Ltd", "purpose": "order_support", "consent_ref": "", "allowed": false, "reason": "no consent reference for this personal data"}
impostor key   -> {"ts": 1794628987, "agent_id": "support-agent-07", "owner": "Example Retail Pvt Ltd", "purpose": "order_support", "consent_ref": "CM-2026-1188", "allowed": false, "reason": "caller does not hold this agent's key"}
after revoke   -> agent credential revoked

The impostor case is the one that matters most. It sends the right agent ID, the right purpose and a valid consent reference. It fails because it cannot sign with the agent's key. A system that trusts the agent ID string would have let it through.

Design notes

Why Ed25519. Keys are 32 bytes, signing is fast, and verification is cheap enough to run on every request. Latency matters here. If the gate adds noticeable time to each call, teams will route around it.

Why purpose and consent are separate checks. The purpose check is about the agent: is this job inside its mandate? The consent check is about the person: did they agree to this use? An agent can be allowed to do order support and still have no consent for a specific customer.

Why one log line. If identity lives in one system, consent in another and access logs in a third, an incident review becomes a join across three databases owned by three teams. Writing all four fields together at decision time removes that join.

What this sample leaves out

This is a teaching sample, not production code. Before using the pattern for real:

Add a nonce and timestamp to each signed request so a captured request cannot be replayed.
Store revocations somewhere shared, not in process memory.
Rotate the issuer key and support more than one issuer.
Look the consent reference up with whoever issued it, instead of only checking that it is present.
Send the audit lines to append-only storage. CERT-In's October advisory on AI agents asked for 180 days of logs.

Where the registries come in

Today the issuer in this sample is you. As agent registries mature, the issuer could be an external registry that checks the owner against company records. As Consent Managers get registered with the Board, the consent reference could point to one of them.

The gate stays the same. What changes is who you trust to sign the credential and where the consent lives.

How are you handling this today? Does your API know which agent is calling, or only which API key?

Agent Access Without Shared Passwords: A Scoped Grant Pattern for Banks and Fintech

chinmay garg — Tue, 27 Oct 2026 03:54:33 +0000

On October 22, Reuters and Axios reported that major US banks are restricting outside AI agents from customer accounts. As reported, customers share a username and password with an AI tool, the agent logs in, and the bank sees only the customer. Some agents tried actions the customer had not asked for. Most banks are moving towards read-only access for agents as a middle ground.

Read-only is a sensible stopgap. It is not a design. The underlying problem is that the bank cannot tell the agent from the person. This post sketches a small pattern that fixes that, with code I ran before writing this. It is a teaching sketch, not a product.

What is wrong with a shared login?

A password proves that an account holder exists. It does not say:

who is acting (the person or software),
on whose behalf,
for what purpose,
within what limits,
for how long.

Once the agent uses the customer's login, all of those answers collapse into one name. The log says "customer logged in" and nothing more.

The pattern in four rules

The agent has its own identity, separate from the customer.
The customer gives a grant: which agent, which actions, which limits, which expiry, and which company answers for it.
Anything that moves money needs an approval signed in the customer's own app, on a separate key. A field inside the agent's prompt is untrusted data.
Every log line names two actors: the agent that acted and the customer it acted for.

Step 1: helpers and signing

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

# Demo only. Production needs asymmetric keys held in a KMS or HSM.
BANK_KEY = b"bank-demo-key"
CUSTOMER_APP_KEY = b"customer-app-demo-key"  # separate channel, separate key


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 seal(payload: dict, key: bytes) -> str:
    body = b64(json.dumps(payload, sort_keys=True).encode())
    sig = b64(hmac.new(key, body.encode(), hashlib.sha256).digest())
    return f"{body}.{sig}"


def open_sealed(token: str, key: bytes) -> dict:
    body, sig = token.split(".")
    good = b64(hmac.new(key, body.encode(), hashlib.sha256).digest())
    if not hmac.compare_digest(sig, good):
        raise PermissionError("bad signature")
    payload = json.loads(unb64(body))
    if payload["exp"] < time.time():
        raise PermissionError("expired")
    return payload

Two keys are used on purpose. The bank signs grants. The customer's app signs approvals. The agent holds neither key.

Step 2: issue a grant and a customer approval

def issue_grant(customer_id, agent_id, operator, scopes, per_payment_limit, ttl=3600):
    """The customer's grant to one agent: scoped, capped, expiring, with a named operator."""
    return seal({
        "grant_id": str(uuid.uuid4()),
        "agent_id": agent_id,
        "on_behalf_of": customer_id,
        "operator": operator,
        "scopes": sorted(scopes),
        "per_payment_limit": per_payment_limit,
        "exp": int(time.time()) + ttl,
    }, BANK_KEY)


def customer_approval(grant_id, payee, amount, ttl=120):
    """Signed in the customer's own app, never typed into the agent's prompt."""
    return seal({"grant_id": grant_id, "payee": payee, "amount": amount,
                 "exp": int(time.time()) + ttl}, CUSTOMER_APP_KEY)

def customer_approval(grant_id, payee, amount, ttl=120):
    """Signed in the customer's own app, never typed into the agent's prompt."""
    return seal({"grant_id": grant_id, "payee": payee, "amount": amount,
                 "exp": int(time.time()) + ttl}, CUSTOMER_APP_KEY)

The approval is bound to one grant, one payee and one amount. It expires in two minutes.

Step 3: a gateway that decides and logs

class Gateway:
    def __init__(self):
        self.log = []
        self.revoked = set()

    def _record(self, g, action, ok, why):
        self.log.append({
            "actor": g.get("agent_id", "unverified"),
            "operator": g.get("operator", "unverified"),
            "on_behalf_of": g.get("on_behalf_of", "unknown"),
            "grant_id": g.get("grant_id", "none"),
            "action": action, "allowed": ok, "why": why,
        })
        return ok

    def handle(self, token, action, payee=None, amount=0, approval=None):
        try:
            g = open_sealed(token, BANK_KEY)
        except PermissionError as e:
            return self._record({}, action, False, str(e))
        if g["grant_id"] in self.revoked:
            return self._record(g, action, False, "revoked")
        if action not in g["scopes"]:
            return self._record(g, action, False, "out of scope")
        if action == "pay":
            if amount > g["per_payment_limit"]:
                return self._record(g, action, False, "over limit")
            if approval is None:
                return self._record(g, action, False, "no customer approval")
            try:
                a = open_sealed(approval, CUSTOMER_APP_KEY)
            except PermissionError:
                return self._record(g, action, False, "bad approval")
            if (a["grant_id"], a["payee"], a["amount"]) != (g["grant_id"], payee, amount):
                return self._record(g, action, False, "approval does not match")
        return self._record(g, action, True, "ok")

The order of checks matters. Signature and expiry come first, then revocation, then scope, then the payment limit, then the customer's approval. Denied calls are logged too, including forged tokens.

Running it

gw = Gateway()
grant = issue_grant("cust-1001", "budget-agent-3", "ExampleApp Pvt Ltd",
                    ["read:balance", "pay"], per_payment_limit=2000)
gid = open_sealed(grant, BANK_KEY)["grant_id"]

print(gw.handle(grant, "read:balance"))                                   # True
print(gw.handle(grant, "pay", "grocer-9", 800))                           # False
ok = customer_approval(gid, "grocer-9", 800)
print(gw.handle(grant, "pay", "grocer-9", 800, ok))                       # True
print(gw.handle(grant, "pay", "grocer-9", 900, ok))                       # False
print(gw.handle(grant, "pay", "grocer-9", 5000,
                customer_approval(gid, "grocer-9", 5000)))                # False
print(gw.handle(grant, "read:transactions"))                              # False
gw.revoked.add(gid)
print(gw.handle(grant, "read:balance"))                                   # False
print()
for e in gw.log:
    print(e["actor"], "for", e["on_behalf_of"], e["action"], e["allowed"], e["why"])

Output:

True
False
True
False
False
False
False

budget-agent-3 for cust-1001 read:balance True ok
budget-agent-3 for cust-1001 pay False no customer approval
budget-agent-3 for cust-1001 pay True ok
budget-agent-3 for cust-1001 pay False approval does not match
budget-agent-3 for cust-1001 pay False over limit
budget-agent-3 for cust-1001 read:transactions False out of scope
budget-agent-3 for cust-1001 read:balance False revoked

Reading the output line by line:

Reading the balance works, because the grant allows it.
A payment without a customer approval is refused.
A payment with a matching approval goes through.
Changing the amount after approval is refused, because the approval does not match.
A payment over the cap is refused even with an approval for that amount.
Reading transactions is refused, because the grant never included it.
After revocation, even the allowed read fails.

Where this stops being enough

Shared secrets. The demo uses HMAC. Anyone holding a key can mint tokens. Production needs asymmetric keys in a KMS or HSM so the gateway can verify but not issue.
First contact. The hard part is how a bank verifies an agent it has never seen. A grant tells the bank what the customer allowed. It does not tell the bank who stands behind the agent. A registry or a signed credential from a trusted issuer would have to fill that gap.
Operator identity. The operator field here is a plain string. It should be a verifiable legal entity.
Log integrity. The log is a Python list. Real systems need append-only storage with a tamper-evident chain.
Screen scraping. None of this helps if the agent can still log in with a password. The bank has to close that route, which is exactly why banks are blocking today.
Revocation latency. A revocation set in memory is not a distributed system. Short lifetimes reduce the damage but do not remove the problem.

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. The main duties apply on or about May 13, 2027. My reading is that these duties do not change when the visitor is software, so a record of who accessed a person's data, and on what basis, still matters. The grant above is a natural place to carry two more claims later: the consent or lawful basis the agent relies on, and the identity of the accountable company. I left them out because there is no agreed standard yet. This is not legal advice.

Questions for you

Do you issue a grant per agent, per task or per customer?
How should a bank verify the operator behind an agent it has never seen?
Should money movement always need a customer-side approval, or only above a threshold?

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

Sources: Axios (Oct 22, 2026); Reuters via Gulf News and Moneylife (Oct 22 to 23, 2026); TechCrunch on the CERT-In advisory (Oct 16, 2026).

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.