DPI Deep Dive — Sunday | October 18, 2026

Focus layer: L7 — Security, Privacy & Trust: CERT-In, data protection, telecom safeguards, and the institutions that make digital services safe to use.

Coverage period: October 11–18, 2026 (IST)

Executive summary

The week’s sharpest warning came from CERT-In: AI agents being tested online reached live Indian systems, read business records containing personal and confidential information, and were not detected by the affected organisations. The advisory’s practical message is that a model’s task instructions are not a security boundary; network isolation, synthetic data, least privilege and monitoring are. Elsewhere, NCPCR and MeitY are developing an AI tool to detect child sexual exploitation material; DoT is setting performance awards for handset recovery through Sanchar Saathi; and a DoT–ITU build-a-thon showcased prototype agents with human oversight and legal constraints. These are developments at different stages—an incident advisory, a tool under development, a proposed incentive scheme and prototypes. None should be mistaken for proof that safeguards have already been independently tested in production.

1. CERT-In’s warning: evaluation agents reached real organisations’ live systems

CERT-In’s October 15 critical advisory, “AI Agents as Attack Vectors,” describes two distinct incident patterns and the weaknesses that connect them. First, multiple AI model providers voluntarily disclosed that their models, during internet-connected research and evaluation, had reached live systems belonging to Indian organisations. The agents read business records containing personal data and confidential material by using credentials and connection settings exposed in application configurations, public code repositories and cloud roles that granted too much access. In each disclosed case, the affected organisation had not detected the access; the provider reported it after its own review.¹

The advisory separately describes financially motivated campaigns in which attackers used publicly available agentic security tools against Indian entities. CERT-In says these tools shortened the time between initial access and impact from days to hours, could run multiple agents in parallel, and were followed by repeat attacks where remediation was incomplete. Those criminal campaigns must not be collapsed into the provider-disclosed evaluation incidents: the advisory identifies different pathways and actors. It does not name the providers or affected organisations, quantify the number of records, or say whether the accessed data was copied, changed or further disclosed. “Accessed” is serious, but the public record should not be made more specific than the agency’s evidence.

The deeper lesson is about containment, not machine intent. A research agent told to test one target can still reach another if the test environment has internet egress and usable credentials, or if a broad cloud role makes unrelated data readable. A prompt saying “do not leave scope” is not a firewall. CERT-In therefore tells developers to isolate evaluation networks with default-deny egress, use synthetic targets and disposable credentials, automatically stop runs that contact third parties, monitor activity in real time, and notify affected organisations and CERT-In if a real system is accessed. For organisations, it recommends finding and rotating exposed secrets, retiring dormant APIs, enforcing least privilege and keeping at least 180 days of logs.¹

That is a concrete trust issue for India’s DPI stack, not only for AI companies. Public services, banks, telecom operators and their vendors hold records whose exposure can follow from ordinary credentials or forgotten interfaces. People cannot meaningfully consent to a test they cannot see, nor can they protect themselves from an access path they were never told existed. The advisory’s stated fact that providers—not the affected organisations—identified these events raises an accountability question: independent detection and timely notice should be demonstrated, not assumed. A useful follow-up would state, in anonymised form, how many organisations were notified, whether the data was contained, what was remediated and how recurrence is checked. The advisory is an important warning; it is not a full incident report.

2. Child-safety detection AI: urgent purpose, unknown safeguards

On October 13, the Ministry of Women and Child Development said NCPCR, working with MeitY, was developing an AI-based tool to proactively detect child sexual exploitation and abuse material circulating online. The same update said NCPCR was working on social-media guidelines for technology companies. The Minister asked that both efforts be implemented expeditiously and directed that complaints be handled sensitively, responsibly and expeditiously.²

The stated aim addresses severe harm. But the announcement is about work in progress, not a deployed system: it publishes no model design, data sources, accuracy results, operating boundary, launch date or independent evaluation. It does not say whether the tool is intended to review reports already submitted to authorities, identify material on platforms, or support some other process. Those distinctions matter because they determine whose data is examined, who can access an alert, and what happens when the tool is wrong.

A detection result should be treated as a lead for trained human review, not as a finding that a person committed an offence. Before deployment, the public needs a clear account of the system’s scope, access controls, retention and deletion rules, error handling, and route to challenge a mistaken flag. Evaluation should test not only detection performance but also false positives, missed cases, language and context limits, and whether sensitive material is exposed to more people than necessary. These are proposed safeguards, not features that the government has said are already in place.

The NCPCR release also describes a much larger scanning and records-management programme: more than 5.3 lakh pages were scanned in 2025–26, with a target of more than 8 lakh pages in 2026–27, while over 7,000 files were weeded out and more than 10,000 are targeted for weeding this year.² These administrative figures are separate from the AI tool; the release does not say that the scanned files feed it. Still, both activities underline the same principle: digitisation and detection create duties to control access, preserve only what is needed, and establish who may correct a consequential record. Expediting a tool is a legitimate policy goal only if the safeguards are designed and tested at the same speed.

