Designing for Compromise: Lessons from an Ethical Hacking Incident at Adalat AI

Adalat AI is a nonprofit building speech and document tools to help courts deliver timely justice. This post describes findings reported by an ethical security researcher, the access they demonstrated, and the changes we are making in response. It also describes the document encryption architecture that helped protect our users’ information, and why we believe its underlying principles matter for anyone building systems in sensitive domains.

At around 6 am IST on Sep 8, 2026, Nisarga Adhikary, a cybersecurity researcher working at C3iHub, IIT Kanpur, brought us a detailed report showing how an exposed research service could be used to reach parts of our production infrastructure. The access was serious: the demonstrated permissions could have allowed an attacker to stop services, alter workloads, or destroy resources.

We have verified that no document contents or production audio from our court users were accessed in this incident. The exposed files were copies of publicly available petitions, judgments and hearing recordings, together with recordings made for our internal demonstrations. The permissions exposed in this incident could have been used to disrupt services. Those permissions did not, by themselves, provide the keys needed to decrypt stored court documents. Decryption depends on the authorized user’s client, so ordinary infrastructure administration does not give our team that access either. We explain this boundary, and its limits, below.

This distinction is what we mean by designing for compromise. Infrastructure access controls can be bypassed, so protecting sensitive documents requires a separate boundary around the ability to decrypt them. As agents become better at connecting security weaknesses, that separation becomes increasingly important.

Nisarga is a co-author of this account. We are grateful for his detailed investigation and for working with us on the response. We want this collaboration to help other teams building for public institutions and public services learn from this investigation and the protections that held. Code examples are redacted or illustrative.

Disclosure and collaboration

In their initial contact email, the researcher said he was contacting us privately under coordinated disclosure. He asked us to take urgent action within 24 hours, including rotating exposed credentials, patching or taking the vulnerable service offline, and restricting access to Kubernetes API servers.

We were surprised to see the summary of findings were made public later that day, while we were still working to establish contact and contain the incident. Our reply ran into an email-delivery problem, which the researcher later acknowledged publicly: his institute’s mail server had gone down. We subsequently spoke, compared the findings, and began working together on remediation. We want readers to note that no exploit was shared publicly in good faith, and by the time the summary was shared publicly, our team had patched the main entry to the vulnerability.

That conversation helped clarify both the provenance of the exposed data and the purpose of the Japan infrastructure. Publishing those corrections alongside the vulnerabilities matters. Courts and users deserve an accurate account, and other engineering teams should be able to learn from it.

What happened

Our infrastructure supports two kinds of work. A part of deployed services handle the speech and document workflows used by courts. A part of deployed services support model training, annotation, evaluation, and demonstrations of products still being developed. Both rely on software deployment tools, cloud identities, and storage. We are strengthening the separation between research environments and court-facing services.

The investigation began with an internal experimental machine-learning service that was reachable from the internet. It used a Caddy reverse proxy in front of a FastAPI/Starlette application served by uvicorn. A reverse proxy receives a request before passing it to the application. Here, the file-serving path allowed requests to reach files outside the directory the application was intended to expose. The host also contained an ML researcher’s home directory with Kubernetes configuration, cloud credentials, a source-control token, and other service settings.

Our researchers work on remote GPU machines, mounting their working files and using coding tools to run experiments. In this case, a researcher’s filesystem had been mounted on the exposed machine, making production credentials available there too. The findings showed why these workflows need tighter controls over credentials and access. We are tightening permissions, changing how credentials are handled, and separating experimental environments from production access.

Figure 1. The researcher-directed agent workflow. Parallel investigations fed into human review and follow-up tests. This is an illustrative reconstruction of the reported approach, not a trace of every agent action. The repositories shown here hold our software source code and configuration.

How the agents investigated

Nisarga describes the investigation as a swarm of agents: several agents pursuing different leads in parallel under human supervision. The security-focused framework is under development at C3iHub, IIT Kanpur, and combines custom post-trained and fine-tuned large language models with shell and browser tools. He reports running it on B300 GPUs on premises in India. The researcher directed the work, approved sensitive actions, and reviewed conclusions about access and impact.

