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, in five steps:

• Model. Rebuilds the AI system from its repository and design docs: the components, models, data, tools, and trust boundaries your standard intake forms don't ask for.
• Threat model. Maps every attack path against the agentic graph, retrieval pipeline, MCP surface, and model output path to OWASP LLM Top 10, OWASP Agentic Top 10, and MITRE ATLAS, with the controls each path requires and their lifecycle gates: what must be in place before pilot, and before production.
• Attack. Maps the attack paths through the system from its design (prompt injection, tool misuse, RAG permission bypass, cross-tenant leakage): how an attacker gets from an entry point to a target. A path whose control is missing is a control gap.
• Fix. Proposes the change that makes each control's check pass, puts it in a Jira ticket, and checks the merged pull request.
• Monitor. Re-checks the system when the code changes, with a gate in CI. The signed, versioned security clearance is the artifact your sign-off process requires.

• The threat model, as a file. Each threat with its component, severity, attack path, controls and OWASP LLM / Agentic Top 10 and MITRE ATLAS ids. Export it as Excel, CSV, Markdown or JSON, or copy it as Markdown into a SAT or a Jira epic.
• Jira tickets for the controls. Connect Jira Cloud once, then create a ticket per control, one at a time or several at once. Each ticket carries its priority, due date, owner, acceptance criteria and framework labels, and its key is kept on the control.
• A proposed fix, checked at the merged commit. Link the review to its GitHub repository through the Drel app. Drel proposes the change that makes a control's check pass and puts it in the Jira ticket; your developer merges it. Drel never opens pull requests or writes to the repository. When a tracked ticket is marked done, Drel looks for the merged pull request that mentions it and, for controls a file check can read (IAM policies, Terraform, OpenAPI, agent tool manifests), runs the check at that commit and comments the result in Jira. Other controls are closed by a person, with a pull request or a document as evidence.
• Your tools' findings beside the review. Upload SARIF 2.1.0 or Checkov JSON from CodeQL, Semgrep, Trivy, GitLab SAST or Azure DevOps, and those findings sit with the AI findings on the review.
• The committee's copy. What AppSec produces becomes the security clearance the AI Committee signs, backed by the evidence pack, with no second write-up.

Traditional AppSec tooling does not cover:

• Indirect prompt injection. Malicious content in retrieved documents or tool outputs that hijacks agent behavior. 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, from the design review to the gate before production. They use Drel to:

1. Model the system with the AI team. Drel rebuilds it from the repository and design docs, and walking that model with the team surfaces what hasn't been 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 organization's specific risk posture.
3. Check it in the repository. Drel checks the required controls it can verify in the code and re-checks it when the code changes. A control that isn't in place stays open.
4. Fix it through Jira. The required controls and lifecycle gates become Jira tickets with their acceptance criteria, priority, due date and a proposed fix. When a ticket is done, Drel checks the merged pull request.
5. Monitor it and sign the clearance. The signed security clearance closes the gate and creates an audit trail. Drel re-checks the system when the code changes, and a change that adds a model, provider or tool reopens only the parts it affects.

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; your threat model and Drel's security clearance are separate artifacts covering different attack surfaces.