xGate: Gateway Rate Limiting

The Problem

Push-bombing attacks exploit the absence of rate limiting to overwhelm users with authentication prompts until they approve one out of fatigue.

In September 2022, an attacker targeting Uber spammed over 100 Duo MFA push notifications to an employee in rapid succession. After repeated prompts, the victim approved one — granting the attacker full access to internal systems. This technique, known as MFA fatigue or push-bombing, requires no technical exploit. It weaponizes human psychology: eventually, someone clicks "Approve" just to make the notifications stop.

Rate limiting at the application layer is inconsistent, bypassable, and usually an afterthought. Each endpoint implements its own ad-hoc throttling (or none at all), leading to gaps that attackers exploit. Without centralized gateway-level enforcement, DDoS, challenge spam, and resource exhaustion attacks become trivial to execute against any push-based authentication system.

The situation is worse in machine-to-machine environments. When AI agents and IoT devices communicate autonomously, a compromised agent can generate thousands of API calls per second. Without DID-aware throttling, there is no way to distinguish a legitimate high-throughput service from an attacker abusing a stolen identity.

Push-Bombing Attack

The PRIVATE.ME Solution

xGate is a multi-algorithm rate limiter built into the gateway layer. It provides sliding window, token bucket, and leaky bucket enforcement with DID-aware and per-scope hierarchical controls.

Every request passes through xGate before reaching the target service. The middleware checks the caller's identity (DID), the requested scope, and the selected algorithm to make an allow/deny decision in sub-microsecond time. If the limit is reached, the request is rejected with HTTP 429 and metadata indicating when the window resets.

xGate ships five limiter types that cover every rate-limiting pattern: SlidingWindowLimiter for time-windowed counting, TokenBucketLimiter for burst-tolerant steady-state control, LeakyBucketLimiter for smooth output regulation, PerDidLimiter for DID-aware per-connection and global limits, and PerScopeLimiter for hierarchical scope-based policies.

Enterprise customers configure per-app overrides at runtime. A corporate identity provider might need a higher limit for legitimate batch operations, while consumer-facing apps stay at the strict default. Overrides are set per app DID and can be added or removed without restarting the gateway.

xGate Filter

How It Works

Every request passes through a deterministic check using an in-memory Map lookup. The decision is made in sub-microsecond time with zero external dependencies.

Three Core Algorithms

Sliding Window tracks request timestamps per key within a rolling time window. On every check, expired timestamps are pruned and the active count is compared against the configured maximum. This provides precise, fair enforcement without the burst edge cases of fixed windows.

Token Bucket models a bucket that fills at a constant rate (tokens per second) up to a configured capacity. Each request consumes one token. This allows short bursts up to the bucket capacity while maintaining a steady-state throughput limit. Ideal for APIs where brief traffic spikes are acceptable.

Leaky Bucket models a queue with a fixed drain rate. Incoming requests fill the queue; the queue drains at a constant rate. When the queue is full, excess requests are rejected. This smooths output to a constant rate, preventing downstream services from experiencing any spikes at all.

DID-Aware Limiting

The PerDidLimiter provides two-tier enforcement. The first tier limits requests per connection (keyed by didA:didB:scope). The second tier limits total requests per DID across all connections. This prevents a single identity from monopolizing infrastructure even when spread across many connections.

Scope-Based Hierarchical Limits

The PerScopeLimiter applies different rate limits based on the requested ACI scope. A defaultLimit applies to any unspecified scope, while scopeLimits provides per-scope overrides. This allows high-throughput scopes (like telemetry) to have generous limits while security-sensitive scopes (like key rotation) stay tightly capped.

Uniform Response Contract

All five limiter types return the same RateLimitResult object: { allowed: boolean, remaining: number, resetsAt: number }. The allowed field is the binary decision. The remaining field tells the caller how many requests they have left in the current window. The resetsAt field (epoch milliseconds) tells them when the window resets. This uniform contract means middleware code works identically regardless of which algorithm is configured.

Error Handling

