Cybersecurity for AI Systems: A Practical Guide for Indian CISOs

A common CISO position in 2026 is that AI is just another application. The same WAF, the same network segmentation, the same IAM. Patch promptly, log everything, train the users, move on.

This position is comfortable and wrong. AI systems introduce a category of risk that traditional application security controls do not address.

Why Treating AI as Another Application Fails

Three properties of AI systems break the traditional security model.

1. The input is the program. In a web app, input is data and the program is fixed code. In an LLM system, input is part of the program. A malicious string in a retrieved document can redirect what the model does next.

2. The output is non-deterministic. Signature-based detection misses the long tail. The same input can produce different outputs. The attack surface is statistical, not structural.

3. The data flows are entangled. Retrieved documents, system prompts, tool definitions, and user input all mix into a single context window. There is no clean boundary between trusted and untrusted.

WAF inspects HTTP. A prompt injection payload is syntactically just text. IAM protects who can call the API, not what the model does once called. DLP scans for known patterns — it misses statistical exfiltration. Each control is necessary. None is sufficient.

The AI-Specific Attack Surface

1. Direct prompt injection. A user manipulates the model by overriding system instructions in their input.

2. Indirect prompt injection. The attacker plants malicious instructions inside a document, email, or webpage that the AI retrieves and summarises. The attacker never touches the application directly.

3. Data poisoning. Corrupting fine-tuning data, the RAG corpus, or user feedback to shift model behaviour over time.

4. Training-data exfiltration. Extracting memorised personal data, credentials, or confidential content from the model via carefully crafted queries.

5. Model theft via query-and-train cloning. Running thousands of queries to reconstruct a proprietary model's behaviour in a cheaper clone.

6. Agent tool abuse. A compromised model calling tools it should not — deleting records, sending emails, exfiltrating to external endpoints.

7. Supply chain compromise. Base models, embeddings, vector stores, and prompt templates are all third-party dependencies with their own attack surfaces.

8. Output-driven SSRF and code execution. The model becomes the attack vector for downstream systems that trust its output.

Controls That Actually Help

1. Separate trusted instructions from untrusted content explicitly in prompts. Never interpolate retrieved content into the system prompt.

2. Output filtering with a second model. A fast, cheap classifier on every output catches a class of attacks that input filtering misses.

3. Tool allowlists and capability gating. The model should not be able to call any tool it does not need for the specific task. Default deny.

4. Isolated, sandboxed tool execution. Tools run in environments with no access to production systems or credentials they do not need.

5. Model lineage and provenance. Know which model you are running, which checkpoint, which fine-tuning run. Treat model versions like software releases.

6. Audit logs for every inference, tamper-evident. Input, output, tool calls, retrieved documents, model version, timestamp. Queryable and immutable.

7. Rate limits and anomaly detection. Statistical exfiltration looks like normal usage individually but abnormal in aggregate.

8. Red-teaming as a quarterly practice. Automated adversarial probing plus human red-teamers who actually try to break the system.

9. Vendor model contracts. No-train clauses, data residency commitments, breach notification timelines, and audit rights — in writing before go-live.

10. Sensitive workloads on infrastructure you control. The most important control for high-risk data is not sending it to a third-party API in the first place.

The Indian Regulatory Overlay

Indian enterprises operating AI systems face a layered compliance environment that most security teams have not fully mapped yet.

DPDP Act 2023 applies to any AI system processing personal data. The penalty ceiling is Rs 250 crore per breach. AI inference logs, RAG corpora, and fine-tuning datasets all potentially constitute personal data processing.

CERT-In six-hour incident reporting applies to AI security incidents. A prompt injection that causes data exfiltration is a reportable incident. Most AI teams do not have an IR playbook that covers this.

RBI FREE-AI framework requires model lineage, continuous monitoring, and formal incident response for AI systems in BFSI. This is not advisory — it is supervisory expectation.

SEBI cyber resilience circular (April 2024) explicitly mentions AI and ML systems in scope. Market infrastructure institutions and regulated entities need to treat AI systems as critical infrastructure.

IRDAI has sectoral expectations on claims processing and underwriting AI, particularly around explainability and audit trails.

MeitY guidelines are voluntary today but are increasingly cited in government procurement requirements and are likely to harden over the next two years.

What This Means in Practice

Most Indian enterprises in 2026 have AI in production but do not have an AI security programme. They have application security controls applied to AI systems, which is not the same thing.

The gap shows up in three places:

Incident response — IR playbooks do not cover prompt injection, indirect injection, or agent tool abuse. When it happens, the response is improvised.

Vendor assessment — security reviews of AI vendors ask the same questions as SaaS reviews. Model-specific questions (training data controls, embedding confidentiality, prompt logging) are not asked.

Audit evidence — internal audit asks for logs, access controls, and patch records. AI-specific audit evidence (model versioning, inference logs, red-team reports, prompt change records) does not exist yet.

Building an AI security programme is not a rewrite of existing security. It is an extension — eight to ten additional controls, applied specifically to the AI layer, with the Indian regulatory requirements mapped explicitly.

CISOs treating AI security as an extension of existing controls will be a half-step behind on most categories of incident. Those treating it as a distinct discipline, with deliberate on-premise options where risk justifies, will be in a stronger position over the next three years.

To discuss private AI infrastructure and the security architecture around it, reach out to admin@setidure.com.