Decide the shape once,
before you build it.

A fixed-fee working session that standardizes the architecture, the data plane and the controls — and leaves you with a written record of your own intent. No access, no scan, no credentials.

Three things to standardize, in this order

You cannot review your way to safety at AI speed — not when every team hand-builds its own stack and every review starts from zero. The alternative is a paved road: decide the shape once, and let the safe path be the easy path. Each move below makes the next one cheap.

1 · Standardize the architecture

One reference shape for RAG and agent applications — ingestion, retrieval, orchestration, memory, tools, identity. Trust boundaries become known, the threat model is written once, and variance becomes the exception that gets a review rather than the norm. The shape covers multi-agent topologies too: the router is a trust boundary, handoffs re-authorize, and every agent holds its own identity.

2 · Standardize the data plane

AI applications leak where data moves, so four rules go into the standard rather than into each team’s judgement: tenancy is declared, not inferred; the filter runs before the search, derived from the caller’s identity; retention is a setting someone chose; and writes carry an author. The prompt is downstream of all four — none of them asks the model to enforce anything.

3 · Standardize the controls

Eight control domains, cut from the architecture above rather than from a model-training lifecycle, and mapped onto DASF and the OWASP LLM lists so findings land in vocabulary your auditors already use. A finite, named control set is the thing a scanner can later check and a report can cite.

The eight control domains

In the design phase these are a checklist — one decision each, made before anything exists. Before release, the same eight become the verification. That symmetry is what makes “did we build what we decided?” an answerable question.

1 · Ingestion integrity — do source permissions survive into the index, and what happens to sensitive content before it is embedded?
2 · Service & store exposure — where does the store listen, and what authenticates in front of it?
3 · Retrieval entitlement — is the filter applied before the search, derived from the caller?
4 · Generation controls — guardrails in and out, and the model treated as untrusted, with no authority.

5 · Agency limits — tool allow-lists, approval gates, iteration and spend caps.
6 · Memory discipline — session binding, partitioning, enforceable retention, provenance, tenant-keyed cache.
7 · Observability — what is logged, where it goes, and whether a user can be correlated to an action.
8 · Identity & entitlement — what each component runs as, what one compromise reaches, where credentials live.

How the engagement runs

A working session, half a day to a dayWith the people actually building it — not a questionnaire, and not a policy exercise.
One decision per domainWalked in order, with the trade-offs named. Some answers are “we would have to check” — those are the useful ones.
Your intent, written downThe output is a record in your own repository: what is multi-tenant, what is sensitive, what each agent may do, which identity it holds. Dated, versioned, yours to keep.

What it is not

Not a scan — nothing is read, because in this phase there may be nothing to read yet.
Not an audit or a certification.
Not a document that sits on a shelf: it is the input the assessment later measures against.

No repository access, no cloud role, no store credentials — nothing to provision, and nothing for your security team to approve.

Already shipped? The review still works — it is simply a different conversation, and its output becomes the declared intent the posture assessment compares against.

Decide the shape once,before you build it.