xGate follows the Result pattern used throughout the PRIVATE.ME platform. Configuration errors (invalid windowMs, negative maxRequests) throw XgateError at construction time — not at check time. Once a limiter is successfully constructed, the check() method never throws. It always returns a RateLimitResult, even for keys that have never been seen before (they start with full quota). This makes xGate safe to use in middleware without try/catch wrappers on the hot path.

Why Not Alternatives?

Every existing rate limiter fails the same test: they throttle by IP address or API key, not by cryptographic identity. In a world of machine-to-machine communication, IP addresses are meaningless and API keys are stealable.

DID-aware means the limiter understands cryptographic identities, not just IP addresses. Scope-aware means different ACI scopes can have different limits. Threshold-aware means per-connection limits that work with XorIDA threshold sharing patterns (didA:didB:scope). No alternative provides all three.

Where They Break

express-rate-limit uses fixed windows with a global counter. At window boundaries, the counter resets — allowing a burst of 2x the intended limit if requests straddle two windows. It has no concept of identity beyond what you manually key on (usually IP). In a Kubernetes cluster with multiple pods behind a load balancer, each pod maintains its own counter — the effective limit is multiplied by the number of pods.

Nginx rate_limit uses a leaky bucket per zone (typically keyed on $binary_remote_addr). It cannot distinguish between a legitimate API client and an attacker behind the same NAT. It has no concept of scopes, DIDs, or hierarchical policies. Configuration is static — changing limits requires reloading the Nginx config.

Cloudflare Rate Limiting operates at the edge but only matches on IP, URL path, or HTTP headers. It cannot inspect request bodies, DID headers, or application-layer identity tokens. Rules are global per zone — there is no per-tenant or per-identity granularity. Pricing is per 10,000 good requests, making it expensive at scale for legitimate M2M traffic.

AWS WAF Rate Rules are per-rule with a minimum evaluation window of 5 minutes. They cannot enforce sub-minute windows needed for push-bombing prevention. Rules evaluate sequentially, adding latency proportional to the number of rules. DID-based keying requires custom request inspection configurations that add complexity and cost.

Redis-based limiters (e.g., redis-cell, rate-limiter-flexible) add network round-trip latency (~0.5ms per check). They support multiple algorithms but require Redis infrastructure, which is an operational burden for air-gapped deployments. They do not natively understand DIDs or ACI scopes without custom key construction logic.

Benchmarks

xGate is designed to add effectively zero latency to the request path. All operations are in-memory Map lookups with no I/O, no locks, and no allocations on the hot path.

Memory Profile

Memory usage scales linearly with the number of tracked keys. At 100,000 unique keys using SlidingWindowLimiter (with 100-request windows), total memory is under 50MB. TokenBucketLimiter and LeakyBucketLimiter use constant memory per key (64 bytes and 48 bytes respectively), regardless of throughput volume. For deployments tracking over 1M keys, TokenBucket is the recommended algorithm for memory efficiency.

Garbage Collection Impact

SlidingWindowLimiter prunes expired timestamps on every check call. For keys with high request volumes (>1,000 requests per window), the pruning pass may briefly increase GC pressure. The token bucket and leaky bucket algorithms do not store per-request data, so they have zero GC impact regardless of throughput. In latency-sensitive environments where consistent sub-microsecond performance is required, TokenBucket or LeakyBucket should be preferred over SlidingWindow.

ACI Surface

Five limiter classes, each with a clean check-and-respond interface. All return a uniform RateLimitResult with allowed, remaining, and resetsAt.

import {
  SlidingWindowLimiter,
  TokenBucketLimiter,
  PerDidLimiter,
  PerScopeLimiter
} from '@private.me/xgate';

// Sliding window: 100 requests per 60 seconds
const slider = new SlidingWindowLimiter({
  windowMs: 60_000,
  maxRequests: 100
});
const result = slider.check('api-key-hash');

// Token bucket: 50 capacity, refills 10/sec
const bucket = new TokenBucketLimiter({
  capacity: 50,
  refillRate: 10
});

