Out-of-Path: The Case for Security That Stays Out of the Way

When you evaluate a security product, one of the most important questions you can ask is: “Does this vendor see my data?”

For most API security products, the answer is yes. API gateways proxy your traffic. WAFs inspect your payloads. Token services validate credentials on every request. These tools sit in the request path — every API call flows through them.

This creates three problems.

Problem 1: Privacy

If your security vendor proxies your traffic, they can see your request and response bodies. Even if they promise not to log or store this data, they have the technical capability. For regulated industries — healthcare, finance, government — this can be a compliance problem.

Problem 2: Availability

If your security vendor goes down, your APIs go down. Every request depends on the vendor being available, responsive, and fast. You’ve added a single point of failure to your entire service mesh.

Problem 3: Latency

Every proxy hop adds latency. Even a well-optimized proxy adds 5-20ms per request. At scale, across thousands of services making millions of calls, this adds up.

The Out-of-Path Alternative

HardenAPI solves all three problems by staying out of the request path entirely. Here’s how it works:

Key distribution, not request proxying. HardenAPI distributes ephemeral keys to your services. Your services use these keys to sign requests locally. The actual API traffic flows directly between your services — HardenAPI never sees it.

Local signing. All cryptographic operations — TOTP generation, HMAC signing, RSA signing — happen locally in the SDK running inside your service. The SDK adds authentication headers to outbound requests and validates them on inbound requests. No external calls during the request lifecycle.

Cached keys with local derivation. The SDK fetches a key from HardenAPI and caches it. For seed rotation (which can be as frequent as every 30 seconds), the SDK derives new signing material from the cached key using HMAC-SHA256 — a local operation that takes microseconds. This means key rotation doesn’t require network calls.

What Happens When HardenAPI Goes Down?

Your services keep running. The SDK caches keys with a configurable TTL (up to one hour on some plans). If HardenAPI becomes unavailable, services continue authenticating requests using cached keys until they expire. This is a deliberate design choice: availability of your services should never depend on availability of ours.

But we go further than just caching. If cached keys do expire during an extended outage, the SDK doesn’t give up — it negotiates a fallback directly with the receiving service, in-band, with no external coordination.

Here’s how it works: the SDK includes a circuit breaker that detects when the Harden API is unreachable — on either side. Once tripped, the client enters dormant mode — requests are sent with service identity but without cryptographic signatures. The receiving server recognizes this pattern and responds with an encrypted acceptance ticket, issued using the shared pair key that both services already hold locally. The client then retries the request with a static HMAC signature derived from that same pair key, proving its identity without ever contacting the Harden API.

This entire handshake happens within the normal HTTP request-response cycle. No discovery endpoints, no shared state, no pre-configuration. It works on Lambda, Kubernetes, bare metal — anywhere. The pair key that both services already have is enough to maintain authenticated communication until the Harden API recovers.

The security posture during an outage is reduced (static HMAC vs. ephemeral key rotation), but it’s still cryptographically authenticated — not just identity headers that anyone could forge.

The Trust Model

With HardenAPI, the trust model is minimal:

• We distribute ephemeral key material to your instance(s) of the SDK
• The SDK handles all signing and verification locally
• Your API requests, responses, and payloads never leave the direct connection between client and server This isn’t a policy choice — it’s an architectural one. We built the system so that seeing your data is not technically possible, not just something we promise not to do.

When Out-of-Path Isn’t Enough

For most organizations, HMAC signing with ephemeral keys provides strong authentication and integrity protection. But some industries — finance, healthcare, government — need more than authentication. They need proof: an auditable, tamper-evident record that a specific service made a specific request, to a specific target, at a specific time, and that the target received the request, unaltered, and responded in kind.

For these use cases, we offer RSA signing on Business+ and Enterprise plans. RSA keys are customer-managed — we never hold the private keys. Signatures are bidirectional: both the request and the response can be independently signed and verified, so either side of the transaction can prove what happened.

Every signed request carries a correlation ID — sometimes called a transaction ID, nonce, or idempotency key — that links the request, the response, and the audit log entry into a single verifiable chain. Non-repudiation logs are written to WORM (Write Once, Read Many) storage with seven-year retention — immutable records that can’t be altered after the fact, even by us. This gives regulated organizations the evidence trail they need for compliance, dispute resolution, and forensic analysis.

The principle remains the same: your data stays your data. We just make it provable.