Our audit methodology
When Niji's cybersecurity teams audit an information system that embeds artificial intelligence, they rely on the best practices published by OWASP, in particular the LLM Top 10, a framework recognized across the cybersecurity community.
The audit is structured along several lines. First, a check of general information system security best practices: the OWASP Top Ten for web applications, ANSSI recommendations for internal audits. Then a specific analysis of how AI is integrated, in line with the requirements in the specifications and, where applicable, CLUSIF's AI security policy framework (PSSI-IA). Auditors look for the vulnerabilities and design flaws specific to these systems (data poisoning, model inversion, prompt injection, drift, information leaks) and issue operational recommendations along with secure development best practices.
What follows is a non-exhaustive selection of vulnerabilities our auditors found during recent engagements, as a concrete illustration of the risks addressed in our audits.
Prompt injection and system context exfiltration
In one of our audits of a conversational assistant, a single prompt was enough to force the model to reveal its system context:
The model returned the vendor's confidential instructions in full: business logic, behavioral constraints, sensitive data. This type of vulnerability corresponds to LLM01 – Prompt Injection in the OWASP LLM Top 10, and clearly illustrates the risks when there is no isolation between system instructions and user input.
Source code analysis with specialized agents & MCP vulnerabilities
When we have access to the source code, AI agents support the auditors in spotting vulnerabilities. This combined approach has notably allowed us to identify flaws in Model Context Protocol (MCP) integrations, an increasingly widespread protocol for connecting LLMs to external tools and services.
Remote code execution (RCE) via an MCP tool
On one of the platforms we audited, here is the attack chain we reconstructed:
By submitting an email address with the right domain, even for a nonexistent account, the authentication API issued a valid token without any SSO-side verification.
Once logged in, all it took was prompting the assistant to use a file-processing MCP tool, which opened up a server-side command execution vulnerability.
Protections blocking certain keywords were bypassed by splitting strings at runtime, for example "urllib.re" + "quest" to import a module without triggering the detection rules.
Code executed from the MCP context could reach an internal API hosted on the private network, with no inter-service authentication token to block the calls.
With a simple user token, our auditors retrieved MCP credentials, Active Directory group lists, LLM configurations and system prompts. With a high-privilege token, the scope widened further: dozens of system prompts containing classified internal data (HR, finance, legal, information security) and the full configuration of every assistant on the platform.
Five steps, zero complex exploits. Taken individually, each one seems minor: a verification bypass, a string concatenation, a missing inter-service token. Chained together, they opened access to classified HR, finance, legal and information security data across the entire platform.
Local file inclusion (LFI) via an MCP server
An MCP server exposed a function for retrieving the content of a web page from a URL. The problem lay in the application's behavior: when the HTTP request failed, the server automatically retried through a page rendering engine (Playwright-style). Our auditors exploited this behavior by passing a URL pointing to the local file system (file://), which was enough to list and read files on the machine hosting the MCP server, with no additional authentication.
What we recommend
These vulnerabilities stem from well-known causes. They combine classic application security flaws (authentication bypass, lack of network segmentation) with blind spots specific to agentic architectures: implicit trust in MCP tools, no strict validation of URL schemes, no isolation between system instructions and user input.
- Isolate system instructions from user input. A user prompt must never be able to surface the content of the system prompt or business instructions.
- Apply the principle of least privilege to MCP tokens. A user token must not open access to credentials, configurations or data shared across the entire platform.
- Authenticate inter-service calls. A pivot from an agent's context to an internal API must be blocked by a service token, not just by network position.
- Strictly validate the schemes and protocols accepted as input. A tool that fetches a URL must only accept
http(s), neverfile://, and never silently fall back to a rendering engine that bypasses controls.
Our conviction: auditing an AI is not auditing a separate scope, it is auditing an information system with new entry points. The foundation (authentication, network segmentation, least privilege) remains the first line of defense; AI-specific controls (prompt injection, data poisoning, drift) come next. Both layers are necessary.