// DID-aware: 20 per connection, 200 global
const perDid = new PerDidLimiter({
  perConnection: { windowMs: 60_000, maxRequests: 20 },
  perDid: { windowMs: 60_000, maxRequests: 200 }
});
perDid.check(senderDid, recipientDid, 'message.send');

// Scope-aware: tight for auth, generous for telemetry
const scoped = new PerScopeLimiter({
  defaultLimit: { windowMs: 60_000, maxRequests: 100 },
  scopeLimits: {
    'auth.rotate': { windowMs: 3600_000, maxRequests: 5 },
    'telemetry.push': { windowMs: 60_000, maxRequests: 10_000 }
  }
});

Use Cases

Regulatory Alignment

Rate limiting is a compliance requirement across every major security framework. xGate provides the technical enforcement layer that maps directly to audit evidence.

Audit Evidence Generation

Every xGate decision produces a structured event record containing: the decision (allow or reject), the algorithm that made the decision, the key that was evaluated, the remaining quota, the window reset timestamp, and the policy configuration that was applied. These records are formatted for direct ingestion into SIEM platforms (Splunk, Elastic, Datadog) without transformation.

For SOC 2 audits, the xGate event stream provides continuous evidence of access control enforcement. Auditors can query the rate-limit log to verify that specific policies were active during the audit period, that violations were correctly rejected, and that no requests bypassed the gateway layer.

Industry-Specific Regulatory Requirements

Rate limiting is not just a defensive measure — it is a compliance requirement with specific technical implementations mandated by industry regulations.

Financial Services: PSD2 and FINRA

PSD2 (Payment Services Directive 2) requires API security controls to prevent credential stuffing and brute force attacks on payment authentication endpoints. While PSD2 does not mandate specific rate limit thresholds, the EBA's Regulatory Technical Standards require that Third Party Providers (TPPs) implement mechanisms to prevent automated fraud attempts. xGate's sliding window enforcement at API gateway layer provides the necessary control: authentication endpoints can be capped at 100 attempts per minute per IP address, with stricter per-DID limits (20 per minute) for Strong Customer Authentication (SCA) challenge flows.

FINRA API throttling enforces strict limits on broker-dealer API access. Synchronous requests are capped at 1,200 requests per minute per IP address. Asynchronous requests are limited to 20 requests per minute per dataset per API account. Broker-dealers integrating FINRA APIs must implement client-side rate control to stay within these limits. xGate's TokenBucketLimiter provides the ideal algorithm: a bucket capacity of 1,200 tokens with a refill rate of 20 tokens per second allows full utilization of the synchronous quota while smoothing bursts. For asynchronous dataset queries, PerScopeLimiter enforces the 20-per-minute cap per dataset identifier.

SEC Rule 17a-4 and SOX compliance require audit trails for all trading and account management operations. xGate's structured event stream provides the necessary evidence: every rate-limit decision (allow or deny) is logged with timestamp, DID, scope, remaining quota, and algorithm used. This log integrates directly into SIEM platforms for continuous compliance monitoring.

Healthcare: HIPAA Minimum Necessary Principle

HIPAA's Minimum Necessary Rule requires that covered entities limit access to Protected Health Information (PHI) to the minimum necessary to accomplish the intended purpose. While rate limiting is not explicitly mentioned in HIPAA regulations, the principle applies to access frequency control. xGate enforces this at the API layer by capping the number of PHI queries per provider DID per time window.

A typical healthcare API configuration uses PerDidLimiter to enforce role-based access quotas: physician DIDs receive 500 PHI queries per hour (sufficient for active patient care), while administrative staff DIDs are capped at 100 queries per hour (sufficient for billing and scheduling). Batch export operations for analytics are routed through a separate scope with higher limits but require additional audit logging. This prevents unauthorized bulk PHI access while allowing legitimate clinical workflows.

Role-Based Access Control (RBAC) integration ensures that rate limits align with job function. Nurse practitioners, medical assistants, and billing clerks each have distinct quotas tied to their role's minimum necessary access requirements. xGate's PerScopeLimiter maps HIPAA-defined purposes (treatment, payment, healthcare operations) to scope-specific limits, providing a technical enforcement layer for the Minimum Necessary Rule.

