Three scoped engagements, priced per piece of work rather than by the hour. Everything I would
tell you is already free on this site — what you are buying is someone applying it to
your system, in writing, with the tradeoffs named.
You are shipping something with a language model in the middle of it. It reads content
somebody outside your company wrote, or it holds a credential, or both. Someone has asked
whether it is safe and the honest answer is that nobody has looked properly.
Most of the work I get asked for is one of four shapes:
A launch gate. The feature is built, the date is set, and security has
not signed off on something nobody on the team has reviewed before.
A customer question. An enterprise buyer sent a security questionnaire
with AI-specific items and the answers are currently guesses.
An incident, or a near one. Something got through, or someone
demonstrated that it could, and the question is how much else is exposed.
A team that wants to stop asking me. They want the judgement in-house
rather than a dependency on an outside reviewer.
Read this first, honestly
The field guide and the
pattern library are the whole method, free, with nothing held
back for the paid version. A competent engineer with a week can run their own review
from those two pages. If that describes your team, do that instead.
Hire me when you want it done faster, by someone who has done it before, and written
down in a form you can hand to a board or a customer.
01
Architecture review.
E-01
One system, mapped and prioritised
Most common
I take one system, place it against the seven layers and the twelve defence patterns on this site, and tell you where it actually breaks and in what order to fix it.
What happens:
A scoping call, then access to whatever you can share — design docs, prompt assembly code, tool definitions, retrieval config. Reading code is useful but not required.
I map the system to one of the four architectures and name the six primitives, which on its own usually surfaces components nobody owns.
Every boundary gets the same question: what crosses it, and do you trust it.
Findings written up, each with the failure it enables, the pattern that answers it, and what that pattern will cost you in latency, engineering and false positives.
A walkthrough call with the engineers, not just the manager who commissioned it.
What you get
A written report you can hand to a customer or a board, ordered so the first three items are the ones that hold even when an injection succeeds.
Who it's for
Teams with one system going live, or one already live that nobody has reviewed with this specific lens.
What it isn't
Not a penetration test and not a compliance certificate. I am reading your architecture, not attacking your production environment.
02
Team workshop.
E-02
Six sessions, using your own traffic
Best value per head
The curriculum this site is built on, run live for your engineers, product owners and security people in the same room. The point is a shared vocabulary, so the next design review does not need me in it.
The sequence:
The machine. Six primitives, four architectures. Everyone names your system out loud.
The defect. Why instructions and data share one channel, and the seven boundaries that follow from it.
Recognition. The attack index run as a drill — the tell shown, the answer hidden, the lookalike argued about.
The arithmetic. Your real traffic volumes through the base rate calculator. This is the session people remember, because most teams have never run these numbers on themselves.
What to build. The twelve patterns in tier order, argued against your actual backlog.
The seat. The training, scored, as a group.
What you get
A team that can run the next review without me, and one shared language for describing these risks across security, product and engineering.
Who it's for
Groups of roughly six to twenty. Remote or in person. Can run as six sessions or compressed into two days.
What it isn't
Not a certification, and not a substitute for a review. A workshop teaches judgement; it does not tell you what is wrong with your specific system.
03
Standing design review.
E-03
A second pair of eyes as you ship
Ongoing
A fixed amount of review time each month, spent on whatever you are about to ship. Design documents before they are built, tool definitions before they are wired up, an argument about whether an agent needs that scope.
What you get
Review at the point where changing your mind is still cheap, which is worth several times the same hours spent after launch.
Who it's for
Teams shipping AI features continuously rather than once. Usually starts after a review or a workshop.
What it isn't
Not on-call, and not incident response. If something is on fire right now, say so in the first line of your email and I will tell you honestly whether I am the right person.
How
How I work.
Everything ends in writing. A call where I say useful things and you take notes is not a deliverable. You get a document.
Findings carry their cost. Every recommendation names what it will cost you in latency, engineering time and wrongly blocked users — the same rule the pattern library follows. A finding without a cost is an opinion.
Priority is by blast radius, not by severity label. The first items are the ones that hold even when an attack succeeds, because those are the only ones that do not depend on being right about the text.
I will tell you when the answer is no. If the honest finding is that your system is fine and you should spend the budget elsewhere, that is what the report says.
Priced per engagement. Scope agreed in writing before anything starts, so the number does not move.
Your NDA is fine. Send it with the first email if you need one in place before you can describe the system.
Limits
What I don't do.
Stated plainly, because the fastest way to waste both our time is a scoping call about something I was never going to take.
Penetration testing and red teaming. I review architecture and read code. I do not attack your production systems, and if that is what you need you want a firm that does it properly and carries the insurance for it.
Compliance certification. A review from me is evidence you can put in front of an auditor. It is not an attestation and I will not pretend otherwise.
General application security. If the question is your cloud posture or your authentication flow, I am not the right person.
Model training, evaluation or fine-tuning work. This site is about the application around the model, and so am I.
Anything offensive. I do not build jailbreaks, write payloads, or help you test another company's system.
Start
What to send.
The button below opens your mail app with these questions already in it. Answer as many as
you can — rough answers are fine, and an incomplete email is much better than no email.
I will reply with whether I am the right person, a scope, and a number.
1. What the system does, in one line.
2. Which shape is it closest to?
A1 plain assistant · A2 retrieval · A3 agent with tools · A4 multi-agent
(see thefilter.hamcodes.com/build/#architectures)
3. What can it reach? Data, tools, credentials, and whose
authority it acts under.
4. Roughly how many requests a day, and what share is public.
5. What already exists? Any guardrail, egress control, scoped
tokens, logging of allow decisions.
6. What is prompting this — a launch, a customer questionnaire,
an incident, an audit?
7. Timeline, and who needs to read the output.
If a question does not apply, write "not sure" and move on. Question 5 is the one people
skip and the one that changes the scope most, so it is worth five minutes.
Send the enquiry.
Opens your mail app with the subject and the questions above already filled in. Nothing
is submitted through this page, no form service sees it, and nothing is tracked.
Priced per engagement, quoted after you send the questions above, and agreed in writing before anything starts. I do not publish a rate card because the same words describe a two-day review of one assistant and a three-week review of a multi-agent platform, and pretending otherwise would mean quoting one of us wrong.
How quickly do you reply?
Within a couple of working days, including when the answer is that I am not the right person for it. If something is live and going wrong, put that in the first line and I will move faster.
Do you need access to our code?
It helps, and it is not required. The parts that matter most are prompt assembly, tool definitions, retrieval configuration and what credentials the thing runs under — often a design document and a conversation cover it. If you cannot share anything before an NDA, send the NDA first.
Can you sign our NDA and security paperwork?
Yes. Attach it to the first email rather than waiting for a call, and it will not slow anything down.
We only want the workshop, not a review. Is that fine?
Completely. They are separate engagements and neither requires the other. Teams often do the workshop first and decide afterwards whether they still want an outside review — a good number decide they do not, which is the intended outcome.
Why is all the material free if you sell reviews?
Because the method is not the scarce thing. Anyone can read the twelve patterns; applying them to a specific system, under a deadline, and writing it in a form that survives contact with a board is the part that takes practice. Publishing the method is also the only honest way to let you judge whether I am worth hiring before you pay anything.