AI Systems Architecture Review: Designed for Production, Then Red-Teamed

What we evaluate

We review the whole system, not one layer of it — scoped the way an attacker would scope it, not the way a slide deck would:

• AI / application architecture — how the pieces fit together, and whether the design was ever written down on purpose.
• Agent topology — how multiple agents are arranged, who talks to whom, and where control passes between them.
• Model selection — evaluated against cost, capability, and risk, not parameter count.
• Tool permissions — whether tool access is scoped and task-bound, or broad and granted for convenience.
• Identity — non-human identity and delegation: whose behalf an agent acts on, and what scope was actually consented to.
• Data flows — what feeds training and retrieval, and what should never reach either.
• Trust boundaries — the exact points where agent output crosses into action, and whether it's validated there or just trusted.
• Cloud infrastructure — the production environment the system actually runs on, across AWS, GCP, and Azure.
• Security controls — guardrails as enforcement, distinct from evals as measurement, and whether either exists.
• Evaluation methodology — structured scoring, assertions, and traces, or the absence of any.
• Observability — full tracing of multi-step agent workflows and reasoning paths, not just an uptime dashboard.
• Cost — per-call and per-task cost attribution, not a surprise on the aggregate bill.
• Failure modes — what happens when a step fails, and whether that failure is contained or cascades.

How it runs

We start with the architecture as it actually exists — diagrams, code, configuration, and the people who can answer for design decisions — and map it against the list above: topology, trust boundaries, identity, data flows, infrastructure. Then we run the same adversarial lens we use in red-team engagements against that map, probing the boundaries we just found rather than a generic checklist. A diagram tells you what the system is supposed to do; only the adversarial pass tells you what it will actually do under pressure.

It's fully remote, rules of engagement are agreed in writing before anything is touched, and it's run by the same senior people end to end. This is a principal-level review, not a staffing engagement — we don't embed for months; we tell you what's true about the system and how to fix it.

What you get

• Architecture assessment — a clear, written read on the system as designed, including where the design was never actually made explicit.
• Threat model — the realistic ways this specific architecture fails or gets abused, tied to the trust boundaries and agent topology we mapped, not a generic checklist.
• Prioritized remediation plan — every finding ranked by severity and impact, with concrete fixes, not vague advice.
• 90-day implementation roadmap — a sequenced plan your engineers can execute without us in the room.

Scope & engagement

Typically 2–4 weeks, fully remote, scoped to the systems and environments you name up front. Rules of engagement are agreed in writing before we touch anything. We assess and design — we don't embed for months. The deliverable is senior judgment, not a seat on your team.