Audit logs generated by xGate include the provider DID, patient identifier hash (for privacy), access timestamp, and whether the request was allowed or denied. This provides the audit trail required by HIPAA's Security Rule (45 CFR 164.312) for access control monitoring.

Government and Defense: FedRAMP and NIST 800-53

FedRAMP Moderate and High baselines require implementation of NIST SP 800-53 controls, including SC-5: Denial of Service Protection. SC-5 mandates that systems restrict the ability of individuals or processes to launch denial-of-service attacks against other systems. Rate limiting is the primary technical control for SC-5 compliance.

FedRAMP-authorized systems must demonstrate that rate limiting is enforced at multiple layers: perimeter (firewall/WAF), application gateway (API layer), and application logic. xGate fulfills the API gateway requirement. A typical FedRAMP Moderate configuration uses LeakyBucketLimiter at the gateway layer to enforce a smooth 1,000 requests per minute per tenant, preventing any single tenant from monopolizing shared infrastructure.

Access Control (AC-2, AC-3, AC-6) requires enforcement of least privilege and role-based access restrictions. xGate's PerDidLimiter integrates with FedRAMP identity providers (Okta, Azure AD, Ping Identity) to enforce DID-aware rate limits that align with user roles. A government contractor with an IAL3-verified identity (multi-factor + PIV card) receives higher API quotas than an IAL1 self-asserted identity.

Audit and Accountability (AU family) requires continuous monitoring and audit log generation. xGate produces structured logs compatible with government SIEM platforms (Splunk Federal, Elastic GovCloud). Every rate-limit decision includes the NIST 800-53 control identifier (SC-5) in the event metadata, simplifying audit evidence collection for FedRAMP assessors.

For CMMC Level 2 and Level 3 (DoD contractors), xGate's fail-closed design ensures that rate limiting cannot be bypassed even in error conditions. If the limiter encounters an unexpected state (corrupted counter, invalid timestamp), the request is rejected with HTTP 429 rather than allowed by default. This aligns with CMMC's requirement for demonstrable security enforcement.

GDPR and Data Protection: Availability Requirements

GDPR Article 32 (Security of Processing) requires that controllers and processors implement appropriate technical measures to ensure ongoing availability of systems processing personal data. While GDPR does not explicitly mandate rate limiting, denial-of-service protection is recognized as a necessary measure to maintain availability.

xGate provides the technical control to satisfy Article 32's "regularly testing, assessing and evaluating" requirement. Rate-limit configurations are version-controlled, and changes are logged with audit trails. Quarterly reviews verify that rate limits align with actual usage patterns and that no legitimate users are being incorrectly throttled.

For DORA (Digital Operational Resilience Act), which applies to EU financial entities, xGate's TokenBucketLimiter prevents cascade failures during ICT incident scenarios. Article 9 requires resilience testing under stress conditions. xGate's burst-tolerant design allows temporary traffic spikes (up to bucket capacity) while maintaining steady-state throughput limits, ensuring that critical payment operations continue during partial infrastructure failures.

Rate Limiting Strategy Selection by Industry

Choosing the correct rate-limiting algorithm depends on the regulatory environment and the nature of the protected operations:

Cross-ACI Integrations

xGate is the gateway layer that protects every other ACI in the platform. It integrates with identity, billing, and fusion primitives to provide context-aware rate control.

xGate + xLink: M2M Throttling

Every xLink agent-to-agent message passes through xGate. The PerDidLimiter keys on both sender and receiver DIDs plus the message scope, ensuring that compromised agents cannot flood their peers. Rate limit policies follow the xLink trust registry — trusted agents get higher limits automatically.

xGate + xPass: Billing-Aware Limits

xPass tracks ACI connection billing per connection. xGate enforces usage quotas that align with billing tiers. A Base tier subscriber gets a different rate limit profile than an Enterprise tier subscriber. When xPass detects an expired subscription, xGate drops the connection's limits to zero — no requests pass until billing is resolved.

