What your security vendors aren't telling you when their APIs fail

On April 14, a customer's Cortex Data Lake adapter returned 401 Unauthorized on every API call for the entire day. Their administrator had no notification. Their security posture view kept rendering as if data were flowing. Their dispatches feed kept publishing stories derived from increasingly stale data.

The actual cause: Palo Alto had silently throttled their tier after they exceeded the 166 credit-units-per-day quota that ships with the standard XSIAM contract. The 401 is how Palo Alto signals quota exhaustion. The customer's engineer didn't know that — until we told him.

That moment is the design center of every reliability feature we ship.

Detection is table stakes. Interpretation is the wedge.

Splunk, Sentinel, and every SOAR can detect a 401. None of them say because Palo Alto is rationing your CDL tier per the 166 CU/day quota. That gap is what we're filling.

The naive engineering response to a 401 storm is: add exponential backoff, retry, and surface the error in a dashboard. That fixes nothing for the operator who cannot interpret the error. The 401 is unambiguous to a developer reading RFC 7235; it is opaque to a SOC analyst whose vendor relationship management is "the account team Slack channel."

Setu's response is structural: every ingestion adapter is wrapped with a circuit breaker that, on failure, looks up a vendor-specific failure semantics block from a 907-vendor catalog and renders the human-language interpretation directly in the posture view. The CDL entry says, in the SOC analyst's language:

Cortex Data Lake or XSIAM returned HTTP 401 after sustained traffic. This typically indicates your Palo Alto credit-unit budget has been exceeded for the current billing period. The API is silently throttling rather than returning a 429.

And the recommended action:

Check Palo Alto admin console > Tenant Management > Credit Usage. If budget is exhausted, contact Palo Alto account team to request a tier increase or wait for the next billing period reset.

That sentence, rendered in the right place at the right time, is the difference between an analyst who knows what's happening and an analyst whose tools are silently lying.

The trust contract: the posture view never silently lies

Setu's central commitment in the Security Control Plane category is simple to state: when our view of your environment is incomplete, you see it. When data is stale, the source's row goes red. When data is fresh, it goes green. There is no third state where things look fine but are actually broken.

This is harder than it sounds because the dominant failure mode of multi-source security platforms is exactly that third state. A SIEM dashboard that renders the last successfully ingested record as if it were current. A SOAR playbook that runs against four-hour-old IOCs as if they were live. The gap between "we have the data we claim to have" and "we have data that actually represents what's happening right now" is the gap an analyst falls into during an incident.

Closing it requires three things, in order:

1. A circuit breaker on every adapter that knows when to give up after exhausted retries.
2. A per-vendor catalog of what every common HTTP failure means in vendor-specific terms.
3. A UI surface that renders both directly to the operator, in their language.

We shipped all three this month.

The catalog is MIT-licensed open data

The vendor catalog at config/vendors/all-vendors-full.json carries 907 vendor entries today. Four of them — Palo Alto Cortex XDR, Salesforce, Microsoft Azure (Entra), GitLab — now have full failure-semantics blocks with retry policies and human-readable interpretations.

We're publishing the catalog as MIT-licensed open data because the moat is the runtime that uses it, not the data itself. A competitor who clones the catalog still has to build the wrap-every-adapter-with-circuit-breaker work. A friend who reads it gets to operate their CDL deployment with one less surprise. That's a trade we'd take every time.

If you operate Cortex Data Lake or XSIAM, the page is yours to read, cite, or fork. If you find a failure mode we missed, please tell us. Real-world observations grade up over inference; we need yours.

What's next

The trust contract gets stronger as the catalog gets richer. Right now we cover the API surfaces of four vendors that bit one or more of our customers. The next eight will come from our own field experience and from the operators who tell us, "actually, here's what their 503 really means in our environment." If you have a war story about a vendor whose API failure modes were not what their docs said, we want to hear it.

The gap between what your vendors document and what your vendors do under load is where SOC analysts lose their afternoons. Closing that gap, one vendor at a time, is the work.