Build security-rail rate limiting for abuse detection and cost control

[ebursztein]

Summary

Capsem needs a first-class rate limiting system in the security rail. This should not be implemented as a DNS-handler one-off. Rate limits are a general security and cost-control primitive that must operate over normalized security events and feed the same detection/enforcement ledger as every other rule.

Why this matters

Recent AGY/security testing highlighted DNS-tunneling style exfiltration risk: arbitrary DNS query bursts can encode data in subdomains and bypass HTTP/HTTPS allowlists if DNS is only treated as a resolver mechanic. The initial implementation idea tried to add DNS-local burst state, but that is the wrong abstraction. The same primitive is needed for:

• DNS tunneling and suspicious qname bursts
• model/API spend and token/cost control
• MCP/tool-call spam or repeated dangerous tool use
• HTTP request bursts to sensitive domains or endpoints
• plugin abuse, including credential broker and future scanning plugins
• per-VM, per-profile, and possibly per-corp budget enforcement

Desired architecture

• Rate limiting lives in the security rail, not protocol-specific handlers.
• Inputs are first-party SecurityEvent objects after protocol parsing/normalization.
• Outputs are normal security detections/enforcement decisions and ledger rows.
• Rules should be expressible through the same profile/corp rule system where possible.
• State should be bounded, inspectable, and keyed by explicit dimensions such as profile, VM, event type, rule id, host/qname/provider/tool, or credential ref.
• The implementation must preserve the single security engine path: no parallel DNS policy engine, MCP policy engine, model policy engine, or hidden shortcut.

Example use cases

• Block or flag high-rate DNS queries under the same suffix, e.g. many unique labels under example.com within a small window.
• Ask/block when a model provider crosses a cost, request, or token budget for a VM/profile.
• Detect repeated MCP tool calls such as file export, HTTP fetch, or shell execution in a short period.
• Detect high-rate HTTP requests to one domain even when each individual request is otherwise allowed.

Acceptance criteria

• Define a rate-limit/security-budget contract that is protocol-agnostic and profile-aware.
• Add a bounded in-memory implementation with explicit eviction and telemetry counters.
• Expose rate-limit matches as first-class detection/enforcement ledger rows with rule id, matched event id, threshold/window, key, and current count/cost.
• Support at least DNS burst detection and model cost/token budget enforcement as proof points.
• Add tests for DNS, HTTP, MCP, model, plugin-triggered events, and per-VM/profile isolation.
• Add UI/TUI/API visibility for active counters/status without reading session DB on hot paths.
• Document the authoring model and invariants in the security architecture docs.

Notes

This came from the 1.3 debug loop. The key decision: do not patch DNS with a local rate limiter. Build the general rail once and let DNS tunneling become one rule/use case of that system.