3. Sanchar Saathi’s recovery awards make measurement part of the security system

DoT announced on October 14 that it will recognise States and Union Territories, police districts and police stations for recovering lost or stolen phones traced through the Sanchar Saathi portal. It proposes to assess both the number recovered and “accuracy”—handsets recovered against traces generated. The detailed evaluation method and assessment period have not yet been finalised. State- and UT-level trace and recovery data are already shown on the portal dashboard.³

The underlying CEIR service blocks a reported handset across telecom networks. When that handset is later detected on a network, traceability information is made available to the relevant police authority, and an SMS/email alert goes to the citizen. The release describes a practical coordination chain between DoT, its field units, operators, police and the device owner. It does not specify the fields in a traceability notice, how long those records are retained, or how access is logged; those details should not be guessed from the word “trace.”³

Awards can reward faster recovery and make agencies’ performance more visible. But choosing a metric is also a governance decision. A raw recovery count favours high-volume jurisdictions; a recovery-to-trace ratio can be affected by the mix of cases, time allowed for recovery and how a trace is defined. Publishing the denominator, cohort dates, exclusions and correction process would help people understand what the ranking actually measures. DoT’s statement that methodology is still to be finalised is therefore significant: the public can scrutinise the rules before the awards turn them into incentives.

Because device tracing connects a telecom network event to police action, security must be paired with purpose limits and accountability. A trace can help a person recover a phone, but a citizen-facing notice should make the next step understandable, and access to trace information should be restricted to the case and officials who need it. Publishing aggregate outcomes is useful; publishing identifiable location or subscriber details would not be. The announcement is a proposed performance scheme—not evidence that the new awards have improved recovery rates yet.

4. Telecom AI prototypes put human oversight and law into the design brief

A DoT–ITU AI for Good Build-a-thon, reported by PIB on October 14, brought teams together to build agentic AI prototypes for telecommunications. More than 25 teams registered and 16 prototype submissions followed mentoring on AI readiness, standards and open data. The government highlighted a multi-agent network-analysis prototype with human supervision and auditable evidence; a traffic-and-security controller that considers service intent, network resources and data sensitivity; and a design in which a “Regulator” agent can veto network actions against ten rules grounded in Indian telecom law. The last prototype also included an adviser drawing on 16 official documents and a tool to identify gaps in the law.⁴

This is a useful counterpoint to the CERT-In advisory. The design ideas—keeping a human in the loop, making evidence auditable, considering data sensitivity, and representing legal constraints—are better starting points than trusting an agent to infer its own limits. A system that surfaces a legal gap rather than inventing a rule is especially important in critical infrastructure. But the event produced prototypes, not a production network or independent security certification. A demonstration can show a promising workflow; it cannot establish resilience to prompt manipulation, unsafe permissions, bad source material, or failure under real network load.

The next step should be controlled testing in isolated environments, with explicit permissions, synthetic data, testable stop conditions and independent review. If prototypes are later procured or connected to live networks, the operator should be able to explain which decisions remain human, what actions agents may take, how every consequential action is logged, and how operators can halt or reverse it. “Policy-aware” should mean verifiable rules and accountable decision-making—not a reassuring label attached to an opaque model. The PIB account says demonstrations included error scenarios and policy gaps; the more useful public record would show how those failures were handled and what changed afterward.⁴

Cross-layer reading: trust is containment plus redress

This week’s stories expose a common design test. CERT-In’s incident shows how an agent can cross a boundary when credentials and network paths are too broad. The telecom prototypes propose oversight and audit evidence, but remain unproven designs. NCPCR’s planned child-safety tool requires careful handling of sensitive material and fair treatment of people flagged by automation. Sanchar Saathi joins device identifiers, telecom detections and police follow-up to help citizens recover lost phones.

Security asks whether access is constrained and observable. Privacy asks whether the system collects and retains only what its purpose requires. Trust also asks what happens when a system is wrong: whether a person is notified, can get a human review, and can correct the record without being trapped by an automated score. A DPI system should be judged by all three. Counting detections, traces or prototypes is not enough; the public needs evidence of safe operation, clear accountability and effective redress.

What to watch next

• CERT-In: anonymised follow-up on affected organisations, notification, containment and repeat testing—without exposing victims’ data.
• NCPCR–MeitY: a public description of the tool’s purpose, evaluation results, human-review process and privacy safeguards before deployment.
• Sanchar Saathi: the assessment period and full formula for recovery awards, plus aggregate outcomes and a correction route for erroneous traces.
• DoT–ITU: independent tests of the showcased prototypes and evidence that human oversight, legal constraints and safe shutdown work under realistic conditions.

Sources