AI architecture review

What it is for

Most weaknesses in an AI system are decided at the whiteboard: which data the model can see, which tools an agent can call, whose permissions those tools run with, and where a person has to approve. An architecture review checks those decisions before they are built into everything around them.

It suits a team that is about to launch an LLM feature or an agent, is moving a prototype into production, or has grown a system faster than its design documents.

What we look at

• Data sources, their owners and their permissions, and how that data reaches the model (prompts, retrieval, memory, files).
• The models in use, where they run, which provider holds which data, and for how long.
• Agents and tools: what each tool can do, the identity it acts under, and which actions need a human.
• Secrets, tokens and service accounts along the path.
• Where output goes next: browsers, databases, tickets, emails, other agents.
• Logging and monitoring: whether you could reconstruct what the system saw and did.
• Tenancy: whether one customer’s data can reach another’s answers.

The UK National Cyber Security Centre organises secure AI development into four stages: secure design, development, deployment, and operation and maintenance.^⁠[1] The review covers all four, with most of the effort on design, where changes cost least.

What you receive

A trust-boundary diagram of the system as it is, a set of findings in plain language, and a target architecture: the design we recommend, with the order in which to get there. Each finding carries its mapping under the TriOngle Method, so your security, engineering and governance teams read the same record.

How it runs

We agree the boundary of the system and the questions that matter to you, read the design material, interview the people who built and run it, and inspect the configuration where we can. No attack testing is part of this scope; that is S1 AI red teaming and adversarial testing.