Can 'No Reverse Engineering' Clauses Block AI Vendor Audits in India?

Authored by Madhavan Thittai , Graduate, MNLU Mumbai.

Introduction

Indian organisations are increasingly relying on AI, SaaS, cloud, security, and compliance vendors to handle information-heavy workflows. A law firm may use an AI tool for research or document review; a bank may deploy fraud-detection software; a hospital may rely on a cloud records platform; an employer may use a monitoring or data-loss-prevention product. These systems may process client documents, employee records, financial information, credentials, audit logs, internal communications, and personal data. The customer organisation may remain responsible if that information is retained beyond contract, accessed by unauthorised personnel, routed through an unapproved environment, or used for an undisclosed purpose.

In the era of Generative AI and Large Language Models (LLMs), the complexity of these workflows has reached an unprecedented scale. These models do not merely store data; they transform it, often through "black box" processes that are opaque even to the developers themselves. As Indian enterprises integrate these tools into their core decision-making pipelines, the "trust but verify" model becomes strained. The difficulty is that the organisation may not be able to verify how the vendor system actually behaves. Vendor promises may appear in a master services agreement, data processing addendum, security schedule, privacy policy, product documentation, or questionnaire.

But the facts needed to verify those promises may lie in configuration logic, telemetry, server-side processing, support-access controls, logs, backups, or sub-processor arrangements that the customer cannot see. There is a growing "transparency gap" between what is promised in a PDF contract and what is executed in a server farm. For an Indian compliance officer, this gap represents a significant liability risk.

At the same time, the contract may contain a broad “no reverse engineering” clause. Such clauses serve a legitimate function. Vendors need to protect source code, algorithms, security architecture, technical documentation, confidential know-how, and trade secrets. Indian cyber law also rightly treats unauthorised access, copying, extraction, breach of confidentiality, and misuse of computer resources seriously under the Information Technology Act, 2000. The problem arises when a clause meant to prevent copying or misuse also blocks proportionate verification of security, retention, deletion, access-control, training-use, or data-transfer commitments.

India’s Digital Personal Data Protection Act, 2023 (DPDP Act) makes this issue more important. A Data Fiduciary remains responsible for compliance in respect of processing undertaken by it or on its behalf by a Data Processor, and must protect personal data through reasonable security safeguards. Significant Data Fiduciaries may also face additional governance obligations, including independent audit and periodic assessment requirements. These provisions do not create a right to inspect source code. Nor should they be read as doing so. But they show that Indian data governance is moving toward demonstrable accountability.

This blog poses the question: should “no reverse engineering” clauses block every form of technical verification in Indian enterprise AI and SaaS contracts? It argues that they should not. Indian organisations should not receive an unrestricted right to inspect proprietary software. But where a vendor handles organisational information assets, contracts should include a risk-based audit-escalation mechanism: documentation first, operational evidence next, independent expert review where necessary, and narrowly scoped technical inspection only as a last resort. In short, “no reverse engineering” should continue to mean no copying, cloning, hacking, or commercial misuse. It should not mean no verifiable accountability.

The Contractual Blindspot

Enterprise technology contracts often contain two sets of promises that sit uneasily together. On one side, the vendor promises security, confidentiality, limited use of customer data, breach notification, deletion, data-residency commitments, processor safeguards, access controls, and compliance with applicable law. These are often presented as "Standard Terms" or "Service Level Agreements" (SLAs) designed to provide the customer with a sense of legal certainty.

On the other side, the same contract may prohibit the customer from reverse engineering, decompiling, disassembling, testing, bypassing controls, benchmarking, or attempting to understand the underlying operation of the software. This structure is commercially understandable. A vendor’s software may embody source code, object code, algorithms, architecture, model design, proprietary weights in an AI context, and confidential technical documentation. A customer should not be able to use a service relationship as an excuse to clone a product, extract trade secrets, defeat access restrictions, or build a competing tool. A “no reverse engineering” clause therefore performs a legitimate protective function.

The difficulty is that these clauses are often drafted as absolute prohibitions, often stemming from legacy software-licensing templates that did not anticipate the highly interactive and data-dependent nature of modern SaaS. A typical clause may say that the customer shall not “reverse engineer, decompile, disassemble, derive source code from, modify, circumvent, or otherwise attempt to discover the underlying ideas, structure, sequence, organisation, or algorithms” of the software. Such language is useful against misuse, but it may also block responsible verification.

Furthermore, the rise of "Shadow AI"—where employees use unauthorized tools—makes the need for enterprise-sanctioned, auditable tools even more pressing. If an organization cannot audit its authorized vendors, it cannot effectively manage its data perimeter. The problem is not that every compliance concern requires reverse engineering. Most will not. A customer should ordinarily begin with less intrusive methods: vendor questionnaires, security schedules, data-processing terms, sub-processor lists, audit reports like SOC 2 or ISO/IEC 27001, certifications, logs, configuration evidence, breach reports, access-control records, and written explanations.

But where those materials are incomplete, inconsistent, or unable to answer a defined concern, the contract should not treat every deeper inquiry as equivalent to piracy or hacking. If the firm later discovers unexplained metadata transmission or inconsistent retention behaviour, the first step should be to seek clarification, logs, configuration evidence, and written assurance. But if those routes do not answer whether the commitment is actually being followed, the firm may need independent technical review. A blanket “no reverse engineering” clause could prevent even a confidential expert from verifying the limited issue.

