AI Security
If you build or work with large language models, you know the real threat isn’t mass unemployment or machines enslaving us. The threat is subtle and insidious, and we only know when it’s too late.
A recent security breach involving the Cline AI coding tool is a good example of this. In February 2026, a malicious GitHub issue title hijacked an automated triage agent, leading to a compromised npm package that affected developers and CI/CD systems for about 8 hours.
Could this have been avoided? Yes. As in most cases, the LLM was fooled, but the system around it wasn’t built to handle this vulnerability.
Build the system around the LLM so that nothing important breaks when the model is exposed.
Let’s go over some common attack surfaces and how we can avoid them.
Prompt injection.
Prompt injection occurs when an LLM processes input that changes the model’s behaviour in ways the developers did not intend. It tops the OWASP Top 10 for LLM Applications (LLM01)
To a large language model, input data and system instructions are the same(they’re both tokens). An attacker can embed malicious text within a webpage, emails, or documents.
I’ve seen this recently with job applicants who embed invisible text in their applications, instructing the LLM behind an applicant tracking system (ATS) to rate them a top-tier fit or push them to the next interview stage.
The defence is architectural. Build the system around the LLM, anticipating its instruction boundary will be bypassed. Limit which actions the model can perform, require human approval for sensitive ones, and restrict what its outputs can reach, so that a successful injection doesn’t become an exploit.
Sensitive information disclosure
Large language models are trained on vast amounts of data. Some of this data contains sensitive information such as PIIs, credentials, proprietary code, and trade secrets.
The LLM can inadvertently disclose this information in its outputs. The disclosure can occur at any stage of the LLM lifecycle.
In March 2023, ChatGPT inadvertently exposed payment PII for 1.2% of Plus subscribers due to a bug in the open-source redis-py client.
You can avoid this by enforcing least privilege across all integrations, limiting what your LLM can access, and using traditional data loss prevention layers to scrub sensitive information from LLM output and inputs.
Excessive Agency
When building AI agents, we give LLMs access to tools they use to accomplish tasks. These can include functions, third-party APIs, and database operations.
Excessive agency occurs when the agent can do more than the task requires, so a manipulated or simply mistaken model can cause real damage. OWASP (LLM03) breaks it into three root causes:
- Excessive functionality: the agent has tools it doesn’t need, such as a file-deletion function on an agent that only reads documents.
- Excessive permissions: the tools it needs run with more access than necessary, such as a read-only task using a database account that can also write and drop tables.
- Excessive autonomy: high-impact actions run without human check.
The core principle applies here too: assume the LLM vulnerabilities will be exposed and limit the damage. Give each agent the minimum tools it needs, minimize tool permissions, and require human approval for sensitive tasks.
Misinformation
LLMs can confidently produce incorrect, incomplete, or misleading information. The risk is when this output is acted upon.
LLM outputs determine which tools to call, generate code, trigger actions, and, in some cases, spawn other agents. Misinformation in this setting can lead to financial losses, service disruptions, and system-wide failures.
We can prevent this by authoritatively grounding sources, validating tool calls, introducing approval workflows, and running regular tests against misleading or ambiguous scenarios.
Final word
I wrote this from a developer’s point of view. I faced some of these challenges when building DocQA .
Credit to the amazing researchers at OWASP. They compile critical security risks facing AI systems.