AI architecture and guardrail design
Where the trust boundaries go, what an agent is permitted to do, how retrieval respects access control, and what happens to model output before it reaches a shell, a query or a browser.
AI Consulting
Everyone shipped an AI feature. Almost nobody designed one.
An LLM feature is an input field that reaches your data and takes actions on behalf of your users. Every assumption your application security model makes about inputs stops being true the moment it is added — and most organisations discovered that after shipping.
DesignBefore the incident
ISO 42001And the NIST AI RMF
EU AI ActClassification and obligations
PrivateDeployment option
Why AI features break the security model around them
Traditional application security rests on a clean separation between instructions and data. Code is trusted, user input is not, and the boundary between them is enforced by the interpreter. A language model has no such boundary — instructions and data arrive in the same channel, and the model's entire job is to follow whatever looks like an instruction.
That is prompt injection, and it is not a bug awaiting a patch. It is a property of how these systems work. So the design question is not "can the model be manipulated" — assume it can — but what is reachable when it is. What tools can it call, with whose permissions, over whose data, and who would notice? Those are architecture questions, and they are cheap to answer before a feature ships and expensive afterwards.
This is the advisory engagement: the design review, the governance framework and the deployment decision. The adversarial testing is a separate engagement — see AI red teaming — and the inventory of what you already run is a platform module, the AI governance register. Most organisations need all three, in roughly that order, and we will say plainly which one you actually need first.
Coverage
Where we help
Design, governance and deployment. The testing has its own page.
Agent permission design
The single highest-leverage decision in an agentic system: what identity it acts as, and what that identity can do. Most incidents in this category are permission problems wearing a prompt-injection costume.
AI risk assessment
Per system and per use case, against the factors that actually drive risk — the data it reaches, how autonomously it acts, whether its output lands on a person, and whether anybody can intervene.
Governance framework
An AI policy set, an accountable owner, an approval route for new systems and a review cycle — built so it survives contact with teams who want to ship.
ISO 42001 and NIST AI RMF readiness
The AI management system, run off the same control set as your existing ISMS rather than as a second programme.
EU AI Act position
Establishing role and risk class, and what follows from each. Most organisations are deployers of far more AI than they provide, and the deployer obligations are the ones nobody has read.
Private and on-premises AI
Where sensitive data cannot leave your estate: model selection, deployment architecture, and the trade-offs nobody mentions until you are committed.
RAG architecture review
Retrieval that respects your access control, tenancy that holds, and an index that does not itself become the disclosure.
Approach
How an advisory engagement runs
Understand what you have, decide what it should be, leave you able to run it.
-
01 · Inventory
What AI is actually in use — including the features that arrived inside products you already pay for. This is where most of the exposure turns out to be.
-
02 · Risk and classification
Per system: the data, the autonomy, the human impact, and the regulatory position. Recorded, with the reasoning, because a determination you cannot produce is not a determination.
-
03 · Architecture review
Trust boundaries, agent permissions, retrieval and output handling, for the systems that matter.
-
04 · Governance
Policy, ownership, an approval route and a review cycle that a shipping team will actually use.
-
05 · Hand over
Set up so your people run it. The register lives in SemperWise One, so the programme continues after we leave.
Deliverables
What you actually receive.
The report is the product. If it cannot be acted on by a developer and understood by a director, we have not finished.
An AI inventory and risk position
Every system with its data, its autonomy, its owner and its classification.
Architectural recommendations
What to change in the system rather than in the prompt. Prompt-level fixes are the ones that regress.
An AI governance pack
Policy, ownership model, approval route and review cycle, mapped to ISO 42001 and the NIST AI RMF.
EU AI Act determinations
Role and class per system, with the reasoning recorded for the ones you will be asked about.
Private deployment design
Where the answer is that the data cannot leave — architecture, model choice and the honest trade-offs.
Is this for you?
Talk to us if any of these are true.
If none of them are, say so on the call and we will tell you honestly whether this is the right piece of work — or point you at the one that is.
Book a scoping call- You are about to add an AI feature to a product that handles real customer data.
- An agent in your product can call tools, APIs or databases rather than only producing text.
- You are building retrieval over internal documents and more than one customer's data is in the index.
- An enterprise customer has started asking how your AI features are governed.
- You want to use AI on sensitive data and need it to stay inside your own infrastructure.
- You need an ISO 42001 or EU AI Act position and do not know where to start.
How we work
Six steps, and no surprises.
The same engagement model applies to every piece of work we take on, so you always know what happens next.
01
Scope
A 30-minute call, then a written scope: what is in, what is out, what we need from you and what it costs. Nothing starts before you sign it.
02
Authorise
Rules of engagement, testing windows, escalation contacts and a signed authorisation. Out-of-hours windows where production cannot take the load.
03
Test
Automated coverage first, then manual testing where judgement is required. Critical findings are reported the day we confirm them, not at the end.
04
Report
One report a developer can act on and an executive can read, with evidence, reproduction steps, business impact and a fix for every finding.
05
Remediate
A walkthrough call with your engineers. We answer questions on the fix, not just the finding.
06
Retest
A free retest cycle to confirm the fixes hold, and a clean summary you can hand to a customer, auditor or board.
Questions
AI Security & Governance — answered.
The questions clients actually ask during scoping. If yours is not here, ask it directly.
Is this the same as AI penetration testing?
No, and they answer different questions. This is advisory: where the trust boundaries should go, what an agent should be permitted to do, how the programme is governed, and where the system should run. AI red teaming is the adversarial engagement that tries to break a specific system. Design first is cheaper; where a feature is already live, we usually scope both and start with the testing, because it tells us what the design review should prioritise.
We use a commercial model — is the vendor not responsible for this?
The vendor is responsible for the model. You are responsible for what you connected it to. Nearly every failure in this category comes from the integration: the tool the model can call, the document it can retrieve, the identity it acts as, the output nobody sanitised. No vendor can design that for you, because only you know what you wired up.
Can we run AI entirely inside our own infrastructure?
Yes, and for some data it is the only defensible answer. The engagement covers model selection, deployment architecture and the trade-offs that are rarely discussed up front — capability against control, cost against latency, and the operational burden of running inference yourself. We will also tell you when a hosted model with the right contractual and architectural controls is the better decision.
Do we need ISO 42001?
Only you can answer that, but the pattern is clear: enterprise buyers are beginning to ask for it before letting an AI feature near their data, in the same way SOC 2 became a precondition a decade ago. If you are being asked, the good news is that an existing ISMS carries most of the underlying controls across — the platform runs both off one control set, so it is a mapping exercise rather than a second programme.
Where do we start if we have no idea what AI we are running?
With the inventory, and it is less work than it sounds. Go through the products you already pay for and record the AI features in each — that pass usually takes an afternoon and finds the entries nobody expected. The AI governance register is built for exactly that, and it computes the risk position as you go.
Next step
Get a written scope and a fixed price.
A 30-minute call, then a scope document with what is in, what is out and what it costs. No obligation, and no charge for the conversation.