The CEVA breach shows why AI back-office buyers must map shared dependencies, design fallbacks, and test recovery across calls, dispatch, quotes, and books.
On August 10, a breach at CEVA Logistics started showing up far beyond CEVA itself. Banks, retailers, and Steam hardware customers were affected because they depended on the same logistics provider. The incident reportedly involved eight European warehouses, while CEVA's broader air, ocean, ground, and rail transportation systems continued operating. That distinction matters. A company can contain an incident to a small part of its estate and still create a large customer impact through the businesses connected to it.
TechCrunch reported that Valve learned customer data had been taken from CEVA systems used for Steam hardware fulfillment. FreightWaves reported that CEVA operates more than 1,000 warehouses and generated $18.3 billion in revenue last year. The headline is a breach. The operational lesson is dependency concentration.
If you buy an AI receptionist, dispatch platform, quoting tool, or accounting integration, the most important question is not whether that vendor has strong security features in isolation. It is this: what stops working when a provider, API, identity system, communications carrier, or shared cloud service fails?
Security Is Not the Same as Containment
Vendor reviews often produce a reassuring checklist. Encryption is enabled. Access is logged. The provider has a security program. Subprocessors are documented. Those controls matter, but they do not tell you how far an operational failure can travel.
A local service business may have a workflow that looks simple from the outside:
- A customer calls about an urgent HVAC repair.
- A voice system transcribes the call and extracts the address and service details.
- An AI system qualifies the request.
- A job is created in the scheduling system.
- A dispatcher assigns a crew.
- The customer receives a confirmation by text.
- The completed job produces a financial update in QuickBooks.
That is not one system. It is a chain of providers and state changes. The phone carrier can fail while the AI model remains available. The model can respond while the job-management API rejects writes. The dispatch system can accept a job but fail to send the confirmation. QuickBooks can be reachable while an authentication token has expired.
The workflow's risk is determined by the weakest handoff and the amount of business activity that depends on it. A vendor can be well protected and still occupy a dangerous position in your operating chain.
Map Functions, Not Just Vendors
The first useful artifact is not a vendor list. It is a dependency map organized around business functions.
For each function, record the primary system, every external dependency, what state it owns, and what your team does when it is unavailable. Include indirect dependencies. If your dispatch vendor relies on a particular communications provider, identity platform, database host, or AI model provider, that relationship belongs in the map even if you do not have a direct contract with that company.
A basic map might look like this:
| Function | Primary system | Critical dependencies | Failure consequence |
|---|---|---|---|
| Inbound calls | Voice platform | Carrier, speech service, model provider | Calls fail or lose context |
| Job creation | Field-service system | API, identity provider, database | Requests remain unassigned |
| Dispatch | Scheduling workflow | Maps, crew data, messaging | Crews receive late or incomplete details |
| Quotes | Quoting workflow | Pricing data, model provider, CRM | Estimates wait for manual review |
| Financial updates | Accounting integration | QuickBooks API, credentials, queue | Books fall behind operational activity |
Then identify concentration points. Four different vendors may appear independent while sharing one cloud region, one identity provider, one model API, or one messaging carrier. That shared dependency is the real blast-radius multiplier.
Do not measure risk only by the probability of failure. Measure it by the number of business functions affected, the volume of work stranded, and the difficulty of reconstructing missing context.
Design Fallbacks Around State
A fallback is not simply a second vendor on a procurement spreadsheet. It must preserve enough state for a person or another system to continue the work.
If an AI receptionist fails, can the call route to a staffed number, voicemail with a clear callback queue, or a basic intake form? If the model is unavailable after capturing an address, is that address preserved? If dispatch cannot write to the scheduling platform, does the request enter a durable queue, or does it disappear with a timeout message?
For each critical step, define three things:
- Detection: how quickly does anyone know the step failed?
- Continuity: what can still happen manually or through a secondary path?
- Reconciliation: how do you compare the fallback record with the system of record after recovery?
The best fallback is often deliberately boring. A dispatcher with a shared queue and a documented call script may be more dependable during an incident than an elaborate failover that has never been used. The goal is not to preserve every automated feature. The goal is to keep customer commitments visible and recoverable.
This extends the lesson from The CEVA Breach Lesson: Map Your AI Back Office’s Blast Radius, which focused on the difference between uptime and workflow reliability. Availability tells you whether a service responds. Resilience tells you whether the business retains context and keeps moving when it does not.
Test Recovery, Not Vendor Promises
Recovery plans fail when they exist only in questionnaires. Test the actual path with a controlled exercise.
Choose a realistic scenario, such as the voice provider becoming unavailable during the morning call surge, the dispatch API returning errors for two hours, or the QuickBooks connection rejecting all writes. Then measure:
- How long until the failure is detected.
- Whether new calls, jobs, quotes, and financial updates remain visible.
- Which team owns the manual queue.
- Whether duplicate jobs or duplicate messages appear after recovery.
- How much context must be re-entered.
- How long reconciliation takes.
Run these tests quarterly for high-value workflows and after major vendor changes. Include the people who actually operate the business. A recovery design that works for engineers but leaves a dispatcher guessing is not ready.
Ask vendors for evidence, not just recovery-time objectives. Request the last relevant recovery exercise, the systems included in it, the data that was restored, and the customer-side actions required. Ask whether queued actions are durable, whether writes are idempotent, and how customers export their operational data during a prolonged incident.
The Evaluation Standard Should Change
When evaluating an AI back-office vendor, add dependency questions to the buying process:
- Which providers can interrupt this workflow?
- Which dependencies are shared across your other systems?
- What data is stored at each step?
- What happens when an action is partially completed?
- How are failed actions retried without duplication?
- Can a human continue from the last known state?
- How is recovery tested with customer workflows?
We have already argued that The DOGE Report's Lesson: Show Your AI Work should change how buyers evaluate automation claims. The same standard applies to resilience claims. Ask for the workflow, the evidence, and the failure behavior, not a polished feature list.
Reeve is built around connected back-office work, so dependency mapping and recoverable handoffs are part of the product question, not an afterthought. The point is not to pretend risk disappears when work is automated. It is to make failures visible, bounded, and recoverable.
Before you sign your next AI automation contract, draw the dependency map for one critical workflow and run one failure exercise. The gaps you find will be more useful than another uptime percentage.