Zero Trust Fundamentals for Data Scientists and ML Engineers
Return to Part 0: Table of ContentsPrevious Article: Chapter 2, LLMs Explained for Security Professionals
Part One: Foundations | Chapter 3 of 39
If you deploy ML models and you do not know what "least privilege" means, this chapter is for you.
Your Jupyter Notebook Is Not a Production Environment
Shadow AI adds $670,000 to the average data breach.[1] That figure comes from IBM's 2025 Cost of a Data Breach Report, and it does not describe a sophisticated attack vector or a novel zero-day exploit. It describes what happens when AI tools are deployed without security oversight. When the line between experimentation and production blurs. When "it works on my laptop" becomes the implicit deployment standard for systems that touch sensitive data.
If you are a data scientist, an ML engineer, or anyone building AI systems, that $670,000 is the price tag for the gap between what you know about machine learning and what you do not know about network security. This chapter exists to close that gap.
Chapter 2 explained how large language models work for security architects. This chapter brings the inverse perspective: the security architecture concepts that AI practitioners need to understand before their models go anywhere near production data.
The good news: you do not need a security certification. You need a working understanding of five concepts that will change how you think about deployment, access, and trust.
Why "It Works on My Laptop" Is a Security Incident Waiting to Happen
Consider the typical ML development workflow. A data scientist builds a model on a local machine or a cloud notebook. The training data lives in a shared drive, a data lake, or a cloud storage bucket. The model is tested locally, pushed to a repository, and eventually deployed to a server where it receives production traffic.
At every stage, the question asked is: "Does it produce the right output?"
The question rarely asked is: "What can this system access, and who decided it should?"
In development environments, access controls are typically permissive by design. Notebooks connect to data sources with broad credentials. API keys are stored in configuration files or, worse, hardcoded into scripts. Models are tested against production data because synthetic data is expensive and incomplete. When that model moves from development to production, it often carries those permissive access patterns with it.
This is not a theoretical concern. IBM's 2025 report found that 13% of organisations experienced breaches involving AI models or applications.[1] Of those organisations, 97% reported lacking proper AI access controls.[1] The pattern is consistent: AI systems are being deployed faster than the security architecture can adapt to govern them.
In New Zealand, government AI adoption has accelerated significantly, with dozens of AI use cases now in operational deployment across government agencies, up substantially from the previous year.[2] That acceleration is necessary and welcome. But operational deployment means production access to citizen data, government systems, and regulated information. Each of those operational deployments needs security architecture that was designed, not assumed.
Traditional network security operated on a simple model: build a wall around your network, verify identity at the gate, and trust everything inside. This is the castle-and-moat approach, and it worked adequately when users sat at desks inside corporate buildings, applications ran on servers in corporate data centres, and the network boundary was physically definable.
That model is now obsolete. Your ML training pipeline pulls data from a cloud data lake hosted in Sydney. Your model is served from a container running in an Azure region. Your API consumers include a mobile application, a web service, and three other internal systems, each running in different network segments. The "inside" of your network is a meaningless concept.
Zero Trust architecture replaces the perimeter model with a principle: never trust, always verify. Every access request, whether it comes from a human user, an API call, or an automated ML pipeline, is treated as potentially hostile until verified. Trust is not granted by network location. It is earned through continuous verification of identity, device health, and behavioural context.
For data scientists, this means a fundamental shift in assumptions. In the castle-and-moat model, once your model was "inside the network," it could access whatever it needed. In a Zero Trust model, your model must prove its identity, justify its access, and operate within defined boundaries for every single transaction. Chapter 1 established that the median time to compromise an AI system is sixteen minutes.[3] Zero Trust architecture assumes that compromise has already occurred and builds containment around that assumption.
The Zero Trust market reflects the urgency. Estimated at $38.37 billion in 2025, it is projected to reach $86.57 billion by 2030.[4] Yet Gartner has projected that by 2026, only around 10% of large enterprises will have a fully mature Zero Trust programme, up from less than 1% in 2023.[5] The gap between recognition and implementation is where this book operates, and where AI practitioners can make the most difference by building security into their workflows rather than bolting it on afterwards.
Three terms that security professionals use interchangeably in casual conversation have precise, distinct meanings. Getting them wrong in your architecture creates vulnerabilities that no amount of model accuracy can compensate for.
Identity answers: "Who or what is making this request?" For human users, identity is established through accounts and credentials. For AI systems, identity is more complex. Your ML pipeline is not a person. It is a workload, a service, a process. It still needs an identity: one that is unique, auditable, and revocable. Chapter 16 explores the non-human identity crisis in depth, but the principle starts here. Every component of your AI system needs an identity that can be independently verified.
Authentication answers: "Can you prove you are who you claim to be?" This is the verification step. For humans, it means passwords, biometric scans, or security keys. For your ML model serving endpoint, it means cryptographic certificates, signed tokens, or workload identity attestation. The method matters. A static API key embedded in your deployment configuration is technically authentication, but it is the weakest form available: equivalent to taping your house key to the front door. Modern authentication for AI workloads uses short-lived, automatically rotated credentials that expire after minutes, not months.
Authorisation answers: "Now that I know who you are, what are you allowed to do?" This is where most AI deployments fail. Authentication without proper authorisation means your verified ML pipeline can access every data source, call every API, and write to every storage location it can reach. Authorisation constrains that access to only what is necessary for the specific task at hand.
For a concrete example: your sentiment analysis model needs read access to customer feedback records. It does not need write access to the customer database. It does not need access to financial records. It does not need the ability to call external APIs. Each of those unnecessary permissions is an attack surface. If the model is compromised through prompt injection, data poisoning, or supply chain attack, the blast radius is determined entirely by what the model was authorised to do, not by what it was designed to do.
Network segmentation is the practice of dividing a network into isolated zones, each with its own access controls. For AI practitioners, this is where theory meets deployment architecture.
In an unsegmented network, a compromised component can communicate with every other component. If an attacker gains control of your model inference endpoint, they can reach the training data store, the logging system, the authentication service, and potentially the wider corporate network. The blast radius is unlimited.
Segmentation limits that blast radius. Your model inference endpoint sits in one network zone. The training data sits in another. The logging system sits in a third. Communication between zones is explicitly permitted, monitored, and constrained. A compromised inference endpoint can only reach the specific resources it has been granted access to, and that access is mediated by policy enforcement points that inspect every request.
For ML engineers deploying to Kubernetes or cloud environments, segmentation is typically implemented through network policies, security groups, and service mesh configurations. The principle is straightforward: define the minimum set of network connections your workload requires, and deny everything else by default. This is the "default deny" posture, and it inverts the way most development environments operate, where the default is "allow everything."
Chapter 21 covers microsegmentation for agent containment in detail. For now, the practical takeaway is this: if your deployment configuration does not explicitly define which network endpoints your model can communicate with, it can probably communicate with all of them. That is not a feature. It is a vulnerability.
The Principle of Least Privilege Applied to AI Workloads
Least privilege is the single most important security concept for AI practitioners to internalise. The principle states: every component should have exactly the permissions it needs to perform its function, and no more.
In practice, least privilege for AI workloads means constraining five dimensions of access:
Data access. Your model should only read the data it needs for its specific task. Training pipelines need access to training data during training, not during inference. Inference endpoints need access to the model weights and the incoming request data, not to the entire data lake. Classification labels, feature stores, and model registries each require separate, scoped permissions.
Compute resources. Your training job needs GPU access during training. It does not need GPU access when it is idle. Autoscaling policies should grant resources on demand and revoke them when the job completes. Over-provisioned compute is not just wasteful; it is a larger attack surface.
Network connectivity. As discussed in segmentation, your model should only connect to the specific endpoints it requires. Egress controls, governing what your model can send outbound traffic to, are particularly important. An AI system that can make arbitrary outbound connections is an exfiltration vector waiting to be exploited. This is one of the three capabilities in the Lethal Trifecta, which Chapter 5 examines.
Temporal access. Permissions should be time-bounded. A training pipeline that needs access to a sensitive dataset should receive that access for the duration of the training job, not indefinitely. Just-in-time (JIT) access provisioning grants permissions when needed and revokes them automatically when the task completes.
Operational scope. Your model endpoint might need read access to a database. It almost certainly does not need the ability to delete tables, modify schemas, or create new users. Scope permissions to the specific operations required: read, write, execute, and nothing more.
The table below maps common AI deployment patterns to their security anti-patterns and the least-privilege corrections:
Common AI Deployment Anti-Patterns and Their Security Implications
| AI Deployment Pattern | Security Anti-Pattern | Risk | Least-Privilege Correction |
|---|---|---|---|
| Shared service account for all ML pipelines | Single credential compromise exposes all workloads | High | Unique identity per pipeline; scoped credentials per task |
| API keys in environment variables or config files | Credential exposure through logs, version control, or container inspection | High | Short-lived tokens via workload identity; secrets management (e.g., Vault, AWS Secrets Manager) |
| Training pipeline with persistent access to production data | Lateral movement from compromised training environment to production | High | JIT access provisioned per training run; revoked on completion |
| Model endpoint with unrestricted egress | Exfiltration vector if model is compromised via prompt injection or data poisoning | Critical | Explicit egress allowlist; all other outbound traffic denied |
| Jupyter notebook connected to production database | Development environment becomes attack surface for production data | Critical | Separate environments with synthetic or anonymised data for development; network isolation |
| Shared credentials across development and production | Compromise in dev grants access to production | High | Separate credential chains; no credential reuse across environments |
| Model deployed without resource quotas | Denial of service via resource exhaustion; unconstrained token generation | Medium | CPU, memory, and token limits enforced per workload |
| Broad IAM roles ("data scientist full access") | Permissions exceed operational requirements; violation surfaces unknown | High | Task-specific roles; periodic access reviews; principle of minimal authority |
If you have read this far, you now understand five concepts that most AI practitioners have never been formally taught: Zero Trust as a replacement for perimeter security; the distinction between identity, authentication, and authorisation; why network segmentation limits blast radius; and why least privilege is the non-negotiable foundation of secure AI deployment.
These are not abstract principles. They are the operational requirements that typically determine whether your AI system survives its first encounter with a determined attacker. When Chapter 1 described operations completing in sixteen minutes from initial access to full system compromise, the only architecture that can respond at that speed is one where access controls are granular, automated, and enforced at every transaction.
Chapter 4 introduces the distinction between AI agents and agentic AI, a distinction that determines whether the security model you have just learned scales to autonomous systems. Chapter 5 introduces the Lethal Trifecta: the three compound capabilities that turn any AI system into an insider threat when combined without proper constraints. Every defensive pattern in this book builds on the fundamentals established here.
For NZ practitioners working in regulated environments, these concepts connect directly to the governance landscape covered in Part Two. The NZ regulatory framework increasingly aligns with Zero Trust principles, and Chapter 7 examines the specific mechanisms in detail. IPP 3A, taking effect in May 2026, creates new obligations around data provenance that require the kind of granular access controls described in this chapter.[6] Understanding Zero Trust is not optional for anyone deploying AI in New Zealand's regulated environments. It is rapidly becoming a compliance requirement.
I did not write this chapter to lecture data scientists about security. I wrote it because I need you in the room when architecture decisions are made. The models you build will only be as secure as the infrastructure they run on, and the infrastructure will only be effective if its designers understand what your models actually need. That shared understanding starts with these five concepts.
Next week in Chapter 4: AI Agents Versus Agentic AI: The Distinction That Changes Everything
What was the first security concept you wish you had learned earlier in your data science career? I am building this series around real practitioner gaps, and your experience helps shape what comes next.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. Zero Trust Architecture for the Agentic Enterprise is the first book in The Hamberger Report series, providing practitioners with deployable patterns and configurations for securing AI-driven systems.
[1] IBM and Ponemon Institute, "Cost of a Data Breach Report 2025," July 2025. https://www.ibm.com/reports/data-breach
[2] Government Chief Digital Officer (NZ), "2025 Cross-Agency Survey of Use Cases for Artificial Intelligence," August 2025. https://www.digital.govt.nz/dmsdocument/263~full-results-2025-cross-agency-survey-for-artificial-intelligence-ai-use-cases/html
[3] Zscaler ThreatLabz, "AI Security Report 2025," 2025.
[4] Expert Insights / Grand View Research, "Zero Trust Architecture Market Size and Trends," 2025. https://www.grandviewresearch.com/industry-analysis/zero-trust-architecture-market-report
[5] Gartner, cited in Northern Technologies Group, "Zero Trust Architecture in 2025," August 2025. https://ntgit.com/zero-trust-architecture-in-2025-shifting-from-perimeter-security-to-never-trust-always-verify/
[6] Privacy Act 2020 Amendment, Information Privacy Principle 3A. https://legislation.govt.nz
[7] Zscaler / Cybersecurity Insiders, "ThreatLabz 2025 VPN Risk Report," April 2025. https://www.cio.com/article/3962906/why-81-of-organizations-plan-to-adopt-zero-trust-by-2026.html