Every team in your company is shipping AI right now — a chatbot here, a copilot there, an agent pilot in a third team. Each one hand-picks its own vector store, its own framework, its own memory and identity pattern. Four applications, four architectures.
Because every architecture is novel, every security review starts from zero. Slow when it happens; skipped when the deadline wins. Neither outcome is the reviewer’s fault. And the same questions get re-litigated every time: Is the index multi-tenant? Where does the filter run? What identity does the agent hold?
The exposure is real — customer data in shared indexes, agents holding production credentials — and it compounds with the second application and the third. Here is the uncomfortable conclusion: you cannot review your way to safety at AI speed. The bottleneck is not effort. Nothing is standard, so nothing is reusable — not the review, not the fix, not the evidence.
The answer is not more review. It is a paved road: decide the safe shape once, so the safe path is the easy path — and then verify, automatically and with evidence, that the standard is what actually shipped. Four moves, in order.
1. Standardize the architecture
Nearly every AI application is the same two paths. One writes documents into a store as vectors. The other answers a question by finding the nearest few and putting them in a prompt. Everything else is detail — which is why one reference architecture can cover almost every team: sources, chunking, embedding, the vector store; user, identity, orchestrator, guardrail, model; memory, tools, logging, configuration.
Decide that shape once and three things follow. The trust boundaries become known. The threat model gets written once, before the next team is even formed. And variance becomes the exception that earns a review, rather than the norm that overwhelms it.
Do it for agents on day one, not later. An agent is not a chatbot with extra steps — it holds credentials, it can take actions (send, spend, delete, deploy), and its inputs are untrusted by nature, because tool results and retrieved documents flow back into the prompt. The second wave of applications will be agents; the reference shape has to cover them before the first one ships. And when there is more than one agent, the shape needs four more rules: one identity per agent, re-authorization at every handoff, memory partitioned per agent, and the router treated as a trust boundary.
2. Standardize the data plane
AI applications leak where data moves, not where it sits. The security consequence of the two-path shape is that retrieval decides what the model is allowed to see, and it happens before the model is involved at all. Whatever separates one customer’s documents from another’s has to live in that retrieval step — not in the prompt, and not in the model’s judgement.
So four rules go into the standard rather than into each team’s discretion:
- Tenancy is declared. The boundary is a named field, written down — never inferred from a name or assumed from a folder.
- The filter runs before the search, derived from the caller’s identity — not applied to the results afterward, and not taken from a value the caller supplied.
- Retention is a setting. Every memory store carries a lifetime someone chose. Session data should not outlive the session.
- Writes carry an author. Memory records which agent wrote what; a shared store without that turns agents into anonymous authors.
The prompt is downstream of every one of these. None of them asks the model to enforce anything.
3. Standardize the controls
With a standard architecture and standard data-plane rules, the control set becomes finite — and a finite, named control set is something a scanner can check and a report can cite. “Each team does something sensible” is not.
Eight domains, cut from the architecture above rather than from a model-training lifecycle, since a team consuming a foundation-model API trains nothing: ingestion integrity · service and store exposure · retrieval entitlement · generation controls · agency limits · memory discipline · observability · identity and entitlement. Each maps onto work your auditors already recognise — DASF, the OWASP LLM lists — so findings arrive in vocabulary your security team already reports in.
The eight are asked twice. At design they are a checklist: one decision per domain, made cheaply, before anything exists. Before release they are a verification: is what you decided actually true in the code, the cloud, and the stores? That symmetry is what makes “did we build what we decided?” an answerable question — and it is what most programs lack, because the design review and the assessment usually come from different checklists, run by different people, months apart.
4. Verify automatically
Pillars one to three exist in some form in every maturity model. Almost no program has the fourth, and without it the first three decay into folklore — a standard nobody verifies is a document everyone assumes is true and nobody has tested since the quarter it was written.
Verification starts with intent, written down. “Is this index multi-tenant?” has no checkable answer until someone records one. A multi-tenant index and a single-tenant one are byte-for-byte identical; the most security-critical fact about the system lives only in someone’s head until it becomes an artifact. Once it is an artifact, a machine can compare it to reality. Two rules govern that comparison: a declaration can create findings but never remove them — declaring a store single-tenant silences nothing — and declared is not verified: when what runs disagrees with what was declared, the disagreement is itself the finding.
Then the honest edge. A control-plane read verifies configuration, code paths, and declared intent. It verifies that a guardrail is attached, not that it blocks anything; that a filter runs before the search, not that it derives the right predicate. Runtime behaviour is a different discipline — recommended and referred out, never counted as covered. And anything unreadable lands on a coverage ledger, named and counted. Nothing unread is ever presented as clean.
What this buys you
Think of it as the books and the audit. Nobody accepts “we think we’re profitable” from a CFO; financial confidence works because there is a ledger and a reconciliation against the bank statements. Most AI estates today run with neither — the equivalent of a company keeping its position in the CFO’s memory and never closing a quarter. Written intent is the books. Verification is the close.
What comes out is a report you can defend line by line — to an auditor, a customer’s security team, or a board — and a number that moves: re-read after a quarter of fixes, and the difference is real, not tester variance. Teams ship on the paved road without waiting for bespoke review, because the proof is generated rather than argued. The alternative is finding out by incident.
Skulk runs the two halves of this model as engagements: a design review in the architecture phase — the eight domains as a checklist, no access needed — and an automated posture assessment before release, across AWS, Google Cloud, and self-hosted stacks. Scoping costs nothing.