Pre-production AI clearance
Before an AI system handles real users or production data, you need a structured security gate. Drel threat-models the system, checks the controls it can verify in your code, proposes the fixes, and produces the security clearance and evidence pack that make that gate defensible.
Why a clearance gate matters
AI systems fail in ways that traditional software doesn't. Prompt injection, retrieval poisoning, tool misuse, data leakage through memory — these are not bugs you catch in a standard code review. They require a different kind of pre-production review.
A pre-production clearance answers one question: is this system ready to handle real users and real data, and what conditions apply? Without a structured answer, teams ship on confidence rather than evidence. The difference matters when something goes wrong.
The two gates
Most production AI systems require at least two clearance gates:
- Pre-pilot clearance. Before the system is exposed to real users, even in a limited pilot. The threat model is complete, critical controls are in place, and conditions for the pilot are named.
- Pre-production clearance. Before the system handles production traffic and production data. All control gaps from the pilot are resolved or explicitly accepted as residual risk with an owner.
Drel supports both gates. The same assessment workspace carries the system from initial review through to the production security clearance.
What Drel produces
For a pre-production clearance, Drel produces:
- A system-specific threat model — not a generic checklist, but threats identified for the architecture, tools, and data flows of this system.
- A required controls list — every control that must be in place before pilot, and every control required before production.
- Attack paths: how an attacker gets from an entry point to a target, derived from the design, with the controls that block each path. Drel does not run attacks.
- Proposed fixes: the change that makes a control's check pass, in the Jira ticket. When the ticket is done, Drel checks the merged pull request and comments the result.
- A control gap analysis — controls not yet implemented or evidenced, with explicit lifecycle gate assignments.
- A clearance decision — one of five states (Approved, Conditional, Restricted pilot, On hold, Declined) with named conditions and re-assessment triggers.
- An evidence pack — exportable PDF with threat model, control plan, gap list, decision memo, and sign-off record.
What triggers a re-assessment
A clearance is valid for the system as assessed, and Drel re-checks it when the code changes, with a gate in your CI, and agents can ask for it over MCP. A change that adds a model, provider or tool reopens only the parts it affects. These changes trigger a re-assessment:
- 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 clearance reaching the end of its validity (by default 12 months for Approved, 6 for Conditional, 90 days for a restricted pilot)
Each re-assessment trigger should be named in the original clearance decision, with an owner. Drel records these triggers in the security clearance so they don't get lost.
What slows a review down
The main source of delay is an incomplete picture of the system. Drel's first step, Model, rebuilds it from the repository and design docs: components, models, data, tools and trust boundaries. What the code can't show, such as hosting model or who the users are, comes from the building team.
Drel's system intake guide lists the information a complete review needs. Running through it with the building team before the security review is the most effective way to reduce review time.