AI security review: an audit of what your AI can do
An AI security review of your system's write paths, approvals, credentials, environments and model boundaries, with written findings and a retest.
This review is engineering work by people who build these systems. It is not a certification, it does not produce a SOC 2 attestation, and it is not a penetration test by a certified third party. Brdy AI holds no security certification of its own; our security page lists exactly what we do and do not hold.
What the review covers
An AI system in operations is a model wrapped in software that holds credentials to your ERP, storefronts, mailbox and messaging. The model is the least dangerous part. The review is organized around what the software can change, because that is where a wrong action becomes a wrong purchase order or a duplicated shipment.
Write paths
Every path that writes outside the system's own database. For each: which credential it presents, whether running it twice creates two of something, and what it leaves behind when it fails halfway.
Approvals
Which actions require a person, whether the gate can be bypassed by a retry or a timeout, and whether each approval is recorded and attributed to the operator.
Credentials
Where secrets live, what each is scoped to do, whether any appear in logs, prompts or repositories, and who can rotate them. More scope than the write path needs is a finding.
Environment separation
How many copies of the system are running, which secrets each copy holds, and which scheduled jobs are enabled where. A staging stack with production credentials is a production system nobody is watching.
Data handling
What customer and commercial data the system reads, where it is stored, how long it is kept, what reaches logs and what reaches the model.
Model-provider boundaries
Whose API keys call the model, whose terms govern the prompt, whether a local model is available where data must not leave, and whether the model can write directly or only hand a draft to deterministic code.
We press hardest on the last point. Where the model drafts and the software executes, the list of possible actions is short and reviewable. Where the model can call any tool it is given, the list depends on the prompt and can only be tested, not audited. Our post on agent failure modes covers what happens without that boundary.
How the review runs
Scope first. Which system, which deployments of it, which external systems it touches, and what is out, so the findings cannot be read as covering things nobody looked at.
Three inventories. Before reading code, we ask for the list of stacks actually running, which secret is installed in which, and which scheduled jobs are enabled on each. Producing these finds problems before anyone reviews them.
Enumerate the writes. Every path that changes something outside the system's own database, with its credential, idempotency and behavior on partial failure. The route list can be long; the write list is usually short, and it is the one audited carefully. The architecture that keeps it short is described in read widely, write narrowly.
Test the claims. Every sentence in your documentation or sales material that describes a control gets one question: name the code path and flag state that make it true in the running deployment. A claim that fails is a finding even when the code exists, because someone will rely on the sentence.
Write up, fix, retest. Findings go to you in writing, with a severity, the evidence and a specific remediation. You fix them on your timetable, with your own team if you prefer. We then retest each one against the running deployment and record what closed.
What you receive
A findings document your own security team can read without us in the room. It states scope and method, lists what was not reviewed, records who did the work and what access was used, and for each finding gives what it is, where it is, how we confirmed it, its severity and its fix. After remediation it carries a retest record per finding. We do not publish client findings, in paraphrase or in aggregate; our post on audit findings patterns explains why the only findings we publish are ones we raised against ourselves.
The patterns we find most often
Four show up in nearly every system that has shipped for a while, including our own. The claim runs ahead of the wiring: a capability described in the present tense that is merged but not deployed, or flagged off. Features reviewed instead of writes: a checklist that never ends while the few paths touching money and stock go unexamined. The deployment treated as separate from the system: code correct everywhere, configuration wrong in one stack. Numbers without a method: figures nobody can trace to a measurement.
Between July 7 and July 15, 2026, a staging copy of Butler, the operations tool we built for PPC International, still held production Slack credentials. For nine days it posted duplicate end-of-day drafts into live channels. The code was correct in every stack; the configuration was wrong in one. The three inventories above exist because of this.
PPC International is a Brdy Holdings portfolio company. An incident in a system we own, in our own channels, not a client's. We publish it because a vendor with no incidents to describe has either been lucky, been small, or is not telling you.
What is not offered
No certification of any kind. No SOC 2 report or attestation; a review by us does not make you, or us, SOC 2 anything. No penetration test as a certified third party: we exercise your write paths and approval gates, but a pentest report with an accredited firm's name on it has to come from that firm. No self-graded mapping to a standard, because a self-authored alignment table is a marketing document.
The review answers the question an attestation does not: what can this software do to my business, with whose approval, and what happens when it is wrong. On a build with us it runs before production cutover as part of the custom AI software process; otherwise it runs alone.
Common questions about an AI security review
Is an AI security review the same as a penetration test?
No. A penetration test tries to break in from outside and is usually delivered by an accredited firm whose report an auditor will accept. This review works from inside, with access you grant, and asks what the system can change and under whose approval.
Can you review a system another vendor built?
Yes, given read access to the code, the configuration of each running deployment and the credentials inventory. The method is the same whoever wrote the system. A vendor that will not provide those is itself the first finding.
What access do you need, and for how long?
Read access to the repository, the deployment configuration of every stack in scope, and the logs and approval records, for the agreed period only. We do not need production write access. The document records what was granted and when it was revoked.
Do you review the model itself?
We review how the model is used: what data reaches it, whose keys call it, whose terms govern the prompt, and whether its output can write directly or only produce a draft that code and a person act on. We do not evaluate the provider's model internals.
Tell us what the system can write to and who approves it today, and we will scope a review around that.