AI in the SDLC: Is It Safe to Open the Door?

We recently published a piece of long-form research on what an AI-enabled software development lifecycle actually looks like in practice. Not the headlines, but the discipline, the controls, and the trade-offs. The reaction has been mostly positive, but a particular concern keeps coming back from engineering leaders:

“It looks great, but I’m not sure I’m ready to open up the attack surface.”

That hesitation is entirely reasonable. And it’s been sharpened this past week by yet another large-scale supply chain incident: the so-called “Mini Shai-Hulud” worm, which compromised TanStack, Mistral AI, UiPath, OpenSearch and over 160 other npm and PyPI packages on 11 May, propagating across the ecosystem in under twenty minutes. OpenAI confirmed two of its employee devices were caught up in it. The malicious packages were signed with valid SLSA provenance and published through legitimate OIDC trusted-publisher bindings, meaning they looked entirely normal until they weren’t.

That’s the backdrop against which someone is now being asked to approve MCP servers, agentic coding tools, and broader developer access to external models. It’s a fair moment to pause.

But pausing isn’t the same as stopping. Let’s look at what the risk actually is, and then at what good looks like.

What people are actually worried about

There are roughly three flavours of concern, and they’re worth separating because the mitigations differ.

The first is the classic supply chain problem, made worse. AI-assisted development tends to expand the dependency surface. Agents pull in libraries, suggest packages, and accelerate the rate at which new code enters the codebase. Mini Shai-Hulud is the latest reminder that this isn’t an AI problem so much as an AI problem that makes it more urgent. The “lost art” of software supply chain hygiene (SBOMs, pinned versions, contractual OSS declarations) was already overdue for a revival.

The second is the MCP and context problem. Model Context Protocol has become, as Anshu Chada at Uber neatly put it, “the USB-C of AI agents.” It’s a brilliant abstraction, and exactly the kind of thing that worries security teams when handed to developers as a free-for-all. An MCP server can read source code, call internal APIs, hit production data warehouses, post to Slack. Most are written by individuals on weekends. Some are written by people who would very much like access to your secrets.

The third is data movement. If your developers are pasting code into a public model, where is that code going, who can train on it, and what happens when something sensitive leaves the building? This is the easiest of the three to address but the one that tends to scare boards the most.

The Uber pattern: a gateway, not a free-for-all

The most useful piece I’ve read on this recently was Gergely Orosz’s deep dive into how Uber runs its internal AI stack. The single most transferable idea is their MCP Gateway: a central proxy through which every MCP server, whether internal or third-party, must flow. Authentication, authorisation, telemetry and logging all happen in one place. There’s a registry for developers to find approved servers, and a sandbox for them to experiment without wiring anything into their daily environment.

This is unglamorous infrastructure, and it’s exactly what you need. The alternative, where every developer manually configures half a dozen MCP endpoints in their IDE, is precisely the surface area people are right to be nervous about. Uber’s approach doesn’t rule out MCP. It says: yes, but everything goes through one door they control.

The same logic applies to AI tooling more broadly. Uber’s AIFX CLI gives every developer the same provisioned set of agent tools, with helpful defaults, centrally maintained and kept up to date. Nobody is on their own with their personal Claude Code config and a half-trusted GitHub MCP server.

For a consultancy or in-house engineering team, that pattern is replicable. You don’t need Uber’s scale to copy its shape. That being said, Uber just put the brakes on its AI spending because developers had gone way over its budget, so maybe their CLI will become a cost throttling engine as much as a security layer.

The data movement concern has a relatively clean answer: run your models in your own cloud tenancy. The three major hyperscalers all have a story here. Vertex AI on Google Cloud, Azure AI Foundry, and Amazon Bedrock all offer frontier models (including Claude, Gemini, and others) within your existing data perimeter, IAM, and audit trails.

This isn’t about whether the public APIs from Anthropic, OpenAI or Google are safe. They are. It’s about whether your data governance posture, your regulator, or your client contract allows code or context to leave your tenancy. For most of the regulated sectors we work in (financial services, healthcare, energy) the answer is that hosted-in-tenancy is the only sensible default. It’s also how you get consistent logging, cost attribution and access control across multiple teams.

Engineering still does the heavy lifting

None of this is to suggest AI replaces good engineering practice. The Mini Shai-Hulud attack succeeded because of three chained GitHub Actions misconfigurations: pull_request_target patterns, cache poisoning across trust boundaries, and OIDC token extraction. No AI tool caused that, and no AI tool would have prevented it. What prevents it is the same boring discipline that’s always prevented it: pinned action SHAs rather than floating tags, isolated runners for untrusted code, scoped tokens, and SBOMs you actually read.

This is a theme that runs through our wider thinking on the AI-enabled SDLC. The point of bringing AI into the lifecycle is to free engineers to spend more of their time on exactly that sort of work, the judgement, the architecture, the threat modelling, and less on the boilerplate. Done well, AI raises the floor of what your team can deliver and leaves more headroom for the things only humans can do.

Why this work pays off

Getting the security scaffolding right isn’t just defensive. It’s the precondition for the bigger prize, which is the compound gain that comes from giving your AI tooling access to a rich, well-curated picture of your business: your code, your tickets, your docs, your architectural decisions, your past pull requests. The industry has started calling this global context, and it’s where the real productivity story lives, well beyond the per-developer tab-completion gains most teams currently measure.

But you only get to play in that space if the foundations underneath are sound. A gateway you trust, models hosted where your data lives, a sanctioned toolchain. Without those, “more context” just means “more leakage.”

So, is it safe?

Safe isn’t quite the right question. The honest answer is: 

it’s safer than letting “shadow AI” happen anyway, which is what’s going on at most organisations, whether they’ve sanctioned it or not.

The right question is whether you’ve put the right shape of controls in place: a gateway for MCP and tooling, models hosted where your data already lives, a sensible default toolchain provisioned centrally, and supply chain hygiene worthy of the era we’re in.

Get those right, and you can open the door with both hands. Leave them undone, and the door is already open. You just can’t see who’s walking through it.

Our full research on the AI-enabled SDLC covers the broader picture this article sits within: the workflow, the discipline, and the governance scaffolding that make it work. If you’d like to talk through any of it, please get in touch.