The investigation started by finding public services and identifying the software they ran. Certificate-transparency records helped locate subdomains. One line of investigation followed the path-traversal vulnerability and the credentials it exposed. Other agents examined APIs, WebSockets, GraphQL, browser access controls, and guest identities in parallel. Each response informed the next test, and the outputs became evidence for the report.

The researcher reports testing hundreds of candidate file paths over an investigation completed in hours. We do not have a controlled comparison that would put a number on the speedup. The practical change is easier to see: a file exposes a credential, the credential identifies another service, and a permission check supplies the next lead. Several agents can follow those leads at once. A human still has to decide what the results prove and where testing should stop.

OpenAI’s account of the Hugging Face incident describes evaluation agents sharing discoveries through unauthorized channels, recovering credentials, and expanding access across systems. That was a different setting from this researcher-directed investigation. Unit 42 has also documented a human-directed intrusion in which agents pursued multiple parts of an enterprise environment.

What the finding establishes

The investigation uncovered previously unreported weaknesses in our deployment. Attributing them to a new zero-day in Caddy, uvicorn, or Starlette would require the affected versions and a minimal reproducer. Path traversal is an established class of vulnerability, and Starlette has had a historical advisory in this area. That advisory provides context; it does not establish the cause of this incident. Our immediate responsibility is to fix the demonstrated file-read path and the conditions that made it consequential.

Access to infrastructure

Reading files outside the application

The researcher attributes the file read to different interpretations of a request path by the proxy and the application. An encoded separator can become a directory separator when a later component decodes it. If the resulting path is not checked against the permitted directory, the request can reach another part of the filesystem. The report describes receiving actual host-file contents after increasing the traversal depth, rather than the application’s usual fallback response.

Figure 2. How the reported file-read path exposed credentials and widened access. The decoding sequence is an illustrative explanation of the researcher’s account; it is not evidence of a new upstream zero-day. The repository branch concerns application source code and configuration.

Listing 1. A simplified example of path interpretation. This is not a request to a live service.

The file-serving operation must check the resolved path against its allowed directory, regardless of how earlier components decode the request. The exact traversal depth still needs a reproducible explanation, so we have left it out of this example. The reported retrieval of files outside the permitted directory establishes the failure that needs to be addressed.

Kubernetes and cloud credentials

The exposed Kubernetes configuration referenced six clusters. The researcher reports reaching the API servers for three Azure Kubernetes Service (AKS) clusters and confirming unrestricted permissions. The three Google Kubernetes Engine (GKE) endpoints were not reached during this investigation. Those credentials still needed review and rotation even though that access path was not demonstrated.

The client certificate identified its holder as a member of system:masters. In Kubernetes, this is an emergency administrative group that bypasses the normal authorization layer. Its authority was sufficient to create serious risks to workloads, secrets, and service availability. The check demonstrated API permissions; it did not test operating-system access on every node.

The researcher also reports reading Kubernetes Secrets, validating cloud credentials, and accessing our software source code repositories. Some credentials were shared across staging and production, weakening the separation between them.

Understanding the impact

The exposed administrative permissions created a risk of disruption to production services and changes to workloads. The investigation also exposed credentials and our application source code. Compute abuse was a separate potential risk through services reachable from the compromised production clusters. The experimental research endpoint itself had no model or data loaded at the time, so its exposed routes did not establish an ability to alter training data or consume research compute.

Clarifications

After speaking with us, the researcher published a clarification distinguishing the public research data he had browsed from the compromised deployment, source-code, and DevOps infrastructure.

We have validated the provenance of the exposed files and verified that no confidential document contents or production audio from our court users were accessed in this incident.

