Zero Trust for AI Workloads on EKS

Large language models, vector databases, AI agents, and tool-calling services are increasingly being deployed on Kubernetes, introducing new security challenges around identity, access, and trust. In this session, we will explore how Zero Trust principles can be applied to AI workloads running on Amazon EKS. Through a live demo, we will build and secure a small AI platform using workload identity, service-to-service authentication, network isolation, least-privilege access, and policy enforcement. Attendees will see how identity-based controls can help prevent unauthorized access, limit lateral movement, and reduce the blast radius of compromised workloads, while gaining practical patterns for securing modern AI systems on Kubernetes.

Transcript

1. AWS COMMUNITY DAY KENYA · PWANI EDITION Track: Cloud Architecture & Infrastructure - Technical Session Zero Trust for AI Workloads on EKS Muhammad Sumon Molla Selim @SumonMSelim 4 July 2026 · Swahili Pot Hub, Mombasa
2. $ whoami Muhammad Sumon Molla Selim Member of Technical Staff, Causal Dynamics Lab AWS Community Builder 4x AWS & Terraform certified Zero Trust practitioner Spoke on “Zero Trust in EKS” - June 2026 Currently building Timothy - a personal AI agent, agentguard - AI guardrails @SumonMSelim 2
3. AI Has Moved Into Your Cluster LLMs are no longer someone else’s SaaS - they are pods, services, and secrets in your VPC LLM & Inference Services Self-hosted models and gateways to Anthropic, xAI, Z.AI. Every call carries a paid, powerful credential. Vector Databases Your private corpus, embedded and queryable. One over-permissioned pod away from bulk exfiltration. AI Agents Software that can autonomously plan and execute tasks, but with no badge at the door. Tool-Calling Services Agents reach into APIs, databases, and AWS itself. Tools turn text into side effects. Every one of these is a workload with identity, secrets, and network reach. @SumonMSelim 3
4. Why AI Workloads Change the Threat Model Same cluster, new blast radius Classic Web App • Code paths are predictable and testable • Humans drive actions through the UI • Secrets: a DB password, maybe an API key • Attackers come in through ingress Agentic AI Platform • Prompt injection can influence or redirect agent behavior • Agents act autonomously with real credentials • LLM API keys & model access concentrate value • Heavy egress to third-party model providers • Vector DB: private data one query away You can’t firewall a prompt - but you can decide what a compromised agent can reach. @SumonMSelim 4
5. The Zero Trust Mandate Never trust, always verify Explicit Verification Authenticate and authorize every request. No implicit trust from network location. Least Privilege Just-in-time, just-enough access for every workload. Assume Breach Design for failure; minimize the blast radius when (not if) something is compromised. Continuous Validation Identity and context are verified continuously, not once at the perimeter. Authenticate ↓ Authorize ↓ Validate - continuously every request · every hop @SumonMSelim 5
6. The Perimeter Model Has Collapsed Identity is the new firewall The Old Way - Perimeter • Static IP addresses • Trusted internal network • Centralized data center • Hard shell, soft inside The New Reality - Zero Trust • Ephemeral workloads (pods) • Default-allow east-west connectivity • Multi-cloud, managed services • Identity is the new firewall @SumonMSelim 6
7. Today’s Blueprint: Five Identity-Based Controls Exactly what we will build and attack in the demo Workload Identity SPIFFE / SPIRE + IRSA 1 Service AuthN mTLS with X.509 SVIDs 2 Network Isolation Default-deny NetworkPolicy 3 Least Privilege Scoped IAM per pod 4 Policy Enforcement Kyverno admission control 5 prevent unauthorized access · limit lateral movement · shrink the blast radius @SumonMSelim 7
8. Identity Foundation: Two Planes Who a pod is - inside the mesh and toward AWS Workload Identity (East-West) SPIFFE / SPIRE • X.509 SVID certificate per workload • Replaces network-location trust • mTLS for every internal hop • Attested at runtime - no deployed secrets spiffe://timothy.mol.la/ns/…/sa/… Cloud Identity (North-South) IRSA (IAM Roles for Service Accounts) • Least-privilege IAM role per service • Temporary AWS credentials via STS • OIDC federation - no static keys • Scoped to exactly the APIs each pod needs pod → OIDC token → STS → scoped role @SumonMSelim 8 Newer option: EKS Pod Identity (no OIDC setup)
9. How a Pod Earns Its Identity SPIRE attestation for timothy-brain 1 · Node Attestation SPIRE agent proves its node to the SPIRE server (EC2 instance identity). → 2 · Workload Attestation Agent evaluates workload selectors (service account, namespace, labels) against registration entries. → 3 · SVID Issuance Pod receives a short-lived X.509 SVID over the Workload API socket. Result: spiffe://timothy.mol.la/ns/timothy-core/sa/timothy-brain - rotated automatically, never written to disk @SumonMSelim 9
10. Meet Timothy - A Personal AI Agent Five Go services on a dedicated EKS cluster (timothy-eks) ns: timothy-edge ns: timothy-core AWS / Internet timothy-gateway REST · :8080 timothy-brain orchestrator llm-router mTLS :9444 memory-service mTLS :9445 tool-runner mTLS :9446 Claude · Grok · GLM model APIs :443 Secrets Manager timothy/llm/* RDS · pgvector memory store mTLS for all service-to-service communication @SumonMSelim 10
11. One Brain, Many Models Task-based routing inside llm-router - user can always override Task type Routed to Why Planning · reasoning · orchestration Claude (Anthropic) Strongest agentic reasoning and tool-use decisions Real-time info · news · social Grok (xAI) Live knowledge and real-time context Coding · summarization · bulk GLM (Z.AI) Fast and cost-efficient for high-volume work Local dev & ops workflows Kiro CLI Runs on the workstation, disabled in-cluster @SumonMSelim 11 model_hint: user override fallback: Claude → GLM → Grok
12. Service AuthN: Identity, Not Location go-spiffe AuthorizeID() - one allowed caller per service Service Accepts connections only from timothy-brain :9443 spiffe://timothy.mol.la/ns/timothy-edge/sa/timothy-gateway llm-router :9444 spiffe://timothy.mol.la/ns/timothy-core/sa/timothy-brain memory-service :9445 spiffe://timothy.mol.la/ns/timothy-core/sa/timothy-brain tool-runner :9446 spiffe://timothy.mol.la/ns/timothy-core/sa/timothy-brain Mutual TLS on every hop, both sides present X.509 SVIDs A pod with no SVID (or the wrong one) fails the handshake before any request is read Removing a registration entry stops future issuance; existing SVIDs expire naturally @SumonMSelim 12
13. Network Isolation: Deny by Default Enforcement: VPC CNI native - or Calico / Cilium (L7 & FQDN policies) Rule 00: default-deny-all All ingress and all egress blocked in both namespaces. Every allowed path below is an explicit, numbered policy in git. kind: NetworkPolicy spec: podSelector: {} policyTypes: [Ingress, Egress] Explicitly allowed paths ✓ ingress → gateway :8080 ✓ gateway → brain :9443 ✓ brain → router / memory / tools ✓ internet egress :443, permitted only for llm-router ✓ memory → RDS :5432 ✓ everyone → DNS :53 · kubelet probes A compromised agent that “wants” to exfiltrate has nowhere to go. @SumonMSelim 13
14. Least Privilege: One Scoped Role per Service IRSA on timothy-eks - newer alternative: EKS Pod Identity Service IAM role Allowed actions llm-router timothy-llm-router secretsmanager:GetSecretValue → timothy/llm/* only memory-service timothy-memory secretsmanager:GetSecretValue → timothy/db only tool-runner timothy-tool-runner sts:GetCallerIdentity - nothing else gateway · brain - none - zero AWS API access Steal a pod, and you get: a temporary credential that can do almost nothing. @SumonMSelim 14
15. Policy Enforcement at Admission Kyverno: bad pods never start Verify image signatures Only cosign-signed images from our ECR repos are admitted. No privileged / root pods runAsNonRoot, no privilege escalation, all capabilities dropped. Required ownership labels Every workload carries app and team labels, auditability by default. Egress label gate Only pods labeled egress=internet can match the internet-egress policy. Identity says who you are. Policies decide what is even allowed to exist. @SumonMSelim 15
16. Demo: Compromise Timothy, Watch It Fail Assume breach, then prove the blast radius 1 Happy path: Chat with Timothy: gateway → brain → llm-router, all over mTLS WORKS 2 Show identities: SPIRE entries and live SVIDs for all five services VERIFIED 3 Rogue pod in timothy-core: NetworkPolicy blocks the path; if networking were allowed, SPIFFE authorization still rejects the caller BLOCKED 4 Compromised tool-runner: egress to api.anthropic.com denied; cannot pull LLM secrets from Secrets Manager (AccessDenied) BLOCKED 5 Privileged pod: kubectl run --privileged → rejected by Kyverno at admission DENIED @SumonMSelim 16
17. Key Takeaways Zero Trust for AI workloads, in five moves Identity is the perimeter SPIFFE inside the cluster, IRSA toward AWS. Authenticate services, not networks mTLS with exact SPIFFE ID authorization on every hop. Assume the agent is compromised Default-deny networking; one audited egress path. Least privilege per workload Scoped, temporary AWS credentials - a stolen pod is a dead end. Enforce at admission Signed images only, no privileged pods - policy as code with Kyverno. Result: unauthorized access prevented · lateral movement limited · blast radius contained @SumonMSelim 18
18. Any questions? github.com/sumonmselim @SumonMSelim Asante sana!