Last week we established the diagnosis: the governance gap is real, it is widening, and it is the structural condition that made the most serious AI security incidents of 2026 possible. This week is the prescription — what building responsibly with AI actually looks like in practice, and what the organisations navigating this era successfully are doing differently from everyone else.
This post stands on its own — but if you missed Part 1, start there for the full context on why the threat landscape has permanently changed.
Governance readiness in enterprise AI sits at 30%. Only 37% of organisations have a formal AI policy — down from 45% last year. Nearly three-quarters plan to deploy autonomous agents, yet only 21% have governance in place for them. The AI stack itself has become the primary attack surface, and most organisations have no map of it.
1. What Building Responsibly with AI Actually Means in 2026
The answer to the governance gap is not to slow AI adoption. That is neither realistic nor strategically correct — the competitive pressure is real, and the organisations sitting on the sidelines while others move are already falling behind in ways that compound. The answer is to build with the same rigour in the governance and security layer that the best teams already apply to the product layer.
This is not abstract. Here is what it looks like in practice.
Treat your dependency graph as a security boundary, not a convenience
Every package your code imports — and every package those packages import — is a trust relationship. Most organisations review their direct dependencies. Almost none systematically audit their transitive ones. The LiteLLM attack landed through a transitive dependency that many affected teams had never consciously chosen to include. Over 74% of malicious packages reach production through this path.
Pin every dependency to an exact version. Commit lock files. Run automated supply chain scanning at the registry level, in the build pipeline, before packages ever enter any environment. Sonatype's tooling detected and blocked the malicious LiteLLM versions within seconds of publication. Manual review cannot move at that speed. Automated scanning at the right point in the pipeline can.
Govern AI tool permissions the way you govern database access
No competent engineer gives a service account more database access than it needs for its specific function. Apply the same discipline — the principle of least privilege — to AI tools. Define what each AI tool in your environment can access before deployment. Enforce those boundaries technically, not just through policy. Audit them regularly.
An AI coding assistant that can silently read your SSH directory and .env files is not a productivity tool with a theoretical risk. It is a credential exfiltration risk with a useful interface. The distinction matters. Claude Code's sandboxing architecture — OS-level filesystem isolation, network traffic routed through a controlled proxy, explicit user approval for any new domain — is what it looks like when an AI tool is built with this principle applied from the start rather than bolted on afterwards.
Treat CI/CD pipelines as privileged infrastructure
The credentials held in a CI/CD pipeline — publishing tokens, cloud access keys, deployment credentials, API keys — represent some of the highest-value access in any organisation. They should be scoped to minimum required permissions, rotated on a defined schedule, and never held in a way that is reachable from other tools in the same pipeline after a compromise.
The LiteLLM attack succeeded because credentials survived intact after an upstream tool was compromised. Atomic rotation after any known upstream incident should be standard practice. Treat "our security scanner was compromised" as a trigger to rotate everything that scanner could reach, immediately — not as an event to monitor while you finish the sprint.
Apply data minimisation as a first principle
The CareCloud breach was made significantly more consequential by an architecture that allowed a single environment breach to threaten records across 40,000 providers. That is partly a security failure. It is also a data governance failure — too much data, retained too long, in environments with insufficient segmentation.
Data minimisation asks a simple question before any system is designed: does this data need to exist here, in this form, for this long? The honest answer, in most systems, is that less data should be held than currently is.
Every unnecessary record retained is an additional unit of liability. Every day of unnecessary retention is an additional day of exposure if a breach occurs.
Design for breach containment, not just breach prevention
Eight hours. That is how long the CareCloud attacker was present before being detected and ejected. The organisations that will emerge from this era with their reputations intact will not necessarily be the ones that never get breached. They will be the ones that detect anomalies in minutes, contain breaches before significant data moves, and have response plans that have been tested before they were needed.
Tabletop exercises. Documented runbooks. Tested escalation paths. Real-time anomaly detection tuned to the sensitivity of the environments it is monitoring. These are not optional governance extras. They are the difference between a contained incident and a class action that opens within 24 hours of public disclosure.
Build AI governance into the development process, not after it
The 12% of organisations successfully deploying agentic AI at scale all share one characteristic: they document governance before deployment, not after. That means defining what an agent can access before it is built. It means setting baseline metrics before a pilot runs. It means having a named owner accountable for the agent's behaviour after deployment. It means integrating security review into the AI development lifecycle the same way code review is integrated into software development.
Governance introduced after deployment is remediation. Governance built in from the start is architecture. Those are not the same cost, and they do not produce the same outcomes.
2. The Practical Checklist: What to Do This Week, This Month, This Quarter
If you have read this far and are wondering where to start, here is a concrete starting point. Organised not by priority tier but by time horizon — because the most common failure mode in security planning is not choosing the wrong thing to do, it is deferring all of it indefinitely.
This week
- Audit what AI tools are running in your environment and what permissions they hold — including tools adopted by individual team members without central oversight. Shadow AI is almost certainly present. Find it before an attacker does.
- If you have any Python environment that may have run LiteLLM on March 24 without a pinned version, treat that machine as fully compromised and rotate all credentials accessible from it immediately.
- Review your CI/CD pipelines. Are credentials scoped to minimum permissions? Would they survive a compromise of an upstream tool? If not, tighten and rotate now.
This month
- Pin all dependencies across every environment — development, staging, CI/CD runners, and production. Without exception. This single change removes the largest category of supply chain attack risk.
- Integrate automated supply chain scanning into your build pipeline. Start with direct dependencies and expand to transitive coverage. Free tiers exist for Snyk and Sonatype to get you started.
- Map every AI agent in your environment against a least-privilege permission matrix. Document what each agent can read, write, execute, and transmit. Close every gap between current permissions and the minimum required for the task.
- Draft a formal AI acceptable use policy if one does not exist. Distribute it. Test whether staff can summarise it. If they cannot, you have a document, not a policy.
This quarter
- Conduct a data minimisation audit. For every sensitive data store: does this data need to exist here, in this form, for this long? Reduce retention windows. Increase segmentation. Reduce blast radius before a breach creates it for you.
- Run a tabletop incident response exercise for an AI-related breach scenario — a compromised dependency, an agent taking unintended actions, or a data exfiltration through an AI tool. Run it before an incident forces it.
- Establish baseline monitoring for anomalous behaviour in your most sensitive environments. If your current monitoring would not have detected the CareCloud attacker within an hour, recalibrate it.
- Assign named ownership for every AI agent in production. Someone should be accountable for what it does, what it can access, and what happens if it is manipulated or compromised.
What the 12% Share — the four traits of successful AI deployments
- Pre-deployment infrastructure investment — security and governance foundations built before the agent is deployed, not after.
- Governance documentation before deployment — what can it access, what can it do, who is accountable.
- Baseline metrics captured before pilots — so you know what normal looks like before an anomaly appears.
- Dedicated business ownership with accountability for post-deployment performance.
3. The Organisations That Will Win
The AI productivity race is real. The organisations moving quickly on AI adoption are building advantages that compound. That is not a reason to slow down. It is a reason to build better foundations.
The organisations that will be in the strongest position in three years are not the ones that deployed the most AI tools in 2025 and 2026. They are the ones that deployed AI with visibility into what their tools could access, governance over what their agents could do, security architectures designed to contain failures rather than merely prevent them, and data practices built around minimisation rather than accumulation.
The 6% of enterprises currently generating meaningful business outcomes from AI are defined by discipline as much as capability. They build baseline metrics before pilots. They integrate AI into workflows rather than layering it on top. They have governance in place before they scale. They measure what their AI is actually doing, not just what it was deployed to do.
That discipline is not a constraint on speed. It is what makes speed sustainable. Building fast on a foundation that has not been secured produces technical debt that eventually becomes a liability event. Building fast on a foundation designed for the threat landscape that actually exists produces something that can be trusted, extended, and scaled without the incident that resets the clock.
The competitive advantage in AI is not who moves fastest. It is who builds something that holds up. That is a harder thing to build. It is also the only thing worth building.
The gap between AI adoption and AI governance will not close on its own. It closes when organisations make a deliberate decision to treat governance as an engineering requirement rather than a compliance afterthought — before an incident makes that decision for them.
That decision is still available. Most organisations are just not yet making it.
Build AI on foundations that hold up.
We build AI-integrated systems for businesses that need them to be genuinely secure, governed, and scalable — not just capable. If you are planning an AI integration and want to build it on the right foundations from the start, we should talk.
Book a Discovery Call
