Fee
Register to see indicative feesConfirmed in writing after scoping01 / Build & Advisory · Standard
AI Security Architecture & Threat Modelling
You are building AI into products or operations, and the security design is being made one decision at a time by whoever is closest to the keyboard.
Defend & RespondBuild and advisory
Typical duration
6 to 10 weeksDepends on the number of systems and integration pointsPrimary artefact
Threat modelPlus 2 moreWho leads it
Steve SharmaFounder & Principal04 / What this is
What AI Security Architecture & Threat Modelling is
A design engagement that produces a threat model for your AI systems and the target-state security architecture that answers it.
And what this service produces
It is the work that makes later testing cheap and later remediation unnecessary: controls designed in rather than retrofitted after a findings report.
05 / Who it is for
Built for a real assurance trigger, not a badge project.
01
This fits when
- Teams building AI into products or internal operations.
- Architecture functions asked to cover AI with no reference design.
- Organisations about to commission red teaming with no threat model.
- Anyone integrating third-party models into sensitive workflows.
02
The usual trigger
- An AI feature is in design and security has been asked to weigh in.
- An architecture review board has no AI reference pattern.
- A red team is being scoped and nobody has modelled the threats.
- Agents are being given system access.
06 / The obligation
The architectural decisions that determine everything downstream
Almost every serious AI security finding traces back to a handful of architectural decisions made early and rarely revisited: what the model can reach, what it is trusted to act on, where its output goes, and what happens at the trust boundary between the two.
Cheap at design, expensive afterwards
Those decisions are cheap to change at design and expensive afterwards.
A late boundary is a migration
A permission boundary drawn correctly in week two costs nothing; the same boundary drawn after an agent has been given broad system access is a migration.
Model before you test
This is why a threat model produced before testing is worth more than a findings report produced after it. It changes what gets built, rather than describing what was.
The most expensive AI security findings are architectural, and architecture is the one thing a test cannot fix.
07 / What you receive
Three artefacts. Each one yours to keep.
- 01
Threat model
What an attacker would want, the paths to it, and the trust boundaries that matter.
Threat model documentArchitecture team - 02
Target-state architecture
The security architecture for AI systems, with the control points named and justified.
Architecture document + diagramsEngineering - 03
Reference patterns
Reusable patterns for the AI integration types your teams will build again.
Pattern libraryArchitecture board
08 / Scope
The whole system is visible before work begins.
Threat modelling
- Attacker goals and capability per system
- Attack paths and trust boundaries
- Abuse cases alongside use cases
Architecture review
- Current-state review
- Data flows into and out of models
- Third-party and supply-chain dependencies
Target state
- Permission and isolation boundaries
- Input and output handling controls
- Logging, monitoring and detection design
Patterns
- Reference patterns for common integration types
- Guardrails and their limitations stated
- Review checklist for new AI systems
Handover
- Architecture board briefing
- Pattern adoption support
- Named internal owner
09 / Included / not included
A useful boundary is part of the deliverable.
Included
- Threat modelling
- Architecture review
- Target-state design
- Reference patterns
- Handover and architecture board briefing
Not included
- Implementation: We design. Building it is your team's work or separate scoped work.
- Adversarial testing: Red teaming is a separate service and validates this design rather than substituting for it.
- Model development: We do not build, train or fine-tune models.
- Tool selection: We are vendor-neutral and take no product margin. We will state requirements, not name a preferred product.
10 / How we do it
A traceable path from scope to evidence.
Discovery and current state
Systems, data flows and existing controls mapped.
Threat modelling
Attacker goals, paths and trust boundaries, per system.
Target-state design
Control points, isolation boundaries and detection design.
Patterns and handover
Reference patterns, architecture board briefing, named owner.
Mapped againstMITRE ATLASOWASP LLM Top 10NIST AI Risk Management FrameworkSABSA
11 / Timeline
6 to 10 weeks of work.
Elapsed time and customer effort are separated because they are not the same number.
Weeks 1 to 2
Discovery and current-state mapping
Systems, data flows and existing controls mapped.
Customer effort
Architecture and engineering access, plus three to four interviews.
Weeks 3 to 5
Threat modelling
Attacker goals, paths and trust boundaries, per system.
Customer effort
One half-day workshop per system.
Weeks 6 to 8
Target-state design and review
Control points, isolation boundaries and detection design.
Customer effort
Two review cycles with the architecture team.
Weeks 9 to 10
Patterns, board briefing and handover
Reference patterns, architecture board briefing and a named owner. The threat modelling workshops are the highest-value hours in the engagement and also the hardest to schedule, which is usually where the timeline moves.
Customer effort
One architecture board session.
Our work: 6 to 10 weeks
12 / Scope check
Test whether AI Security Architecture & Threat Modelling
is the right next move.
We will cover likely scope, cost and fit.
Book a confidential strategy sessionWith Steve Sharma, who would lead.13 / Who leads the engagement
Named lead. Direct assessment.
Your architecture lead
Steve Sharma
Founder & Principal
Facilitates every threat modelling workshop and authors the target-state design.
ASD-endorsed IRAP AssessorCISSPCREST
Every engagement has a named lead. Where a second executive or specialist is needed, they are named in the proposal and subject to client approval.
Review leadership record14 / Why Cybersecurity Link
Three decisions.
Accountability.
Design before testing.
A threat model changes what gets built. A findings report describes what was. The ordering is the whole argument.
Vendor-neutral by construction.
We take no product margin, so the design states requirements rather than naming a preferred stack.
Patterns outlast the engagement.
Your teams will build the next AI integration without us. The pattern library is what makes that safe.
15 / The boundary
What this engagement does not claim.
Implementation
We design. We do not implement.
We do not test architecture we designed either. Red teaming is a separate service.
Vendors
We are vendor-neutral and take no product margin.
The design states requirements. We will not name a preferred product.
Engineering
We do not build, train or fine-tune models.
Model development stays with your product and engineering teams.
What moves the fee
Per additional system in scope.
Where agents or multi-model chains add integration complexity.
Where the current-state architecture is already documented.
Scope confirmed in writing after discoveryThreat model and target-state architectureReference pattern libraryArchitecture board briefing and handover
18 / How this fits
Where this sits in the wider programme.
AI Security Readiness Assessment
If the organisational position matters more than the system design.
AI Agent Security
If agents specifically are the concern, that service goes deeper on permission design.
AI Red Teaming & LLM Security
The validation step, and it is cheaper and sharper when a threat model already exists.
19 / When this is not right
Sometimes the best recommendation is a smaller service, or a later date.
01
Nothing is being built yet.
Governance design is the better use of the budget.
02
A system is already live and the question is whether it holds.
Testing answers that faster.
03
You need the design implemented as well.
We do not implement, and we would rather say so than stretch. Talk to us about who can.
20 / FAQ
The questions that change the decision.
Before, almost always. Testing without a threat model finds the wrong things, and a red team scoped against a real model is both cheaper and sharper than one scoped against a guess.
No. We take no product margin, so the design states requirements and control objectives rather than naming a preferred stack. Your team or a partner selects against those.
No. We design and hand over, and we do not test architecture we designed. Both of those are conflicts we would rather avoid than manage.
Then this becomes a review rather than a design, and it is cheaper. We would scope it that way rather than pretending there is a greenfield to design into.
Longer than the threat model. Patterns tend to hold for a year or more; the threat model should be revisited on material architecture change.
21 / Next move
If AI Security Architecture & Threat Modelling is what you need, the next step is a conversation about scope.
A 45-minute conversation with Steve Sharma, who would lead the engagement: what your scope actually looks like, what it would cost, and whether this is the right service for you at all.