The report also described “Full Infrastructure Compromise” and “Entire Database/Storage Access.” The infrastructure access and storage permissions, including the ability to copy or delete contents, were serious. Access to stored ciphertext is different from the ability to decrypt a court document. The exposed infrastructure credentials did not supply those document-decryption keys. Metadata, public research files, and encrypted court-document contents must be considered separately.

We understand why this was difficult to establish from outside. Public petitions, judgments, and hearing recordings contain real case names and can look like records held privately by a court. What matters is where the exposed copy came from and whether it was already public when we collected it.

1. The legal documents came from public sources. Our data team had collected copies of petitions and judgments already published online for model training and evaluation. The report named the WhatsApp LLC v. Union of India petition and the Abhijit Mishra v. UIDAI petition; it also listed the publicly available judgment in Dahiben v. Arvindbhai Kalyanji Bhanusali. These copies are not confidential files obtained through our institutional court deployments.

2. The 40 High Court records contained metadata. These records included case names, courts, case types, and page counts collected from public legal sources. The underlying PDFs were not available through those records. The separate document-download finding concerned our collection of legal documents downloaded from public websites.

3. The audio findings concerned research and demonstration material. Lawyers and linguists simulated legal dictation and courtroom interactions for an unlaunched product developed separately from our institutional court services. Our data team also collects hearing recordings and transcripts already published online to study legal vocabulary and exchanges between speakers. For example, our source collection pairs a Supreme Court YouTube recording of the Section 6A citizenship proceedings with the corresponding published transcript. These are examples of our public sources, not an identification of the specific audio clip accessed in this incident. Public hearing recordings and internal demonstrations are distinct from private audio supplied by users of our production court services. 

These distinctions matter to us and to the courts and users who rely on us. They do not excuse the infrastructure failures. We are responsible for securing research and demonstration systems too, and we appreciate the opportunity to work with the researcher on the fixes.

Document encryption

Our document architecture is built around a simple requirement: administering the systems that store a court document should not be enough to read it. We use end-to-end envelope encryption. Each document receives a random 256-bit AES-GCM document encryption key, or DEK, which encrypts its contents. Each authorized user receives a copy of that DEK encrypted to their RSA public key. The server stores the encrypted document and these wrapped keys.

The user’s RSA private key is itself stored encrypted. In the browser, the user’s password, a per-user salt, and PBKDF2-HMAC-SHA-256 with 100,000 iterations derive the key used to unlock it. The password and derived unlocking key remain in the browser. The private key is unwrapped into a non-extractable Web Crypto key handle retained in IndexedDB. Decryption therefore depends on the authorized user’s client, rather than a server administrator’s credentials.

Figure 3. Encryption and key custody for stored court documents. The browser is part of the trust boundary. Audio and transient model processing have separate data paths.

Listing 2. Simplified encryption pseudocode. Sharing, recovery, serialization, and algorithm parameters are omitted.

This separation is what protected stored court documents in this incident. Copying the stored ciphertext and obtaining infrastructure credentials did not give the researcher the document-decryption keys.

What encryption protects

This protection depends on the client as well as the cryptography. A non-extractable Web Crypto key cannot be exported through the API, but malicious code running in an unlocked browser session could still invoke decryption or read the result. Protecting the browser and the software delivered to it is therefore essential. The W3C explicitly identifies script injection as a risk to keys and data.

Zero-trust design does not mean that every component can be compromised without consequence. It means that document confidentiality does not rest solely on trusting the storage service or its administrators. An attacker who obtains an encrypted private-key record may still attempt password guesses offline, making password strength and key derivation important. Protecting client code, software delivery, and active sessions remains essential. The boundary demonstrated here is specific: the exposed infrastructure access did not itself provide the keys needed to read stored court documents.

Data sovereignty and our models

For our court deployments, sovereignty means retaining control over the models, the systems that run them, and the handling of court data. We develop and operate our own models, including models fine-tuned from open-weight foundations on publicly available data. This allows us to process court data without sending it to a third-party AI inference API. Cloud hosting and supporting software remain dependencies, and our descriptions of those services need to be clear about the information they receive.

