Every breach this year had the same skeleton
The incidents from the first half of 2026 look different on the surface — a supply chain attack targeting CRM integrations, an 8.3 TB credential database exposed on a public Elasticsearch instance, legacy payment APIs being skimmed across dozens of e-commerce sites, an unauthenticated ServiceNow endpoint leaking enterprise support tickets. But strip away the product names and the attack details, and every one of them has the same skeleton underneath.
A credential with too much scope. An API that asked too few questions before honoring it. And automation — whether it belonged to the attacker or the platform itself — that amplified whatever access the credential had before anyone noticed.
The Klue supply chain breach (June 2026) is a precise example. Attackers used compromised legacy credentials to enter Klue’s integration environment, obtained OAuth tokens tied to customer platforms, and walked Salesforce CRM data out of roughly two dozen customer accounts over the course of a day. The credentials that were compromised were legacy — still active, still scoped to read production data, and nobody was watching them closely enough to catch the anomaly before it spread. Salesforce disabled the integration on 17 June; by then the tokens had been active for nearly a week.
The Stripe legacy API fraud tells a similar story from the other direction: hijacked old API keys — not stolen through a sophisticated attack, but captured from exposed or poorly managed deployments — were used to process fraudulent payments across at least 49 e-commerce sites. The keys worked because nothing about the API’s trust model had changed since they were issued, and nobody was watching what they were being used for.
A ThreatStats 2026 report identified the same thread running through the 700Credit breach, the Qantas airline API incident, and the SwissBorg unauthorized transaction exposure: a stolen or over-permissive token combined with an API that was too trusting, with automation amplifying the damage.
The underlying numbers are not surprising in context. Over 30% of cloud breach cases involve API misconfiguration. More than 40% of organizations report API authentication gaps from inconsistent implementation. Hardcoded API keys remain exposed in code repositories in over 50% of applications. None of these statistics describe exotic vulnerability classes — they describe organizational habits.
The two failure modes
Looking across the incidents, there are two distinct failure modes. They frequently appear together, which is part of why the blast radius is so large when things go wrong.
Long-lived, over-scoped credentials. A token issued once, never rotated, scoped to read (or write) far more than the integration it was created for actually needs. The Klue breach hinged on credentials that were described as “legacy” — which in practice means “issued when the scope seemed reasonable, never revisited, still active.” When a credential with production CRM read access exists, it represents a persistent risk that compounds with every passing month it is not reviewed.
APIs that are too trusting. The counterpart to the over-scoped credential is the API that accepts any valid token and processes the request without checking whether this token should be making this particular call to this particular endpoint. The ServiceNow exposure in June 2026 came from an unauthenticated endpoint — but authenticated APIs are only marginally safer if the policy after authentication is “anything goes.”
The combination is what creates the incidents in the roundup. Scope reduction eliminates the credential risk. Policy enforcement at the API edge eliminates the trusting-API risk. Both together mean a compromised token can only do what it was explicitly permitted to do — and that the blast radius has a ceiling.
Scoped credentials with an explicit allow-list
The starting point is credential isolation. Every integration, every service, every agent should authenticate with a distinct credential scoped to exactly what it needs. Not a shared key. Not a key with a note attached saying “only use for X.” A separate credential bound to a proxy that enforces the constraint in code.
In RequestRocket, this looks like one proxy per integration identity, with a proxyDefaultRuleEffect of deny:
POST /clients/{clientId}/proxies
{
"proxyName": "stripe-payment-intake",
"proxyRegion": "us-east-1",
"proxyProxyCredentialId": "<payment-service-credential-id>",
"proxyTargetId": "<stripe-target-id>",
"proxyTargetCredentialId": "<stripe-live-key-credential-id>",
"proxyDefaultRuleEffect": "deny",
"proxyNotes": "Payment intake service — POST /v1/payment_intents only"
}The proxyDefaultRuleEffect: "deny" sets the baseline: every request is rejected unless an explicit rule permits it. The credential that authenticates to this proxy cannot access any other proxy. The upstream Stripe key is stored in a target credential and injected at forward time — the calling service never sees it.
Add rules to form the allow-list:
{
"effect": "allow",
"ruleActive": true,
"methods": ["POST"],
"path": {
"path": { "pattern": "^/v1/payment_intents$" },
"presence": "must_exist"
},
"priority": 10,
"notes": "Payment intake: create payment intents only"
}This is the “too trusting API” fix applied. The proxy becomes the policy enforcement point. A compromised payment intake credential cannot call /v1/refunds, cannot enumerate customers, cannot access the reporting endpoints. It can create a payment intent, which is the one thing the service was built to do.
This is not optional hardening — it is how you put a ceiling on blast radius. Every credential that exists without an explicit allow-list is an implicit wildcard grant waiting to be exploited.
Monitoring what your credentials are doing
Scope reduction is the preventive layer. Monitoring is the detection layer — and the roundup makes clear that detection speed is often the difference between a contained incident and a multiweek breach.
The Klue breach ran from 11–12 June and was not detected until Salesforce disabled the integration on 17 June. The legacy Stripe fraud has been active since August 2024. Neither of these would have survived long if the traffic patterns on those credentials were being watched.
RequestRocket aggregates telemetry per proxy at configurable intervals. Pull hourly data for any proxy to see whether its traffic looks like what you expect:
GET /clients/{clientId}/proxies/{proxyId}/telemetry?interval=hour&limit=24The response surfaces the maps you need to spot anomalies:
{
"interval": "hour",
"telemetry": [
{
"sKey": "2026-08-03-08",
"countMap": { "proxy": 412 },
"successCountMap": { "proxy": 409 },
"errorCountMap": { "proxy": 3 },
"codeCountMap": {
"200:proxy": 409,
"403:proxy": 3
},
"averageResponseTimeMap": { "proxy": 0.621 }
}
]
}A sudden spike in countMap — a proxy that normally handles 400 requests an hour receiving 4,000 — is a signal. A spike in errorCountMap or a new status code appearing in codeCountMap (particularly 403 or 429) tells you the credential is being used in ways it is not supposed to be.
Per-request detail is available when you need it:
GET /clients/{clientId}/proxies/{proxyId}/requests
?processedAfter=2026-08-03T00:00:00Z
&processedBefore=2026-08-03T12:00:00ZThis gives you the audit trail the Klue and Stripe post-mortems wish they had: what was called, when, from where, and what the response was. If you can answer “what did this credential do between Tuesday and Wednesday?” in seconds rather than days, the cost of a breach is an investigation, not a reconstruction.
Rate limiting as an anomaly signal
Rate limiting is not just a cost control mechanism — it is one of the fastest signals you have that something has changed about how a credential is being used.
A meter set to realistic operational limits for an integration will fire when an attacker tries to use a compromised credential at scale. Automation amplifies attacks; it also amplifies the rate signal. In the Stripe fraud pattern, card skimming operations issue a high volume of small test charges. A per-minute limit tuned to legitimate traffic would catch the volume spike before significant damage accumulated.
Create a meter on any proxy where volume anomalies should be detectable:
POST /clients/{clientId}/proxies/{proxyId}/meters
{
"meterType": "request_count",
"meterActive": true,
"limits": {
"minute": 30,
"hour": 300,
"day": 2000
},
"notes": "Stripe payment intake — operational traffic limits"
}meterActive: true means these limits are enforced: requests above the threshold receive a 429. The limits here are not hypothetical — they should reflect what the service actually does under normal load. An integration that runs 10–15 payment intent calls per minute in production should have a per-minute limit of 30, not 1,000. The gap between the operational limit and the limit you set is the detection latency.
The meter’s contribution appears in telemetry via metersCountMap and metersLimitsMap. If the meter is being hit regularly, that is information — either the limits are too tight, or something about the traffic has changed.
For high-value endpoints where you want observability without hard enforcement, set a meter with meterActive: false and omit limits. It records volume data for telemetry without blocking any requests. Add the limits later when you have a baseline of legitimate traffic to calibrate against.
The agentic angle: MCP servers and agent credentials
The ThreatStats 2026 report called out exposed MCP servers leaking agent infrastructure as a distinct pattern — not as a variation on an older attack class, but as something new enough to name separately. The mechanism is the same one running through the other incidents in the roundup: a credential with too much scope, issued to an automated system, with insufficient monitoring on what that system does with it.
AI agents are, in the relevant sense, API clients. They hold credentials. They make calls. They operate at machine speed, which means when something goes wrong — whether through a compromised key, a prompt injection, or a model reasoning error — the damage compounds faster than any human response can match. An agent that can call any endpoint on a production API because it was given a broad credential is not a controlled system; it is a risk multiplier.
The mitigation is the same as for every other API integration, applied with more urgency because the automation is more aggressive. Each agent gets a dedicated proxy credential. Each proxy has an explicit allow-list via rules. Each proxy has a meter. Each proxy is monitored.
The credential the agent holds can be rotated without touching the agent’s code or configuration — update the target credential record, confirm traffic flows through the new key, remove the old credential. Rotation costs nothing in engineering time, which means there is no excuse for a three-year-old production key that “nobody wants to touch.”
A deny-default proxy with narrow rules is particularly important for agentic traffic because the agent cannot be trusted to self-limit. A proxyDefaultRuleEffect: "deny" proxy combined with an explicit path allow-list means the model cannot, regardless of how it reasons or what it is injected with, make a call that the policy does not permit. The enforcement is outside the agent’s control — which is precisely where it needs to be.
What good looks like
The incidents in this roundup share a characteristic: none of them would have been catastrophic if the affected credential had been scoped to only what the integration needed, monitored for volume anomalies, and bound to a proxy that asked “should this credential be making this call?” before forwarding the request.
That is not a complicated program. It is:
- One credential per integration identity, not one credential for a category of integrations.
- A deny-default proxy with an explicit allow-list of permitted methods and paths.
- A rate limit meter calibrated to operational traffic, not to “what is technically possible.”
- Telemetry pulled on a schedule, with a baseline established so anomalies are visible.
- A rotation policy that runs on a schedule, not on a compromise.
None of this requires changing the upstream API. None of it requires changing your application code. It is a layer added in front of the credentials you are already managing — one that makes the blast radius knowable and the anomalies detectable.
Next steps
The RequestRocket documentation covers the full setup: proxy configuration, credential management, rules, meters, and telemetry queries. If you have an integration running with a broadly scoped key today, the shortest path to remediation is creating a deny-default proxy for it, adding the minimum allow-list rules it needs, and attaching a meter. That takes less than an hour and closes the failure modes that drove every breach in this roundup.