xGate + xFuse: Identity-Aware Throttling

xFuse performs K-of-N identity fusion to verify agent identities. Once fusion completes, xFuse passes the verified identity assurance level (IAL1/2/3) to xGate. Higher assurance levels receive more generous rate limits. An IAL3-verified agent (biometric + multi-factor) gets 10x the quota of an IAL1 self-asserted identity.

xGate + Xguard: Chain-Level Protection

Xguard provides HMAC-chained audit trails. xGate rate-limit decisions are recorded in the Xguard audit chain, creating a tamper-evident log of every allow/deny decision. Auditors can verify that rate limiting was consistently enforced without being able to modify the historical record.

xGate + xLock: Push Auth Protection

xLock provides 1-tap push authentication. xGate protects the xLock challenge endpoints specifically, capping pending challenges per recipient DID. This is the direct defense against push-bombing — even if an attacker obtains a valid app DID, they cannot send more than the configured maximum pending challenges.

xGate + xTrust: Trust-Level Rate Policies

xTrust manages contact trust levels (unknown, tofu, verified). xGate can query the trust level for a DID and apply different rate limit policies based on trust status. Verified contacts receive generous quotas. TOFU contacts receive moderate quotas. Unknown or revoked identities receive strict minimum quotas. This creates a natural incentive for agents to complete verification ceremonies.

import { PerDidLimiter } from '@private.me/xgate';
import { Agent } from '@private.me/agent-sdk';

// Create per-DID limiter for xLink channels
const limiter = new PerDidLimiter({
  perConnection: { windowMs: 60_000, maxRequests: 50 },
  perDid: { windowMs: 60_000, maxRequests: 500 }
});

// Before processing each xLink message
const result = limiter.check(
  senderDid,
  recipientDid,
  message.scope
);
if (!result.allowed) {
  agent.rejectMessage(message, 'RATE_LIMITED');
}

Security Properties

Verifiable Rate Enforcement

Every rate-limiting decision produces a verifiable audit event via xProve. HMAC-chained integrity proofs let auditors confirm that limits were enforced correctly — without accessing the request content.

Ship Proofs, Not Source

xGate generates cryptographic proofs of correct execution without exposing proprietary algorithms. Verify integrity using zero-knowledge proofs — no source code required.

Use Cases

Honest Limitations

xGate is a single-process, in-memory rate limiter. Understanding its boundaries is essential for correct deployment.

In-Memory Only

All rate limit state lives in a JavaScript Map in process memory. When the process restarts, all tracked keys and their quotas reset to zero. This means a restart effectively grants all clients a fresh quota. For most deployments this is acceptable — rate limits are a defense against sustained abuse, not single requests. For high-availability requirements, Redis-backed state sharing is available as an optional integration.

Single Instance

By default, xGate does not share state across multiple server instances. If you run three gateway instances behind a load balancer, each instance tracks its own quotas independently. A client could theoretically get 3x the intended limit by hitting all three instances. For distributed enforcement, configure Redis-backed synchronization or use a sticky-session load balancer.

Clock Dependent

Sliding window calculations depend on Date.now(). Clock skew between instances or NTP jumps can cause brief inconsistencies in window boundaries. The token bucket and leaky bucket algorithms are more resilient to clock drift because they track elapsed time rather than absolute timestamps.

Memory Growth

The sliding window algorithm stores one timestamp per request within the window. For high-throughput keys (e.g., 10,000 requests/minute), memory per key grows linearly with request volume. Token bucket and leaky bucket use constant memory per key regardless of throughput, making them better choices for high-volume scenarios.

No Persistence

There is no built-in persistence layer. Rate limit state cannot survive process crashes without the optional Redis integration. This is an intentional design choice: persistence adds latency and complexity, and most rate limiting use cases prioritize speed over durability.

No Request Inspection

xGate makes allow/deny decisions based on keys (DID, IP, scope) and quotas. It does not inspect request bodies, validate payloads, or perform content-based filtering. For content-level security (DLP, payload validation, schema enforcement), pair xGate with Xguard or xRedact.

