What we can show you, and what we cannot.
This page exists for the person who has to sign off on sending us data. It is written to be read adversarially. Where we have a practice, it is described exactly. Where we have no artefact, this page says so rather than describing an intention as though it were a control.
We hold no security certification today, and we will not claim one until an audit is complete.
Brdy AI has no external clients yet. Every control described on this page runs in a system we built for a company we own. None of it has been tested against a third party's data, and we do not present it as though it has.
Certifications and attestations
What Brdy AI holds
None.
We hold no certification, attestation or third-party report of any kind. We are not going to describe ourselves as aligned with, mapped to, or working toward a standard in order to fill this box. When that changes, the certificate will appear here with its issuer, scope and dates, and you will be able to request the report.
What Brdy AI does not hold
- SOC 2 Type I or Type IINot held
- ISO/IEC 27001Not held
- Third-party security auditNever commissioned
- Independent penetration testNever commissioned
- Written information security policyNot published
- Standard DPANot published
- Subprocessor listNot published
- Cyber liability insuranceNo certificate on file
- Errors & omissions insuranceNo certificate on file
If any of these is a hard requirement for your procurement process, we are not the right vendor for you today. Say so on the first call and we will tell you straight.
Separately: ERP Automate, a Brdy Holdings portfolio company, publishes that it is working toward SOC 2 Type II and does not hold a certification today. That is a different company with a different product, and it confers nothing on Brdy AI. It is noted here only so you are not surprised to find it elsewhere.
The rules the system follows
There is one system in production: Butler, an operations tool built for PPC International. PPC International is a Brdy Holdings portfolio company — we own it. This is internal work, not a client reference, and the constraints below are the ones actually enforced in that codebase.
“Butler reads widely and writes narrowly, always into the system of record, always through a human. It never writes a storefront directly — every price and every listing goes into Odoo, and Odoo's existing connector exports it.”— Butler architecture doctrine, internal engineering document
- The model drafts; the software executes.The LLM support desk writes replies. It does not place, amend or cancel orders. Order actions are executed deterministically by Butler's own code paths.
- A human approves the send.Nothing the model drafts reaches a customer without a person approving it.
- Writes fail closed.The partner-facing merchant API — which creates and confirms real ERP sale orders and deducts real inventory — uses fail-closed error handling and idempotency keyed on the order reference, so a retried request cannot duplicate an order.
- Credentials live in a secrets manager and are never logged.Secrets are held in Infisical and excluded from application logs.
- Schema changes are idempotent and versioned.The database is migrated by raw, idempotent SQL migrations rather than an ORM, so every change to the schema is a reviewable artefact.
Approvals, and what we do not call an audit log
What is true
Approval events in Butler are recorded and attributed to the operator who approved them. Where a human gate exists, you can see that it was passed and who passed it.
What is not true
It is not a unified, system-wide audit log. It does not cover every action in the system, and we do not describe it as though it does. If your requirement is a complete, tamper-evident audit trail across all actions, that is a build we would have to scope, not a feature we can point at.
We are calling this out because the phrase “full audit trail” has appeared in our own marketing copy and it overstates what is built. The accurate claim is the one above: every approval is attributed.
Data handling, residency and retention
Scope note: the practices below are documented for Butler and for ERP Automate, the products we have built and run. They are not yet written into a Brdy AI consulting agreement. Treat them as how we work, not as terms you have been granted, until they appear in your contract.
AES-256 at rest. TLS 1.2 or higher in transit. Credentials held in a secrets manager and excluded from logs.
A dedicated single-tenant instance per customer. This is an architectural property of how the system is deployed, not a measured outcome.
Hosted in the United States. Self-hosting in your own environment is available. We do not currently publish the name of the underlying hosting provider.
Your data is exported to you on request.
The instance is deleted within 10 days of termination.
Contact-form enquiries are deleted after 24 months.
Model providers and systems that touch data
Model providers
Anthropic and OpenAI, called with the customer's own API keys, or a locally hosted Ollama model where no data should leave the instance at all. Because the keys are yours, the commercial and data-processing relationship with the model provider is yours, and their terms — not ours — govern what happens to a prompt.
We do not train models on your data and we do not have a mechanism that would allow us to.
Third-party systems Butler integrates with
These are integrations, not partnerships, and none of them implies a certification or an endorsement. In the one deployment that exists, these are the external systems Butler exchanges data with:
This is a description of one system's integration surface. It is not a subprocessor list: we do not publish one, because the hosting provider behind it has never been written down.
Standards we map to
None. We publish no mapping to the NIST AI Risk Management Framework, to the OWASP Top 10 for LLM Applications, or to the SOC 2 Trust Services Criteria, because no such mapping has been produced.
We could write one in an afternoon. We have not, because a self-authored alignment table is a marketing document, and a set of controls we have graded ourselves against reads well right up until somebody tests it.
Mapping to a standard is not certification against it. If we ever publish a mapping here, it will say who produced it, when, and against which revision of the framework — and it will still not be a certification.
If you are here for a sample audit report
We do not have one we can give you.
The security work we have done has been on systems we own, and the findings from it concern a system that is still running. A redacted write-up of a live system's open findings is a starting point for somebody else, and no amount of redaction makes that a responsible thing to put on a marketing page. So there is no specimen here, and we would rather explain why than publish something invented.
What we can do on a call is walk you through the shape of the work — scope, what is in and out, how findings are severity-rated, and what a retest looks like — against your system rather than a specimen of ours.
- ▪Who, by name, would do the work, and what have they audited before?
- ▪What is the deliverable, and will it survive being read by our own security team?
- ▪What access do you need, for how long, and how is it revoked?
- ▪What happens to your notes and evidence after the engagement ends?
- ▪What have you missed before, and how did you find out?
One we got wrong
Between 7 and 15 July 2026, a staging copy of Butler was running with production Slack credentials still in its configuration. Every day for nine days it posted duplicate end-of-day report drafts into live Slack channels.
The duplicated content was our own internal reporting, and it went to our own channels. That is a fact about which credentials were left behind, not a control that held. A non-production environment carried live credentials for nine days, and the thing that surfaced it was the noise it made.
We publish this because a vendor with no incidents to describe has either been lucky, been small, or is not telling you.
What changed afterwards is recorded in our internal incident record. We do not publish configuration details of live systems, and that includes the fix.
- 2026-07-07First duplicate posts
- 2026-07-15Last duplicate posts
- Duration9 days
Ask us the hard version
Send a security questionnaire and we will answer it in the same register as this page: filled in where we have an answer, and marked “we do not have this” where we do not. We will not return a questionnaire with every box ticked.
Security contact: [email protected]
Last reviewed: 17 September 2026.