How Drel produces an AI security review

Every Drel assessment starts with a structured intake that captures the AI system's architecture, components, data flows, tool access, hosting model, and deployment context. This is not a free-text prompt — it is a guided intake that ensures the assessment has the information required to produce specific, system-relevant output.

The intake drives two parallel processes: first, the construction of a system model (the architecture graph — components, trust boundaries, and data flows), and second, the selection of the relevant threat taxonomy based on the system's architectural characteristics (RAG pipeline, agentic workflow, tool-using agent, fine-tuned model, etc.).

Drel uses a structured threat taxonomy built from the major AI security frameworks: OWASP LLM Top 10, OWASP Agentic Top 10, MITRE ATLAS, MAESTRO (CSA), and NIST AI RMF. The taxonomy is not a checklist — it is a graph of threat patterns with architectural preconditions.

Each threat pattern has:

• Architectural preconditions — what system characteristics must be present for this threat to apply
• Attack vector — how the threat is realised against the system
• Impact scope — what the blast radius looks like if the threat succeeds
• Required controls — the defensive measures that mitigate the threat
• Framework mappings — which framework items this threat corresponds to

The system model from the intake is matched against the threat taxonomy to produce a system-specific threat model — not a generic list of all possible AI threats, but the subset that applies to this architecture.

Each threat in the system-specific threat model maps to one or more required controls from Drel's control library. Controls are not generic security best practices — they are AI-specific mitigations drawn from the frameworks and validated against real-world assessment practice.

Every control has a lifecycle gate: some controls must be in place before pilot (before any real users touch the system), others before production (before the system handles production data at scale). This gate structure means the clearance decision is not just “pass/fail” — it is specific about what must be in place at each deployment stage.

For each required control, Drel tracks the evidence state — how confident we are that the control is actually in place, based on what the system description tells us:

• Explicit — the system description directly states the control is implemented
• Inferred — the control is implied by architectural decisions described in the intake
• Assumed — the control is present in standard deployments of this type but not confirmed
• Missing — the required control is not described or implied — a confirmed control gap
• Unknown — the intake does not contain enough information to determine whether the control is present

A control gap (Missing evidence state on a required control) is the primary input to the clearance decision. Gaps at the pre-production lifecycle gate are the blockers that the AI Committee must resolve before the system can receive an unconditional clearance.

The clearance decision is derived from the control gap analysis, not generated by an AI model. It is a structured five-state decision:

• Proceed — all required controls are evidenced; no blockers
• Conditional — proceed with named conditions that must be met (most common first-review outcome)
• Restricted pilot — limited deployment while specific controls are implemented; re-review required
• Hold — significant control gaps; further work required before any deployment
• Decline — fundamental architecture problems; the system as designed should not be deployed

The disposition is made by the security architect or AI Committee reviewing the evidence record — Drel produces the analytical foundation (threat model, control plan, gap list), but the decision is owned by the human reviewer.

A clearance is valid for the system as assessed. Re-assessment triggers are named events that invalidate the current clearance and require a new review. Every clearance record includes triggers for:

• Model or model version change
• New tool or MCP server added to the agent
• Change in training data or fine-tuning
• Scope expansion — new data types, new users, new use case
• Security incident involving the system or its components
• Scheduled periodic review (typically annual)

Drel is a design-time review tool. It works from documentation — architecture descriptions, system intake forms, specification documents, code repositories. It does not:

• Connect to production systems or scan running workloads
• Ingest live telemetry or monitor in real time
• Perform penetration testing or dynamic analysis
• Access model weights or training data
• Certify, attest, or guarantee any compliance outcome

It is the design-time layer that produces the clearance record your committee signs before a system ships. Runtime monitoring, posture management, and penetration testing are separate tools that sit alongside a design-time clearance record.