A practitioner framework for the AI cybersecurity ecosystem. Most AI security programmes stop at the first thing and call it a programme. This is the rest of the work, written for the practitioners who have to do it.
They scan the model. Check the dependencies. Write the policy. Brief the board. The part that looks most like the security work we already knew how to do gets finished first, and the finished feeling is mistaken for a finished programme.
Every AI capability you are deploying for productivity is also a capability someone will turn back on you.
The team treats AI as something to defend against. The work becomes restriction. Policies forbid use, controls limit deployment, the security team becomes the office of saying no. The result is a defending organisation that is institutionally slower than the attacking organisation, because the attacker has no policy committee. This is the path of caution. It feels safe. It loses the speed race on purpose.
The team treats AI as productivity to capture. Tools are deployed at velocity, copilots roll out across business units, and the security work is reduced to a check at the build gate. Nothing meaningful protects the systems in production or governs what they can do. This is the path of enthusiasm. It feels modern. It exposes the organisation faster than caution would have.
Two halves of the work must travel together, across all four domains. Secure AI as a system. Use AI as leverage. Same programme. Same timeline. Same seriousness.
Secure AI across build, runtime, defence and autonomy.
And use AI across all four.
Provenance, runtime controls, governance over agents, hardening of the AI tools your defenders rely on. The technical and operational work to make sure your AI does what you intended, and only that.
AI to write better code, find threats faster, build detections at scale, run autonomous response, and close the speed gap with attackers who have already made this choice. Leverage, not just risk.
This is not a balance to strike. It is a discipline to hold. Any domain where one side is missing is a domain where you have left a structural advantage on the table or accepted a structural risk you did not name.
BRDA is not a maturity progression. The domains run in parallel. Progress means progress in all four, weighted by your highest risk. Each domain carries both sides of the mandate and ends with a diagnostic question you should be uncomfortable answering.
Security moves from bottleneck to automated accelerator, hardening the software supply chain at the exact speed of development.
Can you produce, today, a provenance record for the model in your highest-risk AI system?
You stop managing alerts and start managing incidents. AI at runtime shrinks the threat lifecycle and turns defence into a proactive, real-time operation.
Name the last adversarial input your AI system encountered in production that you did not generate yourself.
Defence changes from reactive and compliance-driven into a dynamic, self-testing immune system.
Is your security team allowed to use AI as aggressively as the people attacking them are?
The agentic SOC. Security operates at machine speed, with human oversight reserved for irreversible action — not routine triage.
For your most capable agent, what is the worst thing it could do in the ninety seconds before a human could intervene?
The framework names twenty-four capabilities. Most programmes cannot work on twenty-four things at once. If your overall maturity is below 2.0, do these six things, in this order. Each one unlocks the next.
Build an AI Bill of Materials. List every model in production or pre-production, the data it was trained or tuned on, the dependencies in its inference path, and who owns it. This is the foundational artefact.
One system, not all of them. Pick the AI system with the highest blast radius if it failed. Deploy an inference proxy with input and output guardrails, PII and secret redaction, and full telemetry retention.
Roll out an AI assistant for first-pass alert triage and incident summarisation. Treat it as privileged infrastructure from day one. Define what it can read and write, log every interaction, and validate its outputs.
List every autonomous agent already in your environment, including the ones marketing or finance or engineering deployed without telling you. For each, document what it can touch, what credentials it holds, and what the worst case looks like.
Enable LLM-augmented static analysis in your code review pipeline. Start with one team or one repository. Measure: vulnerabilities caught before merge, false positive rate, developer satisfaction.
Walk the senior security team through all twenty-four capability cells. Score on the 0 to 4 scale. The dashboard will tell you the truth of your programme in numbers. Use the priority list to plan the next quarter.
A framework without a technology landscape underneath it stays at the level of principle. This is the landscape. Capability classes only, no vendors named, so the framework outlasts product churn.
Every row covers both sides of the mandate. Every column carries a different commitment of time, capital, and risk appetite.
A credible programme holds capabilities in all three horizons across all four domains. The mix shifts toward Horizon 1 for operational maturity, toward Horizon 2 and 3 for strategic positioning.
A bank may already treat ephemeral task-scoped credentials as foundational because that architecture exists for service accounts. A manufacturer may treat SOC copilots as emerging because the SOC is still largely manual.
The framework is meant to be discussed and adapted, not adopted as a fixed taxonomy.
Available today. Expected in every credible programme. Operational expenditure, not strategic investment. If you do not have these, you have a foundational gap.
1 to 3 years out. Taking shape and being deployed by leading organisations. Standards maturing but not universal. The strategic investments that determine whether you keep pace with the threat.
3 plus years. Research, pilot, or just-emerging. Standards forming. Scout these, pilot small, maintain awareness. The point is not to wait, the point is to know what is coming so it does not surprise you.
The framework is published as a working instrument, not a piece of theory. Below are four concrete uses, in increasing order of commitment.
Walk a senior team through the four diagnostic questions. Score honestly. The lowest score is where next quarter's work starts. Not the question that is easiest to improve. The one you most wanted to skip while reading.
Reorganise reporting against the four domains. Each domain owned, both sides of the mandate as named workstreams, quarterly readout. Any domain missing one side of the mandate is a structural gap, not a sequencing choice.
Use the technology landscape and portfolio worksheet to assess coverage across all 24 capability cells. The shape of the gaps tells you where the next two years of investment goes. Balances operational, strategic, and scouting spend explicitly.
The board does not need to understand prompt injection. They need to see that the organisation is operating across four named domains, both sides of the mandate in each, three horizons of investment. Fits on one slide. Survives scrutiny.
Published openly. Attribution is appreciated, permission is not required. If you build something interesting on it, I would like to hear about it.
Run the full self-assessment online. Sixty-four capabilities across the four domains. Live results dashboard. Download a structured PDF report when you finish.
The complete framework. Foreword, the dual mandate principle, all four domains in depth, the horizon model, the technology landscape, the starter sequence, and guidance for use.
PDF Diagram · .pngThe full BRDA-by-horizon technology landscape on a single image. Capability classes across all four domains and three horizons. For decks, walls, or wherever the framework needs to live.
High-res imageAdopting the framework, building on it, or running into something it does not cover yet — I am happy to hear from you.