Walking the floor at Infosecurity Europe this week, it was impossible to avoid the subject of AI. Every conversation seemed to touch on it in some way. Vendors were demonstrating AI-powered detection capabilities, security teams were discussing governance frameworks, and practitioners were debating how best to secure the models, agents and data pipelines that are rapidly becoming part of everyday enterprise operations.
The level of innovation on display was impressive, and the attention being given to AI security is entirely justified. Yet after two days of discussions, demonstrations and meetings, I found myself returning to a much older question — one that appeared far less frequently than I expected.
What is the configuration state of the infrastructure these AI systems are running on?
Want to learn more about Secure Configuration & Audit-Ready Compliance? Download the Guide.
The Question Nobody Was Asking
That question may sound mundane compared to securing large language models or preventing sensitive data from leaking into AI workflows. But it goes to the heart of how security failures actually occur. AI workloads do not exist in isolation. They run on servers, cloud platforms, containers and virtual machines. They rely on service accounts, network policies, storage systems and OS configurations. Every one of those components has a security posture. Every one of them changes over time.
However sophisticated the AI layer becomes, it inherits the strengths and weaknesses of the infrastructure beneath it. An attacker presented with the choice between exploiting a complex AI workflow and walking in through an improperly configured server is not going to choose the harder option.
An attacker presented with the choice between exploiting a complex AI workflow and walking in through a misconfigured server is not going to choose the harder option.
AI Deployment Is Creating New Infrastructure Debt
The speed at which organisations are deploying AI is making this worse. Development teams are under pressure to move fast, deliver new functionality and demonstrate ROI. Under those conditions, infrastructure accumulates technical debt in predictable ways:
- Prototype environments: become production systems before anyone has run a hardening review.
- Temporary permissions: become permanent because nobody scheduled the follow-up.
- Compute resources: are provisioned rapidly and reviewed later, if they are reviewed at all.
- Base images: get reused long after anyone assessed whether their configurations are still appropriate.
- Service accounts: are created with broad access to get things working quickly and never scoped back down.
None of these patterns are unique to AI. But AI is creating more infrastructure, more identities and more interconnected systems than previous technology cycles. That means more surface area for misconfiguration to develop unnoticed.
Misconfiguration Is Not a Static Problem
This is where a lot of security programmes get stuck. Configuration is treated as something that can be fixed, documented and revisited at the next audit. Modern environments do not work that way.
They are in constant change. Systems are patched. Workloads are migrated. New services are introduced. Administrators make adjustments under operational pressure. Every change has the potential to move a system further from its intended baseline. The question is not whether drift will occur. It will. The question is how quickly you find out.
A CIS Benchmark assessment run three months ago may have been accurate when it was conducted. It tells you very little about today. Security teams are making decisions based on historical information while attackers are operating against current conditions. That gap is where breaches happen.
A benchmark assessment run three months ago tells you what things looked like three months ago. Attackers are operating against what things look like right now.
What Continuous Assessment Actually Looks Like
Getting ahead of this requires a shift from periodic reviews to continuous automated assessment. In practice that means:
- Automated CIS Benchmark assessment: running across every server, container and cloud workload — including AI infrastructure — not quarterly but continuously.
- Drift detection: that surfaces changes as they happen, not when someone next pulls a report.
- Automated remediation: closing known misconfigurations before they become exploitable, rather than generating findings that age in a queue.
- Hardened base images: baked into AI deployment pipelines so new infrastructure starts from a secure baseline, not a cloud provider default.
- Privilege hygiene: for AI service accounts — minimum necessary access, monitored continuously, not reviewed when someone remembers.
The organisations getting this right are not doing better audits. They have built configuration management into their operational rhythm so the gap between intended state and actual state is measured in hours, not months.
Resilience Is an Operational Discipline, Not a Product
Resilience was one of the recurring themes at Infosecurity this week in presentations, panel discussions and strategy conversations across the event. But genuine resilience is not built through a single technology investment. It comes from operational discipline applied consistently over time.
The organisations that will secure AI most effectively are not going to be those with the most ambitious AI security roadmaps. They will be the ones that maintain visibility into their environments, understand when configurations change and respond quickly when they do.
As I left the event, I kept coming back to the same thought. Before we ask whether an AI system is secure, we should ask whether the infrastructure supporting it is secure, continuously assessed and properly understood.
The answer to that question will usually determine the answer to the first.
