With a distinguished career spent on the front lines of corporate cybersecurity, Malik Haidar has a unique vantage point on the evolving threat landscape. Now, he’s focused on a new and rapidly emerging frontier: the security of artificial intelligence systems. As businesses rush to adopt powerful new AI “skills” to automate complex operations, Haidar warns that they are inadvertently creating a dangerous new attack surface, one that mixes executable logic with sensitive data in ways traditional security tools are completely unprepared to handle. We sat down with him to discuss why these AI skills pose such a profound risk and what organizations can do to defend themselves.
AI skills, such as OpenAI’s GPT Actions, combine human expertise with executable instructions. What makes these skills so valuable for scaling business operations, and why does this combination of logic and data create such a dangerous new attack surface for enterprises?
That’s the fundamental paradox we’re facing. On one hand, the value is immense. Imagine capturing the nuanced decision-making process of your best financial trader or the entire workflow of a complex public service delivery system. These AI skills encapsulate that human expertise—the workflows, the operational constraints, all of it—into something executable. This allows organizations to scale knowledge and operations at a level we’ve never seen before. The problem, however, is that you’re creating a single artifact that combines a company’s secret sauce—its decision-making logic—with the data it operates on. It’s like writing the blueprints and the access codes on the same piece of paper. This fusion of executable logic and data creates a potent and dangerously ambiguous target for attackers.
An adversary with access to an AI skill’s operational logic could sabotage manufacturing or disrupt public services. Could you walk us through a hypothetical attack, explaining how an attacker might exploit this access and what kind of proprietary data or decision-making logic is most exposed?
Certainly. Let’s consider a manufacturing plant that uses an AI skill to manage its supply chain and assembly line processes. This skill contains the logic for ordering parts, scheduling machinery, and performing quality control checks. An attacker who gains access to this skill’s logic doesn’t even need to steal data outright to cause chaos. They could subtly alter the operational constraints, changing tolerance levels for a critical component or manipulating the ordering logic to create a massive parts shortage. The most exposed element here is the core business logic—the “how” of the operation. By manipulating that logic, the attacker could sabotage the entire manufacturing process, leading to defective products or a complete shutdown, all without tripping traditional data theft alarms. They are essentially hijacking the company’s operational brain.
AI-enabled Security Operations Centers (SOCs) appear to face acute risks from these new threats. Why are injection attacks a particularly severe challenge in these environments, and how does the design of AI skills create ambiguity that both defense tools and the AI engine itself struggle with?
AI-enabled SOCs are a perfect storm for this kind of threat because they are built on the very thing that makes AI skills vulnerable: the mixing of data and instructions. In a SOC, an AI skill might take an alert—which is user-supplied data—and combine it with instructions on how to investigate. An attacker can craft a malicious alert that contains hidden instructions. This is the essence of an injection attack. The AI engine looks at this incoming data and can’t safely differentiate between the genuine analyst’s instructions embedded in the skill and the attacker-supplied content masquerading as data. This ambiguity is the core of the problem. It paralyzes our defenses because even the AI itself is being tricked into executing malicious commands, potentially creating detection blind spots or even turning the defensive tool into an insider threat.
Many existing security tools are ill-equipped to analyze the unstructured text data that forms AI skills. What specific defensive gaps does this create for security teams, and how can practices like skills integrity monitoring or hunting for data flow anomalies help close them?
The biggest gap is visibility. Our traditional security tools are fantastic at analyzing structured code, network packets, and system logs. They are not built to understand the semantic nuances of human-readable text that also functions as executable instructions. This means a malicious change to an AI skill might just look like a minor text edit to a standard security tool, creating a massive blind spot. To close this gap, we need to shift our mindset. Instead of just looking for known malware signatures, we have to start monitoring the integrity of the skills themselves. This means establishing a baseline of what a skill should look like and what it should do, and then hunting for deviations. We need to be watching for anomalies in its execution, looking for unusual data flows, or monitoring for signs that the core SOC logic has been manipulated. It’s a move from static defense to active, continuous hunting within the AI environment itself.
You recommend separating skill logic from untrusted user data and applying least-privilege principles during design. Can you detail the practical steps a developer should take to implement these controls and explain how they would prevent an attacker from achieving lateral movement within the system?
This is about going back to security fundamentals and applying them to this new paradigm. First, a developer must treat the skill’s logic as sensitive intellectual property, completely isolated from any untrusted data it might process. Never allow user input to be directly concatenated with the core instructions. Instead, treat all user-supplied data as just that—data—and process it within a securely sandboxed environment. Second, when designing the skill, you must apply the principle of least privilege with extreme prejudice. If a skill only needs to read from one specific database, it should have read-only access to only that database. Its execution context should have the absolute minimum permissions required. By doing this, you build containment. Even if an attacker successfully exploits a vulnerability in that one skill, they’re trapped. They can’t use its permissions to access other systems, steal credentials, or move laterally across the network. You’ve effectively firewalled the breach at the source.
What is your forecast for the security of AI skills?
I foresee a rapid and sometimes painful maturation process. Right now, we’re in a gold rush phase where organizations are focused on capability and deployment, often leaving security as an afterthought. This will inevitably lead to a series of high-profile breaches that force a major shift in the industry. In the near future, securing the AI skill lifecycle will become just as critical as securing application code. We’ll see the rise of specialized tools designed to continuously monitor, log, and audit these AI environments, where traditional security boundaries are becoming increasingly blurred. The key takeaway is that we cannot simply bolt on security at the end. It must be woven into the fabric of how we design, test, and deploy these incredibly powerful AI skills from day one.
