Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

For much of security history, one metric dominated: recall. Recall means: of all the sensitive data that exists, how much did you catch? If there are 100 pieces of PII in a document and your system finds 95, your recall is 95 percent. This made sense in the old security world. If a firewall missed a real threat, the company had a serious problem. If it blocked something safe, someone could investigate and fix it.

In my last post, I explained the math behind cosine similarity. Cosine similarity is a powerful search technique. When you are dealing with thousands or millions of chunks, it provides a fast, scalable way to find content conceptually similar to the user’s question. That is a major breakthrough. Without vector search, modern RAG would be much harder to build. But the mistake is pushing every retrieval problem into vector search. That is where practical retrieval starts breaking down.

Cosine similarity is pure math. No magic. No understanding. Once you accept that, a lot of the confusion goes away. We talk to a lot of customers, and even seasoned engineers, who treat cosine similarity like magic that solves everything. Engineers talk about embeddings like they are definitive. Product teams trust similarity scores like they are facts. Vendors sell “semantic understanding” like the model actually understands. Truth is, it does not.

For any business now, data privacy is no longer a legal issue. Companies today collect massive amounts of customer information through AI tools, healthcare apps, SaaS platforms, analytics systems, and cloud services. This has led organizations to take global privacy laws more seriously. This is even more important when it comes to the concept of GDPR vs HIPAA compliance requirements.

There is no doubt that AI, or Artificial Intelligence, is rapidly changing how businesses are operating. However, it also brings new risks when it comes to data. As per industry reports, 72% of companies mention that there has been a significant increase in organizational cyber risks. It is therefore necessary to have a strong AI security architecture that helps to protect sensitive information. In light of this, 85% of organizations are now increasing their cybersecurity budget.

“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.