AI security review for security architects

AI systems require a different kind of security review than traditional software. The attack surfaces are different — prompt injection, retrieval poisoning, tool misuse, delegation chain exploits — and the evidence requirements for a clearance decision don't map to a standard pentest report or threat model template.

Most security architects run the first few AI reviews on a spreadsheet or in a Confluence page, then hit the same problems: the record doesn't survive an audit, the evidence trail is loose, and when something changes in the AI system six months later, there's no clear record of what was assessed and what was accepted.

Drel is the workspace where you run a structured AI security review from start to signed clearance. Drel rebuilds the system from its repository and design docs, threat-models it, checks its controls in your repository, proposes the fixes with Jira tickets, and re-checks it when the code changes.

The output is designed for a security architect working alone. No committee required to start. You run the review, sign it as the responsible engineer, and issue a security clearance backed by an exportable evidence pack. When your organization later wants committee sign-off, you invite them — the record upgrades without starting over.

A complete AI security review in Drel runs in five steps:

1. Model. Drel rebuilds the AI system from its repository and design docs: components, models, data, tools, and trust boundaries. A written description or a spec document works too.
2. Threat model. Drel generates a threat model specific to the system, not a generic checklist. Every attack path is mapped to OWASP LLM Top 10, OWASP Agentic Top 10, MITRE ATLAS, the EU AI Act and more, with the controls each path requires, their lifecycle gates (before pilot, before production) and evidence requirements. Control gaps are listed explicitly.
3. Attack. From the design and the code, Drel maps the attack paths through the system: prompt injection, system prompt extraction, tool misuse, RAG permission bypass and cross-tenant leakage. A path whose control is missing is a control gap; you decide what counts as evidence of a control.
4. Fix. Drel proposes the change that makes a failing control's check pass and puts it in a Jira ticket. When the ticket is done, Drel checks the merged pull request and comments the result. Drel never writes to your repository.
5. Monitor. You sign the security clearance, which exports as a structured markdown and PDF evidence pack. Drel re-checks the system when the code changes, with a gate in CI, and a change that adds a model, provider or tool reopens only the parts it affects.

Drel is worth using when you need a record that survives external scrutiny — an auditor, a regulator, a customer security questionnaire, or a future version of you trying to understand what was assessed eighteen months ago.

It is especially useful for organizations running multiple AI systems in parallel, where the same architect is responsible for reviewing all of them and the portfolio starts to blur without a structured record per system.

If you're reviewing a single internal prototype that will never face external scrutiny, a spreadsheet is probably enough. Drel pays back when the stakes are higher than that.

Drel works from your repository and design docs. It does not run attacks against your systems, in production or anywhere else, and it does not scan running workloads, monitor production traffic, or ingest live telemetry. It is not a production penetration test, a runtime firewall, or a compliance certification service.

For AI systems that need runtime monitoring, runtime firewalls, or posture management of deployed workloads, those are separate tools that sit alongside a security clearance.