Last week I had the pleasure of speaking at the AI Security Engineers Community Netherlands meetup in Amsterdam, hosted at The Social Hub with support from the Snyk team. About 40 engineers gathered for an evening of deep technical content on securing AI systems — from LLM application vulnerabilities to infrastructure-level platform isolation.
The Event
The AI Security Engineers Community, founded by Davide Cioccia (DCODX Cybersecurity), brings together security professionals focused specifically on AI/ML security challenges. The Netherlands chapter holds regular meetups in Amsterdam, and this edition featured two complementary talks:
- Brian Vermeer (Staff Developer Advocate, Snyk) — “Breaching LLM-Powered Applications”
- Luca Berton (AI and Cloud Advisor) — “Securing Multi-Tenant AI Platforms on Kubernetes and OpenShift AI”
Gerald Crescione and the Snyk team provided the venue, drinks, and pizza — creating exactly the right atmosphere for candid security discussions.
Brian Vermeer: Breaching LLM-Powered Applications
Brian opened with a reality check: the same “old-fashioned” vulnerabilities that plague traditional applications — injection, broken access control, insecure configuration — still dominate the security posture of modern LLM applications. The AI layer adds new attack surfaces, but it does not replace the old ones.
Key topics covered:
- Data privacy risks with consumer AI services (your prompts may be training data)
- Prompt injection — both direct and indirect attacks
- Agentic AI function-level security — treating every tool call as an API with its own authorization boundary
- Human-in-the-loop patterns — the AI proposes, the human disposes
- Smart routing architectures — local models for sensitive data, commercial models for general queries
Brian demonstrated live vulnerabilities in a support chatbot that had no guardrails, happily explaining linear algebra instead of staying within its support scope.
For the full technical breakdown with code examples and slides, see my detailed writeup of Brian’s talk.
My Talk: Air-Gapped Multi-Tenant AI on Kubernetes
I shared practical lessons from building fully air-gapped, multi-tenant AI/ML environments on Kubernetes and OpenShift AI, with a strong focus on GPU-backed workloads:
- Workload isolation — namespace boundaries, network policies, pod security standards
- GPU partitioning — MIG, time-slicing, preventing noisy-neighbor GPU contention
- RBAC patterns — data scientists vs platform engineers vs model deployers
- Supply-chain security — container image signing, model provenance, registry policies
- Governance — audit trails, model registries, compliance controls for regulated environments
The core message: as AI scales from single-team experiments to shared enterprise platforms, security becomes a platform engineering problem. The same multi-tenant GPU patterns I presented at Red Hat Summit apply directly here.
Community Response
The talks clearly resonated. Here is what attendees shared on LinkedIn:
Davide Cioccia (Community Founder):
“Great energy at our latest AI Security Engineers Community Netherlands meetup in Amsterdam. Brian Vermeer from Snyk showcased the security and data privacy challenges of AI applications powered by LLMs, and how ‘old-fashioned’ vulnerabilities still play a major role. Luca Berton shared practical insights on building fully air-gapped, multi-tenant AI/ML environments on Kubernetes and OpenShift AI, with a strong focus on GPU-backed workloads.”
Mahan Yarmohammad Tajari (AI Engineer, NextPax):
“A huge thanks to Brian V. for his eye-opening presentation about Security for AI applications which is a major priority for us at NextPax as we continue to enhance our systems. This was followed by a brilliant session from Luca Berton with a great talk about Multi-tenant Platform Engineering for GPUs and AI model hosting. Thank you to everyone involved for sharing such invaluable knowledge!”
Why AI Security Needs Platform Engineering
The evening reinforced a theme I keep seeing across KubeCon, Red Hat Summit, and now security-focused communities: AI security is not just about prompt injection and guardrails. It requires:
- Infrastructure isolation — air-gapped environments where models cannot phone home
- Resource boundaries — GPU quotas that prevent denial-of-service via resource exhaustion
- Supply chain integrity — signed models, verified containers, trusted registries
- Observability — you cannot secure what you cannot observe
- Multi-tenancy by design — teams sharing GPU clusters need hard boundaries, not just promises
This is why platform engineering and security engineering are converging. The platform is the security boundary.
Join the Community
The AI Security Engineers Community is already planning the next Netherlands meetup. If you work with AI/ML systems and care about security, this is one of the best communities to join:
- AI Security Engineers Community — Netherlands
- Follow Davide Cioccia on LinkedIn for event announcements
