AI security review for AppSec engineers

AppSec programs built around STRIDE, attack surface analysis, and code review handle traditional software well. AI systems introduce attack surfaces that sit outside this model: prompt injection through untrusted inputs, retrieval poisoning through the vector store, tool misuse by an autonomous agent, privilege escalation through a delegation chain, and data leakage through model outputs.

These are not edge cases. They are the primary threat surface of any LLM application, RAG pipeline, or agentic workflow. And they require a different review methodology — one designed for AI architecture, not application code.

Drel is not a replacement for your threat modeling tool or your code review process. It is a purpose-built layer for the AI-specific review that sits between those activities:

• AI system intake.Captures the architecture, components, tools, data flows, and trust boundaries specific to AI systems — the information your standard intake forms don't ask for.
• AI-specific threat model. Generates threats against the agentic graph, retrieval pipeline, MCP surface, and model output path — mapped to OWASP LLM Top 10, OWASP Agentic Top 10, and MITRE ATLAS.
• Control mapping. Maps threats to required controls with lifecycle gates: what must be in place before pilot, what must be in place before production.
• Clearance record. Produces a signed, versioned clearance decision that closes the review loop — the artefact your sign-off process requires.

Traditional AppSec tooling does not cover:

• Indirect prompt injection. Malicious content in retrieved documents or tool outputs that hijacks agent behaviour. Not detectable by SAST — it is a runtime semantic attack on the model.
• Retrieval authorization gaps.The RAG retriever surfaces documents the user should not see, because chunking and embedding don't respect document-level ACLs. Not a code bug — an architectural gap.
• Agentic blast radius. An agent with tool access to email, calendar, and CRM can cause significant damage from a single injected instruction. The scope of damage depends on tool permissions — not on code.
• Delegation chain exploits. In multi-agent systems, a compromised sub-agent can escalate permissions through the orchestration layer. This requires reviewing the delegation model, not the code.
• MCP tool surface. MCP servers expose tools described in natural language. Tool descriptor poisoning, over-scoped credentials, and missing audit logging are structural risks in the deployment, not the code.

The common pattern: an AppSec engineer owns the AI security review as a gate in the design review phase. They use Drel to:

1. Run the intake with the AI team.The structured intake surfaces architecture decisions the team hasn't documented — tool permissions, trust boundaries, data flows, hosting model.
2. Review the threat model.The AI-specific threats are generated, reviewed, and supplemented with the AppSec engineer's domain knowledge of the organisation's specific risk posture.
3. Produce the control plan. The required controls and lifecycle gates become the checklist for the build phase — handed to the engineering team as acceptance criteria.
4. Record the clearance decision. The signed clearance decision closes the design review gate and creates an audit trail. Re-assessment triggers are named so changes to the AI system automatically flag a re-review.

Drel complements, not replaces, your existing AppSec tools. Your STRIDE-based threat modeling tool handles the application layer. Drel handles the AI layer — the LLM, the retrieval pipeline, the agentic tools, the MCP surface. Both produce inputs to the pre-production security gate; the clearance records are separate artefacts covering different attack surfaces.