How Drel produces an AI security review

Every Drel review starts by rebuilding the AI system from its repository and design docs: components, models, data flows, tools, trust boundaries, hosting model, and deployment context. Where the code and docs leave something open, the architect answers a short set of guided questions, so the review has the information required to produce specific, system-relevant output.

The model 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), NIST AI RMF, and the EU AI Act. 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 realized 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 step 1 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.

From the design and the code, Drel maps how an attacker would get from an entry point to a target: each step of the path, and the controls that block it. Direct and indirect prompt injection, system prompt extraction, excessive agency and tool misuse, RAG permission bypass, and cross-tenant leakage.

Drel checks the controls it can verify in your code (IaC, configuration, API specs, agent code). A path whose control is missing is a control gap. Drel derives the paths from the design; it does not run attacks, and it never marks a control verified on its own.

For a control that fails, Drel proposes the change that makes the control's check pass and puts it in a Jira ticket. Your developer merges it; when the ticket is done, Drel checks the merged pull request and comments the result. Drel never writes to your repository or opens pull requests, and a reviewer decides what counts as evidence.

For each required control, Drel tracks the evidence state — how confident we are that the control is actually in place, based on what the repository and the design docs show:

• Explicit — the code or the docs directly show the control is implemented
• Inferred — the control is implied by architectural decisions in the system model
• 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 review does not have 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.

A clearance is valid for the system as assessed. Drel re-checks it when the code changes, runs as a gate in your CI, and answers agents that ask for the clearance over MCP. A change that adds a model, provider, or tool reopens only the parts it affects. Every review also names the re-assessment triggers that invalidate the current clearance:

• 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
• The reassessment date set when a risk was accepted
• Scheduled periodic review (typically annual)

The clearance decision is derived from the control gap analysis and the facts the architect confirms (what the approval is for, whether the system is live, third-party dependencies), not generated by an AI model. Until those facts are answered, the review is On hold, provisionally. It is a structured five-state decision:

• Approved — to production: all required controls are evidenced, no blockers, and the AI Committee has signed
• Conditional — to production once the named conditions are met
• Restricted pilot — a pilot, only once its entry conditions are met; production is blocked
• On hold — not yet, not even a pilot: fix what is listed and re-submit
• Declined — not as designed: fundamental architecture problems mean the system 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 check reads specific artifacts in the repositories you connect — infrastructure definitions, policy files, tool manifests — and reports what it observed at a named commit, with the evaluator version, so you can reproduce it. It tells you which part of a control it covered, because one check rarely evidences a whole control.

It does not read your running system, and a repository commit is not proof of what is deployed. Where a requirement cannot be evidenced from source, Drel says so and leaves it to human attestation rather than inferring a pass. A check can pass, fail, or abstain — and the record states which, together with the source that was read and the scope it covered.

Drel works from your repository and design docs: code, infrastructure definitions, architecture descriptions, and specification documents. It does not:

• Connect to production systems or scan running workloads
• Ingest live telemetry or monitor production traffic
• Run attacks against your systems, in production or anywhere else
• Access model weights or training data
• Certify, attest, or guarantee any compliance outcome

It produces the security clearance your AI Committee signs before a system ships. Runtime monitoring, posture management, and production penetration testing are separate tools that sit alongside it.