Craig Riddell, Global Field CISO at Wallarm – Interview Series

Craig Riddell, Global Field CISO at Wallarm, is a seasoned cybersecurity executive focused on helping enterprises manage the growing risks tied to APIs and AI-driven systems. In his current role, he works closely with CISOs, CIOs, and engineering leaders to translate real-world attack patterns and abuse scenarios into actionable security strategies, with a strong emphasis on observability—understanding how APIs and AI systems behave in production across users, applications, and integrations. His career spans leadership roles across identity and access management, zero trust architecture, and enterprise security at organizations including Netwrix, Kron, and HP, where he drove large-scale IAM transformations and modernized security frameworks. Riddell’s expertise centers on emerging threats such as business logic attacks, API abuse, AI system drift, and fraud, with a consistent focus on bridging the gap between high-level security strategy and operational execution.

Wallarm is a cybersecurity company specializing in protecting APIs, applications, and AI-driven systems in modern cloud environments. Its platform provides continuous discovery, testing, and real-time protection against threats such as API abuse, business logic attacks, and automated exploits, while offering deep visibility into how systems behave across complex infrastructures. Designed for multi-cloud and cloud-native architectures, Wallarm integrates into existing DevOps and security workflows, enabling organizations to detect and block attacks as they happen rather than after the fact. By combining API inventory, AI-driven threat detection, and automated response capabilities, the platform addresses a growing reality where APIs and AI systems have become the primary attack surface for modern digital businesses.

You started your career working directly with systems and infrastructure and have since moved into leadership roles focused on identity, access, API, and AI security. What key shifts along that journey led you to conclude that the real risk has moved away from the perimeter and into APIs and machine driven systems?

Early in my career, the focus was on protecting the edge. Firewalls, segmentation, hardening infrastructure. That model worked when systems were more static and trust boundaries were easier to define.

What changed is how applications are built and how systems interact. APIs became the connective tissue of everything, and AI accelerated that further. Now systems are making decisions, calling other systems, and executing actions at a scale and speed that doesn’t involve humans in the loop.

At that point, the perimeter becomes less relevant. The real risk moves to where decisions are made and actions are executed, inside APIs and machine-driven workflows.

If you don’t have visibility and control there, you’re trusting behavior you can’t fully see. That’s where business risk shows up, from financial exposure to unintended outcomes and operational disruption.

You have described the cyber handshake as broken, referring to how systems establish trust and exchange actions across increasingly complex chains of APIs and automated processes. What does that breakdown look like in a real world enterprise environment today?

In most environments, systems trust each other based on identity and authentication. A token is valid, a request is well-formed, and the interaction is allowed.

The problem is that this assumes valid equals safe. That’s no longer true.

We authenticate identity, but we don’t validate intent. We verify access, but not behavior across the chain.

A service may be authorized to call another service, which triggers downstream actions across multiple APIs. Each step looks legitimate in isolation, but across the full chain, you start to see unintended behavior or abuse of logic.

In AI-driven environments, this is amplified. Agents can chain actions and execute workflows without human review.

The handshake still happens, but no one is asking if the behavior makes sense in context. Trust is established but not continuously validated.

Why does AI and API risk so often fall between organizational boundaries instead of being clearly owned?

Because the systems don’t align with how organizations are structured.

DevOps owns delivery. Security owns policy. Business teams own outcomes. Data teams own models. Each group owns a piece, but no one owns the system as it behaves in production.

APIs execute business logic across systems. AI introduces non-deterministic decision making on top of that. Together, they cut across every boundary.

They are built by one team, secured by another, and consumed by a third, with inconsistent monitoring across all of them.

The gaps this creates are not failures of teams. They are failures of the operating model to reflect how modern systems actually work.

In your experience, which teams typically assume they own AI risk, and where do the biggest blind spots exist between security, DevOps, and business units?

Security teams tend to own AI risk from a governance and compliance perspective. DevOps owns deployment and reliability. Business units focus on outcomes.

The blind spots show up between those areas.

Security defines what should happen. DevOps ensures the system runs. The business focuses on results. But very few teams are consistently looking at what the system is actually doing in real time.

That gap is where risk lives, especially when behavior is technically valid but contextually wrong.

Many modern attacks appear as valid and authenticated behavior rather than obvious intrusions. How should organizations rethink detection in this new reality?

We need to move beyond identifying “bad” requests.

In many cases, the request is valid. The credentials are legitimate. The API call is expected. What is not expected is the sequence of actions, the volume, or the outcome.

Detection has to become behavioral and contextual. It’s less about blocking a single request and more about understanding how systems interact over time.

The approaches that actually hold up at scale move beyond pattern matching. They decompose requests structurally, treating each interaction as a set of behavioral tokens rather than trying to match against known-bad patterns.

That allows you to understand how behavior evolves and where it deviates, even when everything looks valid on the surface.

If you rely on static rules or signatures, you will miss most of what matters.

You have emphasized the importance of observability into real world behavior. What does meaningful observability look like for APIs and AI systems in production?

Meaningful observability is not just logs and metrics. It’s understanding behavior in context.

For APIs, that means full request and response visibility, how endpoints are used, and how interactions evolve over time.

For AI systems, it means understanding inputs, decisions, and resulting actions.

Most importantly, it means connecting those across systems into full workflows, not isolated events.

Without that, you’re operating on assumptions about system behavior instead of reality.

Why are traditional human review and approval models becoming less effective in machine driven environments?

Because the speed and scale have changed.

Systems are making thousands or millions of calls per minute, and attacks or unintended behavior can unfold in minutes or seconds. You can’t realistically put a human in the loop for each decision without breaking performance.

AI systems also aren’t always deterministic, which makes pre-approval models less effective.

Human oversight still matters, but it needs to shift from approving individual actions to defining guardrails and monitoring outcomes.

What are the most common operational gaps you see when companies try to secure AI systems using legacy security frameworks?

The biggest gap is over-reliance on design-time controls.

Organizations focus on securing models, reviewing code, and defining policies before deployment. That’s important, but it assumes systems will behave as expected once they’re live.

In reality, systems evolve. APIs change. AI models interact with new data and workflows. Behavior shifts over time.

Without continuous validation of behavior in production, organizations are effectively blind after deployment.

What does a practical operating model look like when multiple stakeholders share accountability for AI and API risk?

It starts with acknowledging no single team can own this end-to-end.

A practical model defines shared accountability, anchored around a common source of truth: runtime behavior.

Security defines risk and policy. Engineering builds and operates systems. The business defines acceptable outcomes.

The teams getting ahead of this operate in a closed loop. Continuous discovery, enforcement, and refinement driven by what systems are actually doing in production, not what was assumed at design time.

All stakeholders need visibility into how systems operate in production. From there, teams can align on what “good” looks like, detect deviations, and respond.

The shift is from siloed ownership to coordinated responsibility, grounded in runtime insight.

Looking ahead, do you expect security responsibility to become more centralized again, or will it continue to fragment as systems become more autonomous?

Responsibility will remain distributed because that reflects how systems are built.

What will change is how that responsibility is coordinated.

We’ll see more unified governance models where teams own their domains but operate with shared visibility and context.

The organizations that succeed won’t be the ones that try to centralize everything. They’ll be the ones that align stakeholders around how systems actually behave in the real world.

Because if no one understands runtime behavior, no one truly owns the risk.

Thank you for the great interview, readers who wish to learn more should visit Wallarm.