Editor’s note: This article was originally published by Craig Riddell on LinkedIn. It has been republished here with the author’s permission.
Boards are giving AI security more airtime than ever. What they’re not giving is the right framing.
A year or two ago, AI was mostly a question of experimentation risk. Today, it’s tied directly to revenue, customer experience, operational efficiency, and competitive advantage. The urgency is real, and it’s translating into aggressive deployment timelines. But most board-level conversations still treat AI security as an extension of traditional cybersecurity. It isn’t.
The moment AI systems start taking actions across APIs, infrastructure, business workflows, and data stores, you’re no longer dealing with traditional risk models. You’re dealing with autonomous behavior operating at a scale no human team can supervise.
Most organizations and boards are still thinking about AI security through the lens of models and compliance. The real problem is operational governance: AI risk materializes through action, and those actions execute through APIs.
Here are the four myths I see most often in the boardroom, along with what boards should be asking instead.
Myth 1: Securing the Model Means Securing the System
The most common – and most dangerous – misconception I see is that if you secure the AI model, you’ve secured the AI system. And that just isn’t how AI works in production.
Every meaningful AI workflow is a chain of API calls, tool invocations, identity decisions, and data movements. The model is merely one link in the chain. To truly understand and mitigate risk, you must understand how those components interact over time.
Believing that secure models inherently result in secure systems means that many boards still grossly underestimate:
- The complexity of multi-step agent workflows.
- The exposure created by API integrations.
- The lack of visibility into what AI systems are actually doing.
Boards also forget that no attacker is required for an AI system to cause harm. AI systems can operate exactly as configured and still expose data, trigger the wrong workflow, misuse permissions, or take other unintended actions.
In short, that means poorly governed agents can have just as much – if not more – impact than malicious requests.
All of this leads to one fundamental failure: most organizations cannot confidently say what their AI system has done over the past 24 hours and, crucially, whether those actions should have been allowed.
Myth 2: APIs Are Just Infrastructure
APIs are more than just infrastructure; they’re the control plane for AI risk.
Transformative as they might be, AI systems do not invent a new execution layer; they merely amplify the importance of APIs. Every AI capability ultimately translates into API activity:
- Retrieving data
- Invoking tools
- Triggering workflows
- Modifying systems
- Interacting with infrastructure
- Making decisions across business processes
That means APIs are where AI intent translates to business action. The problem is that most enterprises built their security architectures around request-response traffic and human-driven interactions. They weren’t designed for autonomous, multi-step systems operating continuously at machine speed.
Most traditional security tooling still evaluates requests individually, using signatures, regex matching, or static inspection models. That approach doesn’t work for AI systems because the risk often doesn’t arise in a single request.
An individual API call, or even the next 10, might look legitimate. But together, they can create unintended actions, data exposure, privilege misuse, or business disruption.
That is why most organizations struggle to detect misuse and enforce meaningful controls in AI environments. They can see requests, but they can’t fully see what’s happening over time. And if you cannot see that acting, you cannot govern AI risk.
Myth 3: Agentic AI Fits Existing Security Models
Agentic AI – AI systems that can decide, execute, and adapt – fundamentally changes the risk model. Traditional tooling wasn’t designed for that. As such, boards must ask:
- What permissions do our AI agents actually have?
- How are those permissions enforced across multiple steps and systems?
- Can we observe and audit decision chains, not just individual requests?
- What prevents an agent from taking a technically valid but business-impacting action?
- What controls exist to stop unintended actions before execution?
And most boards aren’t asking those questions.
We’ve already seen agents expose data, delete information, trigger unintended workflows, or escalate actions in ways organizations did not anticipate. In many cases, the systems weren’t compromised. They were operating exactly as configured, just within poorly governed boundaries.
Traditional security models struggle here because nothing malicious happened at the request level. The problem was behavioral.
That’s why runtime governance is so important. Organizations must know what AI systems are doing as they act, enforce policy inline, and understand behavior across entire workflows.
If you cannot observe and control what agents do in real time, you’re relying on assumptions.
Myth 4: The EU AI Act is Just a Compliance Exercise
The EU AI Act moves into active enforcement in August 2026, and far too many boards are treating it as a documentation exercise. It’s much bigger than that. This is about operational accountability.
The EU AI Act — and the wave of comparable regulations following it — asks:
- Can you prove policies are being enforced?
- Can you show how AI systems behaved over time?
- Can you trace decisions and actions back to systems, identities, and workflows?
- Can you generate continuous, audit-ready evidence?
Static governance documents won’t answer those questions. A policy that says an AI system shouldn’t perform a certain action is only useful if you can prove you’re enforcing it in production.
The regulatory shift happening globally is not toward governance on paper. It’s toward demonstrable operational accountability. Organizations treating this as paperwork will fall behind quickly. The ones investing in visibility, enforcement, observability, and continuous evidence generation will be far better positioned — both operationally and in front of regulators.
What Boards Will Regret Delaying
For organizations moving from AI experimentation to operational deployment, there are a few capabilities I’d call non-negotiable over the next 12 months. These aren’t aspirational. The organizations delaying them are the ones that will find themselves reacting to incidents, struggling with governance, or scrambling to satisfy regulators after deployment has already scaled.
- Establish Visibility into AI Behavior: Understand what your AI systems are actually doing across APIs, tools, workflows, and data flows in real time.
- Treat AI Systems as Identities: AI agents should have defined permissions, boundaries, owners, and accountability, just like human users.
- Implement Inline Enforcement: Detection alone is not enough with autonomous systems operating at machine speed. Organizations need the ability to stop risky actions before they complete.
- Map AI-to-API Exposure: If you do not understand how AI systems interact with APIs, tools, and infrastructure, you do not understand your AI risk surface.
- Build Continuous Evidence Generation: Compliance today demands proof. Generate evidence continuously as part of normal operations, not after an incident or audit request.
Boards still think AI risks start with the model. In reality, risk begins the moment the model is allowed to act. If you don’t have visibility and control over behavior as it happens, you’re just making assumptions.
The future of AI security will not be determined by who has the smartest model. It will be determined by who can govern AI action at scale.
And increasingly, that control plane is the API layer.