Our published work includes Vividh-ASR and SCRIBE. Vividh-ASR describes a training approach that allows a smaller Whisper model to match or exceed larger, conventionally fine-tuned models in its evaluations. SCRIBE introduces diagnostic evaluation and releases rich-transcription models for Hindi, Malayalam, and Kannada. These papers explain how we develop and evaluate models for the languages and recording conditions our tools need to support. Their results are specific to the published evaluations.

Limited GPU availability in India has constrained the capacity we can procure, so we source compute across providers and regions and reserve Indian capacity for court-user inference. The resources identified in Japan were intended for training and experimentation with our own models. The researcher found no evidence that they processed sensitive court data. Our training uses publicly available data.

We are making every effort to secure reliable GPU capacity in India so that all our infrastructure, including model training and experimentation, can be based here. Even though training uses public data, we want those workloads to run in India too, as part of our long-term goal of complete sovereignty and operational independence. Finding sufficient, dependable GPU capacity in India remains a challenge, and we are continuing that search.

What's in a name?

A resource name containing “prod” had been read as a production inference service. In our environment, it referred to making a training workflow operational.

The researcher’s subsequent public clarification is explicit: he found GPU servers in Japan, but no evidence that they processed private or sensitive court data. We appreciate that correction. It is easy for an external investigator to encounter a resource name without the context needed to interpret it.

There is a lesson for us in that gap. Names should distinguish training, evaluation, and court-user inference, and our inventory should record the owner, region, permitted data, and purpose of each workload. A name is not a security boundary, but a clear one makes review and incident response less ambiguous.

For security researchers reading this, we would ask that resource names be treated as leads to investigate. Workload configuration, data flows, and discussion with maintainers are stronger evidence of what a system does. Establish a working contact channel and an explicit disclosure timeline, share enough evidence for the team to act, and give a responsive team a reasonable opportunity to contain the issue and check the conclusions. If a team does not engage or meet its commitments, escalation may be warranted. Teams, in turn, owe researchers timely responses and concrete progress.

Our response

Our first priority was to break the access path and revoke the credentials it exposed. We took the affected host out of service, reissued cluster credentials and client certificates, and restricted Kubernetes API access to authorized IP ranges. We also revoked the source-control token, reviewed organization-wide access, and removed standing credentials from development and experimentation hosts. Further remediation and independent retesting remain in progress.

We are also changing how internal services are deployed and granted access. Private networking and authentication should protect research services as well as deployed applications. Short-lived identities, scoped to a particular workload, should replace broad credentials stored on disk. Production and staging need separate credentials and permissions. These controls work together: a private network does not compensate for an identity that can administer unrelated systems.

For the original file-read issue, testing needs to cover the proxy and application together. A helper’s unit test cannot establish how the deployed system handles decoding, routing, and filesystem access. Tests must cover encoded paths, repeated decoding, and attempts to escape the allowed directory, alongside credential rotation and access restrictions. 

We are adding security training, recurring external testing, and clear ownership of threat modelling and release reviews. We are also preparing a formal disclosure program with a defined scope and response commitments. We are sorry that the initial report was difficult to get through to us. Researchers should be able to reach someone who can act on a report promptly.

Next steps

We are continuing this collaboration through remediation and a further round of testing. That work will revisit the original findings and check for related access paths that the first fixes might have missed.

An agent can follow a credential from an overlooked development service to the systems that matter most. Asset inventories, code reviews, and access policies must account for those connections. For sensitive services, stronger perimeter controls and zero-trust document protection have to work together: one limits the opportunities for intrusion, while the other limits what infrastructure access can reveal. Encryption does not keep a cluster online, so availability needs its own defenses.

We are grateful to Nisarga for the investigation and continued collaboration. Mozilla’s work with Anthropic offers another example of researchers and maintainers turning reproducible findings into validated fixes. Building for Indian public institutions also means investing in models, infrastructure, and security expertise that those institutions can understand and control.