Indian law already recognises that technical access and software misuse are not identical. The Copyright Act, 1957 permits limited acts relating to interoperability and observation, study, or testing of a computer program in specified circumstances. At the same time, the Information Technology Act addresses unauthorised access, copying, extraction, computer-related offences, breach of confidentiality, and disclosure in breach of lawful contract. The lesson for contract drafting is that the law should not collapse all technical inquiry into one category. A lawful, scoped, confidential audit is different from unauthorised intrusion or commercial appropriation.

Why Indian Law Makes Verification Important

The need for audit-escalation clauses becomes clearer once the Indian legal position is viewed from the perspective of organisational responsibility. Indian law does not yet contain a specific statutory right allowing a customer to reverse engineer vendor software for audit purposes. Nor should such a right be casually implied.

The first development is the Digital Personal Data Protection Act, 2023. The Act places obligations on a Data Fiduciary to comply with its provisions in respect of processing undertaken by it or on its behalf by a Data Processor. This is important for vendor relationships. Under Section 8 of the Act, the Fiduciary must ensure that the Processor provides sufficient guarantees. These "guarantees" are difficult to sustain in a vacuum of technical verification.

The second development is the statutory emphasis on security safeguards. The DPDP Act requires reasonable security safeguards to prevent personal-data breaches. The draft DPDP Rules give this obligation a more operational character by referring to measures such as access controls, visibility through logs, monitoring, review, backups, and contractual safeguards with processors. Where a vendor controls the relevant system, the customer may require more than a statement that safeguards exist. It may need records, logs, configuration evidence, or independent assessment.

The third development concerns Significant Data Fiduciaries (SDFs). Section 10 of the DPDP Act contemplates additional governance obligations, including the appointment of a Data Protection Officer and engagement of an independent data auditor. These requirements do not create a general entitlement to inspect software, but they do suggest that high-risk processing cannot be governed only through trust.

Indian constitutional privacy jurisprudence also supports this practical turn. In Justice K.S. Puttaswamy (Retd.) v. Union of India, the Supreme Court recognised privacy as connected to dignity, autonomy, liberty, and informational self-determination. Similarly, in District Registrar and Collector v. Canara Bank, the Court recognised that privacy interests may attach to information and records held by third parties. That principle is significant in modern vendor relationships, where information is often processed through service providers rather than entirely inside the customer’s own infrastructure.

This does not mean that Indian law should encourage intrusive technical inspection. The Information Technology Act, 2000 remains an important boundary. Unauthorised access, downloading, copying, extraction, and breach of confidentiality may attract statutory consequences. Any audit carve-out must therefore be carefully separated from hacking or data exfiltration. The point is not to weaken cyberlaw; it is to ensure that cyberlaw’s prohibition on unauthorised access does not make lawful, scoped, contractually supervised verification impossible.

Why Ordinary Vendor Assurances May Fail

Reverse engineering should not be the first response to vendor risk. In most enterprise AI and SaaS contracts, ordinary assurance tools—data-processing terms, security schedules, and certifications, should come first.

However, the "stochastic" nature of AI, its probabilistic output, means that traditional assurance often misses the mark. Unlike a standard database, an AI model's behavior can change based on the prompts it receives, leading to unexpected data leakage that a static SOC 2 report would not capture. This concern is especially visible in enterprise AI. A vendor may state that prompts are not used for training, yet the customer may still need to know how metadata is handled or whether sub-processors receive any part of the data flow. Global frameworks like the NIST AI Risk Management Framework emphasize the importance of "measurable" and "testable" AI systems.

Supplier-risk and AI-risk guidance both recognise that organisations must manage risks arising from vendors throughout the lifecycle of the technology. These frameworks support the practical point that vendor assurance cannot stop at contract signing. It must remain capable of escalation where a specific risk cannot be resolved through ordinary documentation.

Audit Escalation as Practical Answer

The contractual solution is not to remove “no reverse engineering” clauses. Vendors should remain protected against copying and competitive misuse. The better approach is to qualify the prohibition through a narrow audit-escalation clause.

Such a clause should operate in stages:

1. Ordinary Assurance: Data-processing terms, security schedules, and questionnaires.

2. Operational Evidence: Relevant logs, configuration evidence, and access-control records.

3. Independent Expert Review: Review by a trusted third party bound by confidentiality.

4. Narrowly Scoped Technical Inspection: A last resort for defined and credible concerns.

This staged approach avoids two extremes: it does not allow a customer to use "audit" as a pretext for corporate espionage, nor does it let a vendor hide behind a total bar on verification.

Boundary Against Misuse

An audit-escalation clause must be narrow because the risks on the vendor side are real. A customer should not be able to use an audit request to copy a product or bypass licensing restrictions.

The clause should draw a hard line between verification (asking if a commitment is being honoured) and misuse (seeking to obtain or compete). This boundary is consistent with the Information Technology Act, 2000, which addresses unauthorised access and breach of confidentiality. Organizations must also consider the OECD Recommendation on Digital Security Risk, which advocates for a collaborative approach to security. A well-drafted clause protects both sides: the customer receives a path to verify commitments, and the vendor receives protection against commercial appropriation.

Conclusion

Enterprise AI and SaaS contracts in India need a more precise approach to “no reverse engineering” clauses. Such clauses are legitimate when they prevent copying or cloning, but they become problematic when they operate as absolute barriers against verifying privacy and security commitments. 

The answer is not an unrestricted right to inspect software. Indian law already points toward a balance between the DPDP framework's emphasis on responsibility and the Information Technology Act's protections against misuse. Contract practice should now connect these strands through audit-escalation clauses. As India moves toward a more mature digital economy, the ability to audit the tools we use will define the level of safety we enjoy. In enterprise AI and SaaS relationships, “no reverse engineering” should continue to mean no misuse. It should not mean no verifiable assurance.