No Adaptive Learning

Rate limits are statically configured. xGate does not automatically adjust limits based on traffic patterns, time of day, or historical behavior. If you need dynamic rate adjustment based on anomaly detection, configure an external controller that updates xGate policies via the reset() API when threat signals change.

Enterprise CLI Integration

xGate is embedded in every Enterprise CLI server in the PRIVATE.ME platform. All 21 CLI services use xGate for per-endpoint rate limiting with RBAC-aware policies.

Each Enterprise CLI (trust-cli, keyceremony-cli, deaddrop-cli, auditlog-cli, secureingest-cli, vaultdb-cli, authorize-cli, redact-cli, xlink-cli, xprove-cli, xcompute-cli, xpass-cli, xboot-cli, xlock-cli, xwallet-cli, xid-cli, xfuse-cli, xghost-cli, xchange-cli, xstore-cli, xgit-cli) includes a built-in RateLimiter instance initialized from xGate's sliding window algorithm.

The default configuration for all CLI servers is 100 requests per 60 seconds per API key. This limit is tuned for administrative and operational use — batch data operations should use the library directly, not the HTTP API. Enterprise deployments can override the default by setting environment variables (e.g., RATE_LIMIT_WINDOW_MS=30000, RATE_LIMIT_MAX_REQUESTS=500).

CLI Rate Limiting Pattern

// Every CLI server initializes xGate at startup
import { SlidingWindowLimiter } from '@private.me/xgate';

const limiter = new SlidingWindowLimiter({
  windowMs: 60_000,
  maxRequests: 100
});

// Middleware applied to every route
function rateLimitMiddleware(req, res) {
  const key = req.headers['x-api-key'] || req.socket.remoteAddress;
  const result = limiter.check(key);
  if (!result.allowed) {
    return sendError(res, 429, 'RATE_LIMIT_EXCEEDED',
      `Rate limit exceeded. Resets at ${result.resetsAt}`);
  }
}

How CLI Integration Works

Each Enterprise CLI server creates an xGate limiter during server startup, before any routes are registered. The limiter instance is shared across all route handlers via dependency injection. When a request arrives, the rate-limit middleware executes first — if the limit is exceeded, the request is rejected with HTTP 429 before any business logic runs. This ensures that even malformed or malicious requests cannot consume application resources.

The rate limit key is derived from the API key hash (for authenticated requests) or the client IP address (for unauthenticated health checks). This aligns with the RBAC model: each API key has a role (admin, operator, auditor), and the rate limit applies per key regardless of role. Enterprise deployments can configure per-role limit overrides by wrapping xGate's PerScopeLimiter with role-to-scope mapping.

Per-CLI Port Assignments

Ready to deploy xGate?

Talk to Sol, our AI platform engineer, or book a live demo with our team.

import {
  SlidingWindowLimiter,
  PerDidLimiter,
  PerScopeLimiter
} from '@private.me/xgate';

// Layer 1: Global per-IP sliding window
const global = new SlidingWindowLimiter({
  windowMs: 60_000,
  maxRequests: 1000
});

// Layer 2: Per-DID identity throttling
const identity = new PerDidLimiter({
  perConnection: { windowMs: 60_000, maxRequests: 20 },
  perDid: { windowMs: 60_000, maxRequests: 200 }
});

// Layer 3: Scope-specific overrides
const scoped = new PerScopeLimiter({
  defaultLimit: { windowMs: 60_000, maxRequests: 100 },
  scopeLimits: {
    'auth.rotate': { windowMs: 3600_000, maxRequests: 3 },
  }
});

// Apply all three layers in middleware
function rateLimit(req) {
  const ip = req.socket.remoteAddress;
  const r1 = global.check(ip);
  if (!r1.allowed) return r1;

  const r2 = identity.check(
    req.did, req.remoteDid, req.scope
  );
  if (!r2.allowed) return r2;

  return scoped.check(req.scope, req.did);
}