Every API has a different risk profile. An internal billing endpoint and a public-facing authorization endpoint don’t fail the same way. They don’t get attacked the same way either. A generic ruleset can’t account for that. Custom rules can, and now those rules can see sensitive data too.
This new release brings two things together to improve API Security: custom runtime API rules, so your team defines what suspicious means for your own environment, and sensitive data detection inside those rules, so you can act on where sensitive data actually shows up in a request or response, not just that it showed up somewhere.
Here’s what’s new.
The problem with one-size-fits-all API detection
Most API security tooling ships with a fixed set of detection patterns. That catches the obvious stuff, but it misses the information that’s specific to your organization.
Say your service mesh has an endpoint that should only ever be called by three other services. A generic ruleset doesn’t know that. A fourth caller showing up doesn’t look malicious in the abstract. It only looks wrong if you know your own environment.
Custom rules close that gap. And now they close a second one: knowing sensitive data is present isn’t the same as knowing where.
Custom runtime API rules
API is now a selectable rule type for Upwind’s runtime sensor. You define the logic: specific endpoints, request patterns, caller behavior, access that shouldn’t be happening.
A few examples:
- Flag any request to an internal-only endpoint from outside its expected service group
- Alert on abnormal request volume to a specific API path, tuned to what’s actually normal for that endpoint
- Catch access attempts against deprecated or shadow endpoints that should see zero traffic
- Detect unauthorized access to sensitive data endpoints, correlated with the process making the call
The rule runs at the sensor level, reading L7 traffic directly from the kernel. No traffic mirroring, no separate proxy. Write it once and it’s live.
Because it’s a sensor rule, it inherits the same runtime context as every other detection type: the process behind the call, the network path, what else was happening on that host. A custom API rule isn’t a filter bolted onto your traffic. It runs on the same runtime fabric as everything else.
Now with sensitive data detection, by location
In addition, custom API Security rules can now detect sensitive data in API traffic, and pinpoint exactly where it appears.
sensitive-data flags are surfaced per HTTP location. A rule can distinguish sensitive data in the URI or query string from sensitive data in the body, and from sensitive data in headers.
Why that split matters: PII showing up in a response body is a different problem than PII showing up in a request URL. One might be expected behavior for a given endpoint. The other might be a real leak. Without location-level detection, both get flagged the same way, or neither does.
Now you can write a rule that alerts specifically on PII leaking in a response body, while staying silent on the same data category appearing legitimately in a request URL elsewhere in your environment. That’s the difference between an alert your team trusts and one they start ignoring.
Where it fits
Detections from these rules land alongside your process, network, and Kubernetes audit log detections, with the same investigation view: request details, the runtime context around it, everything in one place. You can also filter by detection type when you want to isolate everything your custom rules are identifying.
Why this matters day to day
A rule that knows sensitive data exists is useful. A rule that knows whether it’s sitting in a header, a query string, or a response body is actionable. That distinction is what turns a compliance checkbox into a real detection your security team can act on without wading through noise.
Runtime context has always been the differentiator behind Upwind’s platform. This puts that logic directly into your hands for the API layer: not a predefined ruleset catching what everyone else catches, but rules built by the people who know what normal, and what sensitive, actually looks like for their own services.
Learn more about Upwind’s API Security capabilities here.
