How long does a review take?

It is scoped to be short — typically days, not weeks — because the value is in the findings and the fix list, not in the length of the engagement. Larger or more entangled systems take longer, and I will say so up front rather than pad a small one.

Do you need access to our code and infrastructure?

Read access to the code, the configuration and the logs, and a conversation with whoever runs it. I do not need write access to anything, and the review does not change your system. Access is arranged in whatever way your security policy requires.

Is this a sales exercise for a rebuild?

No. The deliverable is written so that your own developer can act on it. You can commission implementation separately, but the review does not depend on a rebuild or a follow-on contract.

Can you review a vendor's AI product we use, rather than something we built?

Partly. I cannot see inside a vendor's system, but I can review what you have granted it, what data flows to it, what it can do in your accounts, and whether the vendor's answers about all of that hold up. That is often the part that matters most.

What do we get at the end?

A written report: the failure modes and their blast radius, the cost accounting, the permission and data-access map, and a prioritised fix list with verification steps. Plus a call to walk through it, in plain language, with whoever needs to make decisions.

You already have AI in production and are not sure what it is doing.

AI systems review

A scoped developer review of an AI workflow, based on the code and evidence available. Findings, uncertainties, and suggested next steps are documented.

The situation

Start with one agent, one repository, and one business-critical workflow. We agree on the scope and price before access is granted. You receive a permission map, reproducible findings, and a ranked repair plan. Implementation is a separate choice; this is not a compliance certification or a promise of zero risk.

Plenty of businesses now have AI in production that was built quickly, by a contractor who has moved on, or by an enthusiastic team member, or by a vendor whose answers to 'what can it access' are vague. It works, mostly. Nobody is quite sure what it costs, what it could break, or what would happen if it went wrong at 3am.

We first establish whether the system fits my experience. For an agreed scope, I can inspect the implementation, reproduce specific issues, and document suggested next steps. This is a developer review informed by my own project work, not a comprehensive security audit or specialist assurance service.

How I approach it

Failure modes and blast radius

For each thing the system does, we ask: what happens when the model is wrong, what happens when the upstream service is down, what happens when the input is malformed or hostile, and how far does the damage travel before something stops it. The answer to that last question — the blast radius — is usually the most important finding in the review.

Cost and token accounting against real usage

Review the available logs, invoices, and actual calls for avoidable retries, oversized context, and missing limits. Where evidence is available, quantify the observed baseline. Where it is missing, specify the instrumentation needed instead of inventing a savings number.

Permission and data-access review

Document the permissions and data flows visible within the agreed scope. Unknowns remain explicit. This can help plan engineering work, but it is not an insurer-facing assurance report or an answer to every compliance question.

A fix list in priority order

Document observed issues, their practical consequences, and suggested verification steps. Unknowns and work needing a specialist are listed separately. Implementation can be scoped afterwards or handled by your own developer.

What gets delivered

Failure-mode and blast-radius analysis
Cost and token accounting against actual usage
Review of visible permissions and data flows
A prioritised fix list you can hand to any developer

What it costs to get wrong

A monthly AI bill that has become a line item nobody questions, where one retry loop accounts for most of it.
A system holding credentials far broader than its job, one prompt injection away from an incident.
A client security questionnaire you answer optimistically because nobody actually knows.
Finding out what the system could reach only when it reaches it.

Why you can believe this

The Sentinel and NexusTerm case studies show specific defects I investigated, repaired, and checked with regression tests. They are not evidence of a formal security-audit practice.

Explore the work Read the ai-os case study

Questions buyers ask

How long does a review take?: It is scoped to be short — typically days, not weeks — because the value is in the findings and the fix list, not in the length of the engagement. Larger or more entangled systems take longer, and I will say so up front rather than pad a small one.
Do you need access to our code and infrastructure?: Read access to the code, the configuration and the logs, and a conversation with whoever runs it. I do not need write access to anything, and the review does not change your system. Access is arranged in whatever way your security policy requires.
Is this a sales exercise for a rebuild?: No. The deliverable is written so that your own developer can act on it. You can commission implementation separately, but the review does not depend on a rebuild or a follow-on contract.
Can you review a vendor's AI product we use, rather than something we built?: Partly. I cannot see inside a vendor's system, but I can review what you have granted it, what data flows to it, what it can do in your accounts, and whether the vendor's answers about all of that hold up. That is often the part that matters most.
What do we get at the end?: A written report: the failure modes and their blast radius, the cost accounting, the permission and data-access map, and a prioritised fix list with verification steps. Plus a call to walk through it, in plain language, with whoever needs to make decisions.