Third-party risk in AI commerce platforms: a practical guide

Most security reviews of an AI commerce platform spend their effort in the wrong place. They interrogate the layer where the vendor writes code — authentication, permissions, encryption — and treat everything underneath as a footnote. That is understandable, because the first-party layer is the part the vendor can speak about most fluently. It is also the layer where comparatively little goes wrong.

The incidents that reach customers in this category tend to originate somewhere else: in the chain of other companies the platform runs on, and particularly in the tooling the platform operates internally to watch itself.

An AI commerce platform is a stack of other companies

When you connect a platform like this to your business, your customer data does not enter one company’s system. It enters a chain. A realistic map of that chain:

Layer	Typical providers	What they can reach
Messaging	WhatsApp Business Platform, Instagram, web chat	Message content and delivery metadata for your number
Commerce	Shopify or an equivalent store backend	Catalogue, orders, customer records
AI	One or more model providers	Whatever is placed in a prompt or retrieved for grounding
Payments	Payment gateways and processors	Transaction data, often tokenised
Logistics	Shipping and fulfilment providers	Addresses, contact details, shipment status
Infrastructure	Cloud hosting, storage, CDN	Everything at rest and in transit
Internal tooling	Analytics, observability, support desk, error tracking	Frequently broad read access across the above

The first six rows are the ones questionnaires ask about. The seventh is the one that most often matters, and it is the one buyers rarely name.

Why internal tooling is the structural weak point

Analytics and observability components sit in an unusual position, and three properties compound to make them attractive targets.

They are designed to see everything. The purpose of an observability tool is to have visibility across the system. Narrow access would defeat it. So it tends to hold broad read permissions almost by definition.

They receive less scrutiny than production code. Application code that faces customers goes through review, testing, and release process. Internal tooling is often treated as infrastructure — installed once, configured, and left running. The same organisation can be rigorous about one and casual about the other without anyone noticing the inconsistency.

They are often self-hosted components someone else wrote. A self-hosted analytics or monitoring component inherits the operator’s network position while its code is maintained by an upstream project. The operating team is responsible for patching software it did not write and may not track closely. When an upstream vulnerability is disclosed, the clock starts for every self-hosted deployment simultaneously — including the ones nobody has thought about in a year.

A component that observes everything and is reviewed by almost nobody is not an unlucky place for something to go wrong. It is a predictable one.

The four failure modes worth planning for

Excessive access. A provider or component holds broader permission than its function requires, so a compromise reaches further than it should. The mitigation is boring and effective: scope every provider to what it actually needs, and re-check when the function changes.

Unmonitored inheritance. A self-hosted component is deployed, works, and stops being tracked. Nobody owns its patch cycle. The mitigation is an inventory with a named owner per entry — the absence of that inventory is the finding.

Silent chaining. A provider has its own providers. Your data reaches companies you never evaluated because your vendor’s vendor subcontracted. The mitigation is asking about the chain explicitly, and asking what notification obligations flow along it.

Slow removal. A provider becomes a problem and the platform cannot cut it out quickly, because something load-bearing depends on it. The mitigation is knowing in advance which providers are removable and which are not. “How fast could you remove this, and have you ever done it” is one of the most revealing questions you can ask.

What to ask a vendor

Four questions, in order of how much they tell you.

Which third parties can reach my data? By name if the vendor will, by category and function if not. A vendor who cannot describe their own provider chain is unlikely to be managing it well, and the quality of this answer predicts the quality of the rest.

What can each one actually access? There is a large difference between a provider that sees aggregate usage counts and one that sees message content. Push past the category to the access level.

How fast can you remove one, and have you? This tests operational capability rather than intent. A vendor who has actually removed a component from their environment can describe doing it. A vendor who has not will speak in conditionals.

What will you tell me, and when, if a provider of yours is affected? This is the question that determines whether you learn about an incident from your vendor or from a search engine. Ask for the commitment, and note whether it is a contractual term or a vague assurance.

Read the incident history, not the marketing

The single highest-signal artefact in a vendor evaluation is not the trust page. It is the incident record.

A vendor with a dated, specific, publicly available incident record has demonstrated the capability you actually care about: that when something goes wrong, they can establish what happened and communicate it without collapsing into either denial or vagueness. That is a rehearsed skill, and you can see whether it has been rehearsed.

A vendor with no incident history has either been genuinely fortunate or has chosen not to publish. You cannot tell which from the outside, which is precisely the problem. Absence of a record is not evidence of absence of incidents — it is an absence of evidence, and it should be read that way.

What to look for in a record that exists:

• Dates. When they became aware, when they acted, when remediation completed. Vagueness about timing usually indicates vagueness about everything else.
• Scope stated honestly, including what remains unconfirmed. “We have not confirmed impact” and “there was no impact” are different statements, and a vendor that conflates them is telling you something about how they will handle the next one.
• Separation of verified findings from external claims. Third-party reporting about an incident routinely inflates figures. A vendor who repeats external numbers as their own, or who refuses to address them at all, has chosen the two worst available options.
• Durability. Is the record still there months later, or did it quietly disappear? A page that vanishes teaches you what to expect next time.

A short evaluation checklist

Usable without a security team:

1. Ask for the provider chain — names or categories with functions.
2. Ask what each provider can access: content, metadata, or aggregate.
3. Ask which providers are removable, and how quickly.
4. Ask what internal tooling holds broad read access, and who owns its patching.
5. Ask for the notification commitment when a provider is affected.
6. Read the incident history and check whether it is dated and specific.
7. Confirm you can export your data in full, yourself, without raising a request.
8. Confirm what the vendor retains after termination, and for how long.

Points seven and eight are the ones people skip, and they are the ones that determine whether a bad answer to any of the others is survivable. The ability to leave with your data intact is the strongest security control a buyer actually controls.

Where bitbybit publishes this

bitbybit is built on services operated by other companies, and treats those providers as part of the security surface rather than outside it. Several are named on the integrations pages, and the categories of provider bitbybit shares information with are set out in the Privacy Policy.

The questionnaire-order answers — data ownership and export, encryption, access control, third-party providers, certification status, and incident history — are on the vendor security review page. The approach behind them, including responsible disclosure, is on the Security & Trust page. Live service state is on the public status page, and the dated record of the August 2026 third-party analytics vendor breach is published as a security notice.

Applying this guide’s own standard: read that notice, check whether it is dated and specific, and judge accordingly. That is the test worth running on any vendor in this category, including this one.