Cloud and AI security training
Instructor-led private cohorts for your engineers and your security team — cloud security, AI and agent security, threat modelling, detection engineering — taught against real misconfigurations, with architecture review and AI security programme design when the gaps turn out to be structural.
When you need this
Your engineers are shipping AI features faster than your security team can learn to review them, and the review is turning into a rubber stamp.
The same class of finding comes back after every assessment, and writing it up a third time clearly isn't what fixes it.
A team owns production on AWS or Google Cloud without anyone who has done cloud security engineering before, and the on-demand video course isn't landing.
You've been asked to stand up an AI security programme and what's expected is a plan with owners and controls, not a policy document.
What we do
01
The curriculum gets written after we read your environment
Before dates are held we go through what your teams actually run: Terraform or CloudFormation, org and folder structure, IAM policy, the last assessment report, the tickets that keep reopening. Topics come out and go in on that basis, so an AWS platform team doesn't sit through GCP organisation policy and a detection team doesn't sit through IAM fundamentals. Where we've assessed you, your own findings become the worked examples.
02
Labs against real misconfigurations, not screenshots
We build disposable AWS and Google Cloud accounts containing the failure patterns we're teaching — a GitHub Actions OIDC trust policy with a wildcard subject claim, iam:PassRole into a service that will run anything, an SSRF-reachable app in front of an instance where IMDSv1 is still permitted, a project where the default compute service account still holds Editor, a GKE workload that can impersonate more than it needs. Attendees exploit it, fix it, then re-run Prowler and a Stratus Red Team emulation to see what changed. Controls from the CIS Amazon Web Services Foundations Benchmark and the CIS Google Cloud Foundation Benchmark get discussed as the outcome of that exercise rather than as a checklist to read. The labs live in our accounts, never in yours.
03
AI security taught to two different rooms
Engineers building on models need a different session from the security team reviewing them. The engineering track covers retrieval design, tool and function scoping, output handling, and where authorisation belongs when a model decides what to call — mapped to the OWASP Top 10 for LLM Applications and to MITRE ATLAS technique names, with excessive agency (LLM06) and vector and embedding weaknesses (LLM08) treated as architecture problems rather than prompt problems. The security track covers evaluating an AI feature somebody else built: threat modelling agents against the OWASP Agentic Security Initiative's ASI01–ASI10 categories, standing up a repeatable attack harness with promptfoo, PyRIT or garak, and reading the trace an agent leaves behind. Both rooms hear the same thing about input filtering — it's one weak control, and the defences that hold are tool scoping, isolation, egress restriction, and human checkpoints on irreversible actions.
04
Threat modelling and detection engineering as working sessions
The threat modelling workshop takes one of your real services: data flow on the board, trust boundaries argued out loud, STRIDE and attack trees applied until the room disagrees about something that matters. The detection workshop runs against your own telemetry — write Sigma rules for CloudTrail and Google Cloud audit logs, fire the matching ATT&CK cloud technique, watch the rule miss, tune it, then commit it with tests so it survives the next engineer. Attendees leave with artifacts they wrote, not notes they took.
What you receive
- A curriculum written for your stack and your audience split, agreed before anyone books a day out
- Lab environments we build, run, and tear down, handed over as Terraform so your team can rebuild them later
- Slides, lab guides, and solution walkthroughs your team keeps and can re-run internally
- The artifacts produced in the room — a threat model for a real service, detection rules against your own audit logs, an agent tool-permission review
- A written debrief naming what the sessions exposed, separating knowledge gaps from architecture problems
- Where the gap is structural: an architecture review or AI security programme outline, with NIST AI RMF and ISO/IEC 42001 mapped to controls you would actually implement
How it runs
Scope
days
Discovery call, audience split, topics cut to what's useful, dates held.
Build
1–2 weeks
Curriculum written to your architecture; lab accounts built with the misconfigurations we plan to teach.
Deliver
days per cohort
Live sessions in half-day blocks so people can still do their jobs. Labs run with us in the room or on the call.
After
included
Written debrief, materials handed over, and a follow-up session once the team has applied it to their own systems.
Durations are indicative. Actual scope and price are fixed after the scoping call.
Questions we get asked
- Do attendees get a certification?
- No. We don't run exams, we aren't an accreditation body, and we don't issue badges. You get the materials, the lab environments, and an attendance record. Some professional bodies let members self-report training hours — check yours, because we won't claim credits on your behalf.
- How many people can attend?
- Usually six to twelve. Delivery is senior-only — the engineer teaching is the one running lab support — and past roughly fifteen people the labs stop working: attendees fall behind quietly and the session degrades into a lecture. Larger groups get split into separate cohorts on separate dates rather than merged into one room.
- We already pay for an on-demand security training platform. Why this?
- Keep the platform. A video library is the cheaper way to cover a hundred engineers on fundamentals, and we're not going to pretend otherwise. This is for the smaller group making architecture decisions, and the value is the part video can't do: breaking your patterns, in your context, with someone answering the awkward follow-up question. If what you need is broad, low-cost coverage, we're the wrong purchase.
- We don't want a course — we want someone to review our architecture and help design the programme. Can you do that instead?
- Yes, and it's often the better sequence. The advisory work is architecture review and AI security programme design: current-state review, threat model, control set mapped to NIST AI RMF and ISO/IEC 42001, and a prioritised plan with owners. It's the same engineer, scoped as review and design work, with training added later only if the plan calls for it. We map to ISO/IEC 42001 controls; we don't certify against it and can't audit you for it.