“Don't drink the water. They put something in it to make you forget. I don't even remember how I got here.” I’ve heard this quote for the first time over 20 years ago, and somehow it just stuck with me. Bonus points for anyone who can recognize where it came from, by the way!
Earlier this year, I wrote a blog post about privacy and data protection, where I complained about how the ongoing AI craze has undermined years of effort spent on teaching the public about the importance of privacy. Everyone has seemingly forgotten about it overnight, simply because of the convenience of an AI assistant. Well, when it comes to security, it appears that the AI-induced retrograde amnesia has affected not just the public, but many experts and vendors as well.
As the pressure from both regulatory compliance and malicious actors continues to grow, most people now agree, in general, that AI security is important, but what exactly does the term stand for? Whenever I’m reading another article on LinkedIn or listening to a vendor pitch, they would inevitably focus on securing the AI model development: you’ll hear about Data Poisoning, Model Inversion, Prompt Injection, and other terms that sound vaguely significant. Alternatively, they’ll be talking about using AI for securing AIs, and that secondary AI is almost always a black box that “just works, we promise”.
The real scope of AI security
Don’t get me wrong – all those risks are, in fact, real and critical for AI research companies that develop next-generation LLMs. But for an average business utilizing AI systems, the real risks lie in an entirely different area. Take agentic AI systems, which are the current fad in the industry. Such systems are comprised of multiple autonomous and loosely coupled agents that leverage large language models for complex reasoning, communicate with each other and with external systems over networks, and in the end solve complex multistep problems without human intervention. By the way, questions like “Who is accountable for their actions then” are a whole new can of worms I’d rather not open today...
These agents, just like their human predecessors, require access to existing business data to make the right decisions and to existing IT systems to perform actions. In most scenarios, these agents will be using AI models from third-party providers, but they will be interfacing directly with an organization’s existing IT, including identity providers, databases, document stores, or applications. Most of these interactions are powered by the same standards and protocols that have been in use for decades and, in fact, securing those interactions is a problem that has been solved by the cybersecurity industry many times over. And yet, many organizations either entirely ignore this history when rushing to deploy their AI systems or, even worse, turn to questionable half-baked solutions that had no way to prove their reliability or efficiency…
If you feel the pressure to prevent any potential sensitive data leaks, both from your organization to an untrusted LLM or from an AI tool to a malicious actor, do you really need an entirely new set of “AI guardrails”? Or can those guardrails be implemented by a combination of trusted and proven solutions like a database firewall, behavior analytics, and data leakage prevention?
If you’re designing a complex mesh of AI agents that interact with each other over RESTful APIs, do you really require anything new to keep them under control? What if you already have an API security solution in place, which uses the same technology and enforces the same policies on existing “dumb” API endpoints? But even if you don’t, why not choose a proven universal solution that can address not just agent-related risks, but strongly improve your overall security and compliance posture?
And if you absolutely need to make sure that your chatbot will never disclose a shameful secret from your past, why not just apply some basic data redaction policies at the network layer? It works for GDPR compliance, after all…
So, maybe let’s stop trying to reinvent the AI wheel? Trying to redesign the entirety of information security from scratch, ignoring the decades of successful solutions to essentially the same problems, inevitably produces an overcomplicated, expensive, and unpredictable result. ChatGPT seems to agree with that!
Adopt, adapt, and improve – a practical example
A couple of months ago, I attended Oracle’s annual Database Analyst Summit, which showcased their vision for AI and data integration. While many of the details remain under NDA, there is still plenty we can already talk about that illustrates exactly the point I’ve been trying to make: you don’t need to reinvent security for AI, you just need to expand the use of tools that already work.
Oracle’s converged database architecture is a good case in point. Unlike many fragmented solutions on the market, Oracle Database brings together all data types and workloads: relational, document, graph, spatial, and vector. What does this mean for AI? It means AI systems, including agentic architectures and LLM-based assistants, can interact with business data through a single, consistent, policy-enforced layer, without relying on a patchwork of disconnected tools that often bring more risk than they mitigate.
Rather than forcing organizations to extract and synchronize data across multiple platforms, they can run these workloads inside the database. You can apply models to sensitive business data without ever moving it outside the secure, audited, and access-controlled environment. Vector search and traditional SQL queries work together to find the most relevant content, which is then fed into the LLM — all within a tightly controlled database environment protected by capabilities such as row-level access control through the Virtual Private Database and Real Application Security features. This is not just a performance win; it's a security win.
Then there’s the SQL Firewall, a feature that deserves a lot more attention in today’s AI security conversations. While many vendors propose application-layer filters or “chat sanitizers” to catch malicious queries or data exposure risks, Oracle has put it directly into the database engine. The SQL Firewall is thus immune to bypass attempts and can transparently protect AI agents from SQL injections and other logic manipulation attacks, without requiring app developers to change their code.
Oracle Data Safe provides a unified control center for all these database security controls. From sensitive data discovery to masking, user risk profiling, and activity auditing, it can enforce any kind of security policies on any data, even the one that just happens to now be feeding or being accessed by an AI system. Whether it’s a human, a traditional app, or an AI agent that is working with your sensitive data — the underlying policies still ensure compliance with your organization’s data governance rules.
Conclusion
This was, of course, just a single example to illustrate the overall message: stop reinventing the AI security wheel. Instead, understand how exactly adding AI components to your existing IT environments changes the risk landscape and what additional gaps in security coverage emerge as the result. Then just shop around for a set of better wheels: a data protection one, an API security one, an identity governance one, etc. Or just go with tools that already work, such as those built into your Oracle Database. After all, would you rather have your security architecture resemble an 8-axle missile truck or a kid's bike with training wheels?
