Integrating With Aadhaar-Based Auth Correctly

The SI drew a friendly box on the architecture slide: Aadhaar login. The box sat next to the large language model as if both were commodity connectors. In the next sprint someone logged full Aadhaar numbers in the prompt store so support could replay failed KYC. That store was the same disk that held embeddings. That disk was in the demo VLAN. That VLAN had a path to a hosted observability tool.

UIDAI, not your model vendor, governs Aadhaar authentication. The Aadhaar Act and the authentication regulations are not optional colour. The 2018 Constitution Bench judgment limited how Aadhaar may be demanded. DPDP adds another layer for digital personal data. None of those instruments asked you to put a twelve-digit number in a chat trace.

This guide is for the integrator who has to say no inside a sprint, and for the departmental owner who has to refuse a convenience feature. It is not an onboarding manual. It is not a substitute for UIDAI's live AUA/KUA papers. Read those papers. Then keep the agent off the identity path except where the service already has a lawful, notified use.

Authentication is not eKYC, and neither is a prompt

Authentication, in the UIDAI sense, is a request that returns a yes/no or a limited technical response that the person is who they claim, through an authorised path. eKYC, where permitted, returns specified demographic data and a photograph to a KYC User Agency. Those are different permissions, different onboarding, and different data classes.

An agent that asks the citizen to paste an Aadhaar number into a chat box is not doing Aadhaar. It is collecting an identity number outside the regulated pipe. An agent that stores the eKYC XML in a vector index so it can answer profile questions has created a parallel store UIDAI never approved as a CIDR replica.

If the department is not an AUA or KUA, and is not a lawful sub-AUA or sub-KUA under a live agreement, stop drawing the box. Convenience is not an onboarding letter.

Purpose limitation is the whole design

Aadhaar authentication is purpose-bound. You authenticate to deliver a specified service you are allowed to deliver that way. You do not authenticate so the model can know the citizen. You do not reuse an old eKYC packet for a new scheme because the XML is already on disk.

DPDP purpose limitation points the same way for personal data generally. Two statutes pointing the same way is not a reason to pick the weaker reading. Write the purpose on the workflow. If the purpose is personalisation, you do not have a purpose.

Puttaswamy (Aadhaar, 2018) is why you do not invent new mandatory Aadhaar uses because a chatbot UX is easier with a single identifier. If the service does not already have a lawful basis to demand Aadhaar, the agent does not get to demand it either.

Do not store Aadhaar in logs, traces, prompts or tickets

This is the sentence that should be on the wall of the SI war room. Do not store Aadhaar numbers in application logs, model traces, retrieval chunks, eval sets, screenshots, or helpdesk tickets. Do not store biometrics at all. UIDAI's ecosystem rules have long been hostile to storing PID and to casual copies of the number.

Use whatever reference UIDAI currently expects for your role — tokens, virtual IDs, hashed references as specified in the live regulations — and keep even those out of the LLM prompt unless the step truly needs them. Most agent steps do not. A scholarship drafting agent needs a file number and an eligibility circular, not a twelve-digit identity.

Redaction after the fact is a confession. Filter at intake. Reject prompts that look like Aadhaar-shaped strings. Test that rejection with a dummy number in staging. If the dummy appears in any outbound body, you have failed the week.

• No Aadhaar in system logs, access logs, or APM traces.
• No Aadhaar in the vector store, even for support replay.
• No Aadhaar in gold sets or vendor eval notebooks.
• No operator paste of eKYC XML into the chat to debug.
• No screenshot of the Aadhaar letter in the ticket.

Where the agent may sit relative to the AUA pipe

The regulated path is: userland application, then AUA or KUA or sub, then ASA or KSA, then CIDR. The agent is not a node on that path unless you have a written, UIDAI-compatible reason and the encryption, device, and operator controls that path already demands.

Safer pattern: the existing departmental application performs authentication or eKYC as it already does. It writes a purpose-limited internal reference into the case file. The agent sees the case file without the Aadhaar number. If a later step must re-authenticate, it returns to the regulated UI, not to the chat.

If a vendor proposes that the model calls Aadhaar as a tool, treat that as a high-severity design smell. Tools that reach identity systems need the same change control as a payment tool. Most departments should refuse the tool entirely.

Objections you will hear — and what to do with them

These are the lines that stall the file. Answer them in the room, then put the answer in the note.

We only store it hashed

A hash of a twelve-digit space is not magic. Purpose and permission still fail if you had no right to collect. Also, support staff will keep the raw number in the ticket beside the hash. Design for the ticket.

UIDAI allows eKYC, so the agent can read it

eKYC permission is not a licence to embed the XML for similarity search or to show it to a model host. Re-read your KUA terms and the purpose you declared.

The demo will not work without a real Aadhaar

Then the demo is wrong. Use the official sandbox or a stub that returns yes or no. Real residents are not a test fixture.

DPDP will cover us later

UIDAI duties apply now. DPDP commencement dates do not pause Aadhaar law. Do not store the number in the meantime as a convenience.

Four weeks to take Aadhaar out of the chat

1. Week 1: list every screen, prompt, log shipper and eval set. Search for Aadhaar-shaped fields and for the words eKYC, VID, PID, UID. Write owners.
2. Week 2: if the service has no live AUA/KUA or lawful sub path, remove Aadhaar from the agent UX. If it has a path, confine it to the existing widget and cut the chat paste.
3. Week 3: purge traces and tickets that already hold numbers. Record the purge. Rotate any key that sat on the same disk. Tell the DPO.
4. Week 4: add intake filters and a staging test that fails the build if a dummy Aadhaar leaves the box. Put the no-Aadhaar-in-logs line in the runbook the operator actually opens.

How this shows up in the file

Subject: Aadhaar authentication and eKYC — separation from agent logs and indexes.

UIDAI governs Aadhaar authentication. Authentication and eKYC are distinct permissions. This department will not treat a chatbot as an AUA. Aadhaar numbers, PID and eKYC XML will not be stored in model traces, vector indexes, eval sets or helpdesk tickets. Purpose limitation will be written per workflow.

Where authentication is lawful and already implemented, it will remain on the existing regulated path. The agent will see a purpose-limited case reference, not the identity number. This note is not legal advice and not a UIDAI filing.

Sub-AUA is not a shortcut for the model

A department that rides another organisation's AUA still inherits purpose, device, operator and logging duties. Putting the model in the middle does not make those duties lighter. If the parent AUA has not written the agent into the arrangement, you have invented a node.

Virtual ID and tokenisation, where UIDAI expects them, are for the regulated application. They are not a licence to keep a lookup table next to the embeddings so the bot can greet the citizen by house number. Greetings are not a purpose.

Prcept AI will not ship an Aadhaar tool in the agent runtime. We will refuse a connector that looks like CIDR. We will fail a staging test if a dummy twelve-digit string leaves the box. If that costs a demo, the demo was the risk.

This article is informational field guidance for Indian public institutions, not legal, procurement, security-accreditation, engineering or board advice. Confirm against the live Gazette, GFR, GeM term, CVC instruction, CERT-In direction, UIDAI regulation, DPE guideline, DPDP text, departmental charter, plant safety manual and your counsel before you file it.