Zero-trust architecture
All traffic flows through a hardened pipeline. No request is trusted by default. Each layer performs independent verification before passing the request inward.
Security posture
Middleware stack (8 layers)
Every inbound request traverses all eight layers in sequence, in the order listed. A failure at any layer terminates the request immediately. CORS, observability and check recording also run in this stack and do not block a request on security grounds.
| # | Layer | Function |
|---|---|---|
| 1 | Audit Logging | Structured request/response logging with tenant context |
| 2 | Sandbox Detection | Route sandbox keys to mock responses, enforce rate limits |
| 3 | Rate Limiting | Per-tenant and per-endpoint limits, Redis-backed |
| 4 | x402 Payment | Per-call USDC payment verification (Base + Solana) |
| 5 | Tenant Isolation | Request scoped to authenticated api_key_id, BOLA prevention |
| 6 | Request Size Limit | Reject oversized payloads before processing |
| 7 | Security Headers | HSTS, CSP, X-Frame-Options, X-Content-Type-Options |
| 8 | Host Validation | Reject requests to unknown hostnames |
Tenant isolation
Every data-bearing operation is scoped to the authenticated tenant's api_key_id. This is designed to prevent cross-tenant access.
BOLA Prevention
Broken Object Level Authorization (OWASP API Top 10 #1) is prevented at the middleware layer. Seven dedicated fixes ensure no endpoint accepts a tenant-scoped identifier without ownership verification. Attempting to query another tenant's data returns HTTP 403, never 404, preventing enumeration attacks.
Audit Trail
Every scored check is recorded in an append-only audit trail, chained with SHA-256 hashes so that any change to an earlier entry breaks the chain; any API key can verify it at GET /v1/audit/verify. An entry holds the API key, timestamp, score, recommendation and a hash of the entity name, never the name itself. Key creation and GDPR requests are recorded in the application logs. Audit entries are removed only by a GDPR erasure request or when their retention period ends.
Container hardening
The Limitguard API runs in a hardened container with the following security configuration:
read_only: true: filesystem is read-only; no runtime writes to container layercap_drop: [ALL]: all Linux capabilities droppedsecurity_opt: [no-new-privileges:true]: privilege escalation blocked- Non-root system user (
limitguard, UID 999): process runs without elevated permissions - Internal Docker network: no direct external access; all traffic via Caddy proxy
- Minimal base image: Debian slim, reduced attack surface, no dev tools in production
Compliance coverage
| Standard | Coverage | Status |
|---|---|---|
| OWASP Web Top 10 | Injection, broken auth, misconfiguration, XSS, IDOR | Addressed |
| OWASP API Top 10 | BOLA (#1), broken auth (#2), excessive data exposure (#3) | Addressed |
| OWASP Agentic Top 10 | Prompt injection guards, output validation, tool call auditing | In progress |
| NIST 800-207 Zero Trust | Identity verification, micro-segmentation, least privilege | 72/100, self-assessed, improving |
| GDPR | Data minimization, right to erasure, DPA available, EU hosting | Addressed |
Continuous security
| Check | Frequency | Tooling |
|---|---|---|
| SAST (Static Analysis) | Every pull request + nightly | Semgrep with custom ruleset |
| Active Penetration Testing | Nightly on ephemeral Hetzner VPS | Phase 2 active scan pipeline |
| Passive Security Checks | Nightly at 02:00 UTC | TLS, headers, response codes |
| Alerts | Real-time on critical/high findings | Slack notifications (#limitguard) |
Incidents get a public post-mortem. The most recent, covering the outage of 2026-06-19 to 2026-09-05 and what changed as a result, is at docs.limitguard.ai/postmortems.
Responsible disclosure
We operate a responsible disclosure program. Security researchers are encouraged to report vulnerabilities before public disclosure. We aim to acknowledge reports within 48 hours and resolve critical findings within 14 days.
Report security issues to security@limitguard.ai. The same contact is listed in our security.txt. We do not pursue legal action against good-faith researchers acting within the scope of our disclosure policy.
For data processing and privacy commitments, see our Data Processing Agreement.
