In-company workshop · one day
One day. Your own agentic system, its boundaries and a responsibility matrix an auditor can follow.
An example: in April 2026 an AI agent deleted a company's production database and its backups in nine seconds, despite explicit instructions not to (PocketOS).
Your organisation is deploying AI agents, or soon will. They plan, act and talk to other systems, with your credentials. Something will go wrong; something always does. What matters is whether you can answer four questions. Where are the boundaries? Who owns them? Who notices when they are crossed? Who fixes it? In one day you map your own agentic system and leave with documented answers to all four.
Talk to me on LinkedInThis is already measurable
188
agent-inflicted incidents in one year across 7,246 monitored deployments, as counted by Cyera.
CVSS 9.3
for EchoLeak, which exfiltrated data from Microsoft Copilot without a single click.
OWASP published a Top 10 for Agentic Applications in December 2025, because the LLM Top 10 no longer covered it. These are vendor and operator reports, and they age fast.
The day, in three blocks
Morning
See where it breaks
Draw the trust boundary of your own system, then look at real incidents to see where it broke.
Afternoon
Threat-model it
Three questions anyone at the table can ask. The big one: where is data leaving your control? Then a walk through the OWASP Agentic Top 10 against your system.
Close
Give every control an owner
For that I use OLRA, the responsibility-allocation model I derived from CSA's AI Controls Matrix. You map the result onto frameworks such as ISO/IEC 42001, so an auditor can follow it.
What you take away
- A responsibility matrix for your system: per control, the owning role and the evidence you will ask for.
- One shared answer to "who do we call when this happens", agreed by all roles in one room, in one day.
- Two follow-up sessions, included, to test that answer against practice.
No model theory.
Who it is for
People who hold one of four seats around an agentic system.
The product owner or engineering lead who answers for what the system does.
The builder: the engineer who connects the agents to tools and credentials.
The security or cloud architect: the one who draws the trust boundary.
Risk, GRC or audit: the one who asks for the evidence.
Come as a team, or on your own. Bring one agentic system, live or planned, and the architecture as far as it exists. Five to twelve participants.
What I learned: Threat modelling starts with knowing which security controls actually exist, otherwise there is no trust boundary to draw. From the follow-up I took away how MCP clients, tasks and short-lived OAuth tokens fit together, and that an agent should have its own identity rather than borrow the user's.
What I can do better: I now know which questions to ask before an MCP server or coding agent goes live: where the credentials live, what the agent's identity can reach, and where the isolation boundary is.
The workshop provided one of the most practical frameworks for AI security that I have encountered. The concept of analysing AI systems through security zones and trust boundaries gives a clear and actionable way to identify risks and controls.
Since attending, I have used this approach in customer discussions around Copilot and agentic AI. It enables conversations to move beyond vague concerns or blanket restrictions and instead focus on understanding which data crosses which boundary, what controls exist at that point, and who is accountable for them.
The framework is equally valuable when evaluating emerging technologies such as MCP gateways. It helps separate marketing claims from actual security value by focusing on the precise controls being applied at each trust boundary.
Your instructor
I am Dr. Peter van Eijk. I train CSA's cloud and AI security curricula, and I developed the OLRA model.
Interested, or want to see if it fits your system?
Talk to me on LinkedIn