
Enablement and workshops
When AI Becomes the Attack Surface
A three-hour security briefing for teams building LLM applications, around the OWASP LLM Top 10.
For architects, developers and engineering leads building LLM-based features, for AppSec and platform teams, and for product leads responsible for a safe launch.
What you get
A risk map for your applications
Where the trust boundaries run: prompts, models, retrieval layers, tools, data sources and agents acting on behalf of users, and which architecture decisions create exposure.
Control selection
What belongs to prevention, what to detection and what to response, and why one control never covers all three. A checklist that stays with the team for future reviews.
A shared language for engineering and security
One model that lets both sides talk about the same risk in the same terms, and a set of questions to challenge every new LLM use case.
How it works
Attacker logic
How an attacker thinks about an LLM system, and how to tell apart threats that look similar but need different controls.
The ten risks on your system
Prompt injection and output handling, excessive permissions and agents, supply chain and dependencies, overreliance and information disclosure. Each one examined against the group's own architecture.
Choosing controls
Decisions on permissions, data access, validation, monitoring and human approval, while they can still be changed.
Format
- Duration
- Three hours, live on Teams or in person.
- Participants
- 15 to 40, in Hebrew or English.
- Preparation
- None. No installations, environment access or permissions. Participants need to know the systems they are building, because the examples are discussed against them.
- A fit for organizations that
- Build LLM-based features, use RAG, agents or tool calling, need security alignment before a wide rollout, or face SOC 2, ISO 27001 or ISO 42001 reviews.
FAQ
A penetration test finds exposures in a system that is already built. The briefing deals with the decisions that create the exposures: permissions, data access, validation, and where a person approves an action. Both are needed, at different stages.
Yes, and usually more so. Much of the exposure comes from ordinary engineering decisions, such as an agent that inherits a human user's permissions, or external content entering a prompt with no separation between instruction and content.
Yes. The usual next steps are a threat model for a specific solution, a targeted attack attempt before going to production, and a decision on how much autonomy to give an agent. All of these are part of delivery in the FDE model.
Contact
Tell us what you are building, on which infrastructure, and who needs to be in the room.
- info@applai-consulting.com
- Tel Aviv, Israel