Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

“Just let the LLM write the SQL.” It sounds powerful. A user types a question in plain English, the model generates a query, the system runs it against the database, and the answer comes back. No SQL knowledge required. No BI tools. No waiting for the data team. It works beautifully in demos. And it is a serious engineering mistake in production. Direct SQL generation from LLMs combines two things that should never be combined: untrusted code generation and privileged execution.

Every few weeks, a new story surfaces: an AI agent deletes a production database, an autonomous coding tool racks up a five-figure cloud bill, or a chatbot exfiltrates internal documents through a prompt injection attack. The reaction is predictable. “AI is dangerous.” “LLMs can’t be trusted.” “We need better guardrails on the model.” But if you look at the root cause of these incidents, the model is rarely the problem. The system around it is.

If your first instinct when connecting an LLM to enterprise systems via MCP is to strip out all personally identifiable information, you’re building a system that is useless. The “block all PII” approach sounds responsible. It checks a compliance box. But it fundamentally misunderstands what MCP-based AI systems do and why they need data in the first place. The real engineering challenge is not blocking data.

Zero Trust AI Access (ZTAI) is a security framework that applies “never trust, always verify” principles to every interaction involving AI systems, including LLMs and AI agents, as well as the sensitive data they process. Traditional zero trust was built to protect people accessing applications. ZTAI extends those same principles to a new category of actor: AI itself.

A prompt injection occurs when an attacker manipulates input to your AI system, overriding its instructions. To prevent prompt injection, you need a layered approach: separate system instructions from user input, validate user input before it reaches the model, monitor model outputs for anomalies, enforce least-privilege access for AI agents, and protect the data layer so sensitive information never reaches the model in a readable form. No single fix is enough.

Last week, OpenAI released Privacy Filter, an open-weight model for detecting and redacting PII in text. It is a thoughtful release: Apache 2.0 licensed, able to run locally, designed for high-throughput workflows, and built to go beyond regex-based detection. This is good news for everyone building enterprise AI. Privacy at the model layer is getting real attention. What we liked most was how clearly OpenAI described the role of the model.

Generative AI security is the practice of protecting the data that flows into AI systems, and the outputs those systems produce, from leaks, attacks, and unauthorized access. Every organization using AI today has the same blind spot. Sensitive data enters an AI pipeline, and most security teams have no visibility into where it goes next. An employee pastes a customer record into ChatGPT. A developer submits code containing API keys to an AI debugging tool.

Over two-thirds of enterprises are already running agentic AI in production, according to a 2025 industry survey on the state of agentic AI security. Fewer than one in four have the visibility to know what those agents are actually doing. That gap is live right now, in systems handling customer data, financial records, and protected health information.

The types of AI guardrails are input guardrails, output guardrails, security guardrails, ethical guardrails, and operational guardrails, each positioned at a different failure point across an inference pipeline. Gartner’s research found that 30% of generative AI projects don’t survive past the proof-of-concept stage, with weak risk controls cited as the leading reason. Most of those projects weren’t badly built. The models worked. The gaps were in what sat around them.

Every enterprise wants to use AI on its most valuable data — customer records, financial documents, clinical notes, legal files, engineering IP. The problem is simple: the moment that data enters an AI workflow, traditional security stops working. Firewalls protect the network. Encryption protects data at rest. Access controls protect the database. But none of them protect what happens when an AI agent retrieves five documents, synthesizes an answer, and delivers it to a user.