Skip to content

AI-SEC · Path 3: Govern and protect

Secure GenAI and Agent Threat Modeling

Two days after which you hold a threat model, a data flow diagram and a test plan for a real application instead of a list of theoretical risks.

Duration
2 days
Group
up to 12 people
Format
In-house · Remote · In the lab
Language
German or English
Price
€15,800 flat, plus VAT

Who this track is for

For security and governance owners together with engineering who need to secure a GenAI or agent application. Ideal when an application is about to go live or already runs and its protection should become systematic.

Who it is not for

Not for teams without a concrete application that only want an overview. For the executive-level overview, the Sovereign AI Executive Briefing (AI-EXEC) is the better fit.

Starting situation

Your first GenAI application with a knowledge connection or an agent with tool access is ready, but the security review is missing. Classic threat models do not map cleanly onto prompt inputs, RAG sources and tool calls, and no one has recorded the full data flow.

This exists after the track

  • A data flow diagram of your application from input through model, knowledge sources and tools to output
  • A threat model that carries a STRIDE-style method over to GenAI and agents
  • A catalogue of concrete protective measures: guardrails, permissions and output filters, assigned per threat
  • A test plan that makes it verifiable whether a measure works
  • A prioritised residual risk list with owners

Prerequisites

Basic knowledge of application architecture and information security. You need a real application to examine, at least as an architecture sketch.

Preparation before the track

You bring a description of your target application: which models, which knowledge sources, which tools and permissions, which user groups. From this sketch the shared data flow diagram is built on day one.

What's included

  • Two on-site or remote days with Dino Bordonaro and up to twelve participants
  • Threat modeling template for GenAI and agents with data flow notation
  • A reference frame along known OWASP LLM risk areas as a checklist, in our own wording
  • Measures and test plan template to continue in-house
  • Access to the lab environment for the demonstrations and a 30-minute follow-up call after four weeks

Agenda

Day 1

09:00

Why GenAI carries different threats

Prompt injection, unsafe outputs, data leakage through knowledge sources and tools. Core question: where does this differ from classic application security and where does it not?

10:30

Data flow diagram of your application

We draw the full flow: input, model, RAG sources, tool calls, output. Exercise: every trust boundary is marked and named.

13:30

Carrying a STRIDE-style method over to GenAI

We work through the threat categories and translate them onto prompt, context, tools and output. The OWASP LLM reference frame serves as a checklist so no category is forgotten.

15:30

Collecting threats on your application

Exercise on your data flow diagram: per trust boundary we name plausible attacks. Day result: a first threat model with prioritised threats.

Day 2

09:00

Live demonstration in the lab

On a prepared environment we show how a prompt injection works through a RAG source and what an over-permissioned tool gives away. No customer data, only to understand the effect.

11:00

Protective measures per threat

Guardrails, least-privilege permissions, output filters, source checks. Decision per threat: which measure, which effort, which residual risk remains?

14:00

Building the test plan

For each measure a test that proves its effect. Exercise: for each important threat we formulate a concrete test case with an expected result.

16:00

Residual risks and handover

We gather what remains and name owners. Day result: threat model, measures catalogue, test plan and prioritised residual risk list for your application.

Exercises and lab share

On the second day live demonstrations in the lab environment show the effect of prompt injection and over-broad permissions. The threat model and test plan are built on your real application.

Platforms

Delivered on your premises, remotely or in our enterprise lab. The demonstrations run in a prepared environment without customer data, your threat model works with your architecture sketch, not with production systems.

Transfer evidence

The completeness of threat model, measures catalogue and test plan at the end of day two is reviewed, each on your application. Attendance and content are documented in an audit-proof way.

Artifacts you take home

  • Data flow diagram of your application with marked trust boundaries
  • Threat model with prioritised threats
  • Measures catalogue with guardrails, permissions and output filters
  • Test plan with concrete test cases per measure
  • Prioritised residual risk list with owners

Optional extensions

  • Evaluation, Observability and Guardrails (AI-EVAL) for measurably securing your application in operation
  • AI Risk Classification Lab (AI-RISK) to classify the application beforehand
  • Evaluation, Observability and Guardrails (AI-EVAL) for ongoing monitoring of the implemented measures

Boundaries

The track delivers model, measures and test plan as a draft. It does not replace implementation, a penetration test mandate or a managed security service.

Frequently asked questions

Do we have to bring a finished application?

No, a solid architecture sketch is enough. What matters is that models, knowledge sources, tools and user groups are named, because that is where the data flow diagram and threat model come from.

Do you just copy the OWASP LLM list?

No. We use the known OWASP LLM risk areas as a reference frame and checklist so no category is missing, and we carry them over with our own method onto your concrete application. The result is your threat model, not a copied list.

Do you attack our system in the process?

No. We model threats and show their effect in a prepared lab demonstration. Your team leaves with a prioritised test plan and works through it internally or with a testing partner.