Cybersecurity threats from careless AI usage — and how local, isolated environments reduce the risk

AI tools are embedded in every developer's workflow. Paste the error, get the fix. Describe the feature, get the boilerplate. It is genuinely useful, and the speed gains are real. It is also a category of data exposure risk that most teams have not formally assessed. This post maps the threats as they exist in production — drawing on the OWASP Top 10 for LLMs 2025 and documented incidents — and explains which of them local, isolated inference addresses directly.

Threat 1: Proprietary code in cloud prompts

A 2025 industry report found that 77% of enterprise employees who use AI have pasted company data into a chatbot query, and 22% of those instances included confidential personal or financial data. Developers are a subset of this, but a high-risk one: they paste code containing business logic, database schema, internal API contracts and sometimes environment variables.

Each of those requests is a data transmission to a third-party server. Depending on the provider's current privacy policy and your subscription tier, the content may be logged, reviewed for safety, retained for a period, or used in training. Zero-retention tiers exist at most major providers, but they require explicit activation — they are not the default.

Threat 2: Credentials in context

API keys, database passwords and environment variables end up in prompts more often than teams acknowledge. The pattern: a developer copies 150 lines of code to explain a bug. Line 47 has a hardcoded credential that "will be moved to an env file later." That credential is now in a request log on a cloud provider's infrastructure.

The OWASP Top 10 for LLMs 2025 classifies this under LLM02: Sensitive Information Disclosure — which moved from #6 to #2 in the 2025 edition, reflecting how common the issue has become in production deployments. System prompts that contain connection strings or credentials are particularly high-risk: leakage of a system prompt enables attacks including privilege escalation and guardrail bypass.

Threat 3: PII flowing through AI APIs

A customer support workflow using an LLM to summarise tickets. Those tickets contain names, email addresses, complaint details, sometimes medical or financial information. Every summarisation request sends personally identifiable information to a third-party API. Under GDPR, this is a data transmission that requires a Data Processing Agreement with the AI provider, potentially a Transfer Impact Assessment if the provider processes data outside the EU, and in some contexts explicit user consent.

Most teams that have built these workflows have not completed that paperwork. The violation is not in the AI usage itself — it is in the data flow that was not mapped before the integration went live.

Threat 4: AI-generated code as an attack surface

LLM-generated code is not reviewed code. Research consistently shows that AI-generated code contains security vulnerabilities at a higher rate than human-reviewed code: SQL injection from unsanitised inputs, missing authentication checks, insecure defaults on cryptographic primitives, secrets committed directly to version control. If a team's workflow is "accept Copilot suggestion, run tests, merge," the test suite is unlikely to catch security issues that are architecturally correct but semantically dangerous.

SonarQube, Semgrep, and similar static analysis tools help here — but only if they are integrated into the CI pipeline and their findings are treated as blocking, not advisory.

Threat 5: Prompt injection in production systems (OWASP LLM01:2025)

Prompt injection is the #1 vulnerability in the OWASP Top 10 for LLMs 2025 — appearing in over 73% of production AI deployments assessed during security audits. The attack: an AI agent that reads external content (emails, user inputs, web pages, documents) can be instructed to take unintended actions through adversarial text embedded in that content.

A concrete example: an AI email assistant is instructed via a malicious email body to forward the user's inbox to an attacker-controlled address. The instruction is invisible to the user, written for the model. This is not a theoretical attack — working exploits have been demonstrated against production email and document-processing agents. In 2025, the first documented autonomous cyberattack campaign run entirely by AI agents was recorded, and OWASP released its first framework specifically for agentic AI security in response.

How local, isolated inference addresses these threats

Running AI models on infrastructure you control eliminates Threats 1, 2 and 3 entirely. There is no third-party request log. No training data exposure. No GDPR transmission to map. The inference happens inside your network boundary — the same boundary that already governs your database, your source code and your backups.

On our NVIDIA DGX Spark infrastructure, models like Qwen3.6-35B-A3B FP8 run fully on-premise. For client projects under NDA or with data sensitivity requirements, all AI inference — code review, document summarisation, generation — stays within the client's agreed infrastructure boundary. For tasks that do not touch sensitive data, we use cloud models. The split is deliberate and documented per project.

Practical security checklist

• Audit what data reaches AI prompts — run a pre-commit hook that flags hardcoded secrets and PII patterns before they can be pasted anywhere
• Activate zero-retention API tiers at cloud providers before any sensitive code touches those APIs
• Sign a Data Processing Agreement with every AI provider before PII enters their API — not after the integration is live
• Treat AI-generated code like third-party code: mandatory security review (automated + human) before merge, not optional
• For any AI agent that reads external content: implement strict input sanitisation, treat external content as untrusted, and never allow it to directly influence privileged actions
• Consider on-premise inference for anything touching proprietary algorithms, NDA-protected code, or data regulated under GDPR, HIPAA, or sector-specific rules

The bottom line

AI tools do not create new categories of security risk — they create new pathways to old ones. Data leakage, credential exposure, insecure code, and injection attacks all predate LLMs. What has changed is the surface area: AI is now involved in almost every stage of the software development lifecycle, which means the blast radius of a single insecure habit has grown significantly. The response is not to stop using AI. It is to treat AI integrations with the same rigour you would apply to any other external dependency that processes sensitive data.