Harvendra Singh, IT Delivery Manager – Cloud Engineering & Architecture, driving innovation through cloud and AI-led digital transformation.
For decades now, software supply chain security has been focused squarely on code. Companies worried about vulnerable libraries, compromised packages or insecure dependencies making their way into production.
That was a legitimate concern, and it still is, but modern, AI-driven systems are taking that problem to the next level.
Modern cloud-native applications are increasingly powered not just by code but also by ML models, vector databases, prompt pipelines, external datasets, AI agents and third-party inference services. In fact, in many organizations today, teams are adopting these capabilities faster than they can be secured.
We’re calling this challenge AI supply chain security.
Unlike software supply chains of the past, AI systems bring complexity that many organizations aren’t prepared for.
First, let’s review how traditional software supply chains differ from those driven by AI.
How The Supply Chain Has Changed
Think of a traditional application. Odds are it’s deterministic. Code can be inspected. Dependencies can be validated. Expected behavior can be tested in a staging environment.
AI systems are different. A cloud-native application that includes AI may also source:
• External models trained with unknown data
• Dynamically generated prompts
• Third-party APIs
• Autonomous agents that make decisions in real time
• Continuously updated models
Each of these components adds a security risk.
The issue is that traditional supply chain security focuses on securing the infrastructure. But what about the “brains” powering that infrastructure? As AI gets baked into cloud-native platforms, the potential attack surface increases exponentially.
Today’s software supply chain security focuses on securing code. But the AI supply chain also includes things like data, models, prompts, context and decisions.
Why Traditional Security Techniques Fall Short
When it comes to cloud security, most teams think about infrastructure and identity. Secure the network. Harden your workloads. Manage access. Monitor logs.
That’s not wrong. But AI introduces security risks that don’t conform to traditional thinking.
Take a few examples:
• A manipulated dataset can influence how a model behaves, without changing the application.
• Prompt injection can trick a model into producing a specific output.
• Model drift can slowly alter output over time, without teams noticing.
• Using third-party AI services can create blind spots in governance and visibility.
The problem is that a lot of traditional security fails when it comes to AI. You can have all the logging in the world but still not know your models are biased, vulnerable or making unsafe decisions.
That’s a risky proposition.
AI Risks Compounded In Cloud-Native Systems
Cloud-native systems are built to support rapid innovation. They’re modular, distributed and almost infinitely scalable. AI fits perfectly into these types of systems. It’s easy to plug a model into an API, workflow, automation pipeline or operational technology system.
The challenge is that speed often overcomes governance.
In my work with teams building AI-driven applications, I’ve seen too many examples of teams rushing to deploy AI capabilities without asking how those models are sourced, trained, monitored or updated over time.
“It’s from Amazon/Azure/Google.” I often hear teams say that and assume the model is safe.
But what if it’s not?
Like any other software component, there is risk when integrating third-party services. With AI, those risks can be harder to see, but they are still very real because AI components aren’t like typical software. They aren’t static. They learn and adapt over time, evolving as data changes and they’re exposed to new contexts.
Why Continuous Validation Matters
What happens if your model starts making unpredictable decisions?
If you don’t have a way to validate AI behavior, you won’t know. That’s why continuous validation of AI components is one of the most important shifts we’ll see over the next few years.
Traditional software testing operates on the assumption that your system will behave the same way every time it’s executed. But AI doesn’t behave that way. That’s why teams are looking to continuous validation, including:
• Monitoring AI behavior and outputs
• Analyses for anomalous outputs and decisions
• Continuous validation of prompts and workflows
• Monitoring for model drift
Continuous validation allows you to create a feedback loop where you’re constantly evaluating security rather than checking it at one point in time.
Trust That Comes Downhill From Engineering Teams
One other critical shift happening now is that security and validation are moving from IT organizations into engineering teams.
AI isn’t something you secure. AI is something you build with confidence. That means engineering teams should own the trust and validity of their AI-driven decisions.
Look at Uber. Who’s responsible for a self-driving car hitting a pedestrian? The security team?
Security needs to be part of the conversation. But everyone from architects to developers, platform engineers and data teams all play a role in AI supply chain security.
Security and engineering teams need to work together to create a culture of trust.
Traits Of AI-Secure Applications
To help bring this idea to life, here are a few traits of AI-secure applications that we’ve seen teams build successfully:
• Ownership: Clear teams “own” AI systems and their dependencies.
• Visibility: Teams have visibility into where their models come from and how they are updated.
• Observability: Can teams observe AI behavior?
• Automation Guardrails: Teams have guardrails for any automated decisions.
• Incremental Adoption: Teams don’t rush AI adoption. They expand capabilities gradually.
Engineering teams own the trust behind their applications. Everything else flows from there.
The Future Of Cloud Native Security
Everything we’ve talked about points to one thing. As more AI capabilities get integrated into cloud-native applications, security teams must shift their focus from securing infrastructure to securing decisions.
Yes, application and infrastructure security are important. But teams must develop a new discipline around trusting the decisions their applications are capable of making.
Because someday soon, we won’t be asking if our servers are secure.
We’ll be asking if we can trust them.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
