AI agents are moving from answering questions to completing tasks: retrieving records, filling forms, checking eligibility and coordinating services. In India, that capability becomes especially valuable when connected to public digital infrastructure such as ABHA (Ayushman Bharat Health Account) and DigiLocker. However, an agent cannot safely access these systems merely because a user asks it to. It needs controlled tools, explicit permissions, strong identity verification and auditable workflows.
WebMCP—a browser-oriented protocol and tool-integration approach for exposing website actions to AI agents—could help bridge that gap. Instead of giving an agent unrestricted browser control, WebMCP can describe permitted actions, required inputs, authentication steps and expected outputs in a structured way. This article explains how WebMCP can be used to connect AI agents to ABHA and DigiLocker, the technical architecture involved, important limitations and practical guidance for Indian builders.
What WebMCP Means for AI Agents
WebMCP can be understood as a standardised layer between an AI agent and web-based services. It exposes selected website capabilities as machine-readable tools rather than requiring an agent to guess where to click or how to interpret a page.
A WebMCP-enabled service might expose operations such as:
- Search for a user’s available documents
- Request consent before accessing health information
- Initiate a verified login flow
- Fetch a document after authorisation
- Present a document for user confirmation
- Track the status of a service request
The important distinction is between tool access and account access. WebMCP should not give an agent raw credentials, session cookies or unrestricted control. It should provide narrowly scoped functions that enforce authentication, consent and policy at the service boundary.
For ABHA and DigiLocker, this matters because both involve highly sensitive personal data. A well-designed integration lets the agent assist with navigation and orchestration while the user retains control over identity, consent and final submission.
Why Connect AI Agents to ABHA and DigiLocker?
India’s digital public infrastructure is built to make services more portable and accessible. AI agents can add a conversational and workflow layer on top of these systems.
ABHA use cases
ABHA is designed to provide a unique health-account identity and help individuals link, manage and share health records through consent-based mechanisms. Potential AI-agent use cases include:
- Helping a user create or locate an ABHA address
- Explaining how a health record can be linked
- Finding records available for sharing
- Preparing a consent request in plain language
- Summarising retrieved clinical documents for the user
- Assisting with healthcare-service forms without making medical decisions
An agent must not treat ABHA data as ordinary profile information. Health data requires purpose limitation, minimum necessary access, clear consent and careful handling of generated summaries.
DigiLocker use cases
DigiLocker provides access to issued and uploaded digital documents. Agents could help users:
- Locate a driving licence, education certificate or vehicle document
- Explain which document is required for a government or private workflow
- Retrieve a document after user authentication
- Share a document with a relying party after confirmation
- Check document metadata and validity indicators
- Populate an application using user-approved fields
The agent should never silently download or share documents simply because it can access them. The user should see what will be shared, with whom, for what purpose and for how long.
A Reference Architecture for WebMCP, ABHA and DigiLocker
A production integration should separate the agent’s reasoning from identity, consent and data access controls. A practical architecture contains the following layers.
1. User interface and agent layer
The user interacts with an AI assistant through a chat, voice or application interface. The agent interprets the request, identifies the required workflow and proposes the next action.
For example, a user might say: “Use my DigiLocker degree certificate to complete this application.” The agent should translate that into a plan:
1. Identify the target application and required document.
2. Explain why the certificate is needed.
3. Ask for permission to open DigiLocker.
4. Trigger the authenticated DigiLocker flow.
5. Let the user select or confirm the certificate.
6. Share only the required document or fields.
7. Report completion and retain an audit reference.
2. WebMCP tool gateway
The tool gateway exposes approved operations to the agent. Each operation should have a strict schema, for example:
{
"name": "request_document_share",
"description": "Prepare a DigiLocker document share for user confirmation",
"inputSchema": {
"type": "object",
"properties": {
"documentId": { "type": "string" },
"recipient": { "type": "string" },
"purpose": { "type": "string" }
},
"required": ["documentId", "recipient", "purpose"]
},
"requiresUserConfirmation": true
}The gateway should validate every input, reject unexpected parameters and prevent the model from inventing document identifiers or recipients.
3. Identity and authentication layer
Authentication must happen through the official service flow, not through credentials supplied to the model. Depending on the service and approved integration model, this may involve OAuth-style authorisation, a government identity provider, a mobile OTP, a consent manager or an authenticated browser session.
Recommended controls include:
- Use short-lived access tokens.
- Keep refresh tokens outside the model context.
- Bind sessions to the authenticated user and device where possible.
- Use PKCE for public clients where applicable.
- Never place Aadhaar numbers, passwords, OTPs or private keys in prompts.
- Require step-up authentication for sensitive sharing or account changes.
4. Consent and policy engine
The policy engine determines whether an operation is permitted. It should evaluate the user, purpose, data category, recipient, requested fields, retention period and regulatory constraints.
For ABHA workflows, consent should be explicit, informed and purpose-specific. For DigiLocker, the user should authorise the exact document or data fields being shared. A generic instruction such as “handle my documents” is not an adequate substitute for transaction-level confirmation.
5. Official service adapters
Adapters connect the gateway to approved ABHA or DigiLocker interfaces. These adapters should use documented APIs, official SDKs or authorised integration channels—not page scraping or attempts to bypass controls.
The adapter should normalise service-specific responses into safe internal objects while preserving provenance. For example, a document result might include:
- Issuer
- Document type
- Document identifier or reference
- Issuance date
- Verification status
- Retrieval timestamp
- Share status
Sensitive document contents should be retrieved only when needed and should not automatically enter the model’s long-term memory.
6. Audit, monitoring and incident response
Every sensitive action should produce an audit event. Log who initiated the action, which tool was called, what purpose was declared, what consent was obtained, which service responded and whether data was shared.
Logs must be designed carefully: auditability does not justify storing full health records, identity numbers or document images indefinitely. Use redaction, encryption, access controls and defined retention schedules.
How an ABHA Workflow Could Work
Consider an agent helping a patient find and share a health record with a participating healthcare provider.
Step 1: Clarify the request
The agent asks what the user wants to share, with which provider and for what purpose. It should distinguish between viewing a record, summarising it locally and transmitting it to another party.
Step 2: Show the data scope
The agent presents the available record categories and explains the proposed date range. It should not request all records when one document is sufficient.
Step 3: Initiate official authentication
The user is redirected to the approved authentication and consent experience. The agent does not read or handle OTPs. After successful authorisation, the service returns a scoped result.
Step 4: Obtain consent
The user reviews the purpose, recipient, records and duration. The agent can explain technical language but must not pressure the user or misrepresent the consequences.
Step 5: Retrieve or transmit
The adapter retrieves the minimum necessary data or initiates an approved transfer. If the agent generates a summary, it should clearly label it as AI-generated and preserve access to the original record.
Step 6: Confirm completion
The user receives a transaction status, timestamp and reference. If the operation fails, the agent should explain whether the failure occurred at authentication, consent, retrieval or transmission.
How a DigiLocker Workflow Could Work
Suppose a user wants to submit an education certificate to a lending, employment or admissions application.
The agent can first inspect the application requirements without accessing DigiLocker. It can tell the user that an issued certificate is preferred and ask whether to open DigiLocker. Once authorised, the agent can show matching documents, including issuer and document type, and ask the user to select one.
Before sharing, the interface should display:
- The exact document or fields
- The receiving organisation
- The stated purpose
- Whether the recipient receives a copy, a verification response or a link
- Any expiry or revocation option
- Whether the application will retain the document
After confirmation, the tool performs the approved share operation and returns a verifiable status. The agent should not alter document contents, remove issuer metadata or claim that a document is valid unless the official service provides that status.
Security Risks and Mitigations
Connecting agents to public digital infrastructure creates risks that are different from ordinary chatbot deployments.
Prompt injection
Malicious text inside a document or webpage could instruct the agent to disclose data or call another tool. Treat all retrieved content as untrusted. Separate data from instructions, use allowlisted tools and require confirmation for external side effects.
Excessive agency
An agent may chain several low-risk actions into a high-risk outcome. Use transaction limits, approval checkpoints and policy evaluation at every sensitive step.
Confused-deputy attacks
A malicious website or recipient could cause the agent to use the user’s authority for an unintended purpose. Bind each token and tool call to a verified audience, declared purpose and specific transaction.
Data leakage through model context
Full medical records and identity documents should not be inserted into prompts unless necessary. Prefer structured extraction, field-level filtering and local processing. Disable training reuse and define retention rules for provider-managed model infrastructure.
Spoofed government interfaces
Users can be tricked by lookalike pages. Use verified domains, clear origin indicators and official redirect flows. Do not ask users to enter credentials into an agent-controlled form.
Incorrect interpretation
A language model can misunderstand a certificate, clinical note or consent notice. Present original sources, confidence indicators and human review for consequential decisions. Agents should assist with administration, not make eligibility, diagnosis, credit or legal determinations without appropriate controls.
India-Specific Compliance Considerations
A WebMCP integration involving ABHA or DigiLocker should be assessed under the Digital Personal Data Protection Act, 2023, applicable rules and sector-specific requirements. Healthcare use cases may also involve obligations under health-data policies, contractual requirements and the ecosystem’s technical standards.
Key implementation principles include:
- Define the data fiduciary and data processor roles.
- Establish a lawful purpose and provide clear notices.
- Collect only data necessary for the stated service.
- Support withdrawal of consent where applicable.
- Provide correction, grievance and deletion processes where applicable.
- Protect personal data with appropriate technical and organisational measures.
- Document cross-border processing and vendor access.
- Conduct security testing, threat modelling and incident-response exercises.
Compliance is not achieved by adding a consent checkbox. The entire workflow—from discovery and authentication to storage, sharing and deletion—must reflect the declared purpose.
Implementation Checklist for Founders
Before launching an AI agent connected to ABHA or DigiLocker, confirm that you have:
- An approved integration route and documented API terms
- A threat model covering prompt injection and account takeover
- Tool schemas with strict validation and least privilege
- Separate authentication, consent and agent layers
- No credentials, OTPs or private keys in model prompts
- User confirmation for retrieval and external sharing
- Field-level data minimisation
- Encryption in transit and at rest
- Token rotation and revocation
- Comprehensive but redacted audit logs
- Human escalation for ambiguous or high-impact cases
- Clear error handling and retry limits
- A retention and deletion policy
- Vendor and subprocessors due diligence
- Security, privacy and accessibility testing across Indian devices and networks
Where WebMCP Fits—and Where It Does Not
WebMCP can improve interoperability and make web workflows more discoverable to agents, but it is not an identity system, consent framework or compliance certificate. It cannot make an unofficial integration safe, and it cannot compensate for weak access controls at the application or API layer.
The strongest design uses WebMCP as a constrained orchestration interface. Official identity systems authenticate the user, ABHA or DigiLocker controls the underlying records, a policy engine governs access, and the agent helps the user understand and complete the workflow. This division of responsibility is more reliable than giving an agent broad browser automation privileges.
The Opportunity for Indian AI Startups
Indian founders can build valuable products around documentation, healthcare administration, education, finance and citizen services without attempting to replace public infrastructure. The opportunity lies in reducing friction: explaining requirements in Indian languages, preparing forms, detecting missing information, coordinating consent and helping users complete multi-step processes.
A strong product will treat trust as a feature. It will make every access request understandable, every transfer visible and every automated action reversible where possible. It will also design for users with limited bandwidth, shared devices, accessibility needs and different levels of digital literacy.
FAQ: WebMCP, ABHA and DigiLocker
Can WebMCP directly access ABHA or DigiLocker?
Not automatically. Access requires an official, authorised integration and a valid user-authentication and consent flow. WebMCP can expose approved actions to an agent, but it does not bypass service controls.
Should an AI agent store ABHA health records or DigiLocker documents?
Usually, it should store as little as possible. Retrieve only the minimum necessary data, avoid model-memory retention and apply encryption, access controls and defined deletion schedules.
Can an agent use OTPs supplied in chat?
No. Users should complete OTP and authentication steps in the official, trusted interface. OTPs and credentials should never be placed in prompts or agent logs.
Is browser automation enough for integration?
No. Browser automation can be fragile and vulnerable to phishing, layout changes and excessive permissions. Prefer documented APIs or authorised service integrations, with WebMCP exposing narrowly scoped actions.
What should founders build first?
Start with a low-risk, read-only workflow such as document discovery or requirement explanation. Add retrieval and sharing only after implementing consent, policy enforcement, auditability and security testing.
Apply for AI Grants India
Building a privacy-first AI agent for ABHA, DigiLocker or India’s wider digital public infrastructure? Apply to AI Grants India for support and opportunities designed for Indian AI founders.