How We Think About AI Security at MWC
The AI era is gathering steam and the velocity of change is climbing with it. Change introduces opportunities to stop and think if the old ways still serve us. Some do, some don’t. Implementing good security at the start - not after you've already shipped - begins with first principles. At Millwater we are fundamentally aligned with the first principles of Trust Nothing and Detect Everything. Trust Nothing, which means security architected into your foundational systems of record, and Detect Everything, which means observability that scales with the system instead of trailing behind it.
Trust nothing, detect everything
We first assume no 3rd party system, no new piece of data, no input, no tool call and no model output is safe until you've proven it, then we design every system so you can see what actually happened rather than what you hoped happened. Trust is a control you grant deliberately, not a default you inherit.
Defence in depth means a few trusted partners, not twenty
Defence in depth is real, but people misread and misapply it badly. Defence in depth does not mean twenty security vendors stacked on top of each other, every one of these is one more software supply on its own, and actually can increase your net risk. It means two or three highly capable, genuinely trusted partners, each covering a layer that holds up if the one above it fails.
Most NZ and Australian organisations do this poorly. They bolt on more and more tooling to plug gaps in systems that were never secure by design and every bolt-on becomes another credential to rotate and another vendor to breach.
More vendors does not equal more secure. It's the exact opposite: every third-party software stack you adopt is one more piece of your attack surface. Complexity is the enemy of security and the simplest design that meets the requirement is almost always the most secure one - which is really just the previous point wearing a different hat.
Keep your work and personal AI separate. Always.
Diversify your resilience the way you'd diversify investments - don't put all your eggs in one basket. Your work agents and your personal agents should live in a separate blast radius, with separate credentials and separate data. When one is compromised and eventually one will be, the other keeps standing.
Treat every agent as already compromised
Design as if the agent is already owned. That reframes every decision you make when it comes to AI. Ask what can it reach, what can it spend and what can it exfiltrate before anyone notices? Even the experts are still figuring this out and anyone who tells you they've got agentic security solved is misinformed, not recognising their own blind spots and/or selling something.
Design for failure, not for a perfect world
The sharpest framing I've heard on this came from Mike Parsons of Air New Zealand at a local AI meetup recently. His point: "Airlines have always designed for human failure. No human failure should result in that impacting reliability or safety. The same principle applies to AI - design for failures and errors and the system should cater to that." That's the mindset in one sentence. You don't secure an agent by hoping it behaves - you secure it by assuming it won't and building the control gaps and fallbacks so a single failure never cascades into a real incident.
Prompt injection is real - don't hand your harness the open internet
Prompt injection threats are real, emergent and evolving fast. The single biggest mistake we see is giving the harness - Claude, Hermes, Copilot, whatever you're running - direct, unmediated internet access. Don't do it. Put a proxy in front of it, log every call, observe the traffic, sandbox the execution and enforce policy on tool use with something like OPA for your MCP servers. That's defence in depth in practice, not in slideware. Each layer assumes the one before it already failed, which is the only assumption worth building on.
The standards aren't finished - be honest about that
Agentic security standards are still forming. SPIFFE for workload identity, OAuth extensions for delegated agent authority - the pieces are emerging, but nobody has the full stack nailed. Anyone who claims they can reliably measure what an agent did on behalf of a user is stretching the truth and we've seen only a handful of implementations that actually do this well - even those had room to improve. That's not a reason to wait. It's a reason to build with humility, instrument everything and revisit your assumptions as the standards catch up.
The takeaways
Design security in from commit one. Bolting it on later costs more and secures less.
Fewer, more-trusted partners beat a wall of vendors every time.
Separate your work and personal AI. Always.
Assume every agent is already compromised and size the blast radius accordingly.
Never give your harness raw internet access - proxy, log, sandbox, enforce policy.
Stay humble. The standards are still being written and honesty about that is itself a security control.
If you're building agentic AI systems in New Zealand or Australia and want a second set of eyes on your security architecture, that's exactly the kind of work we do at Millwater. Let's do it once and do it right.
-Patrick Sullivan, MD, Millwater Consulting https://millwater.consulting
