Provider API keys are encrypted using AES-256-GCM. The encryption key is derived via PBKDF2-HMAC-SHA256 with 100,000 iterations. You can set your own encryption key with STOCKYARD_ENCRYPTION_KEY (minimum 32 characters), or Stockyard auto-generates one and stores it in the database on first boot.
Encrypted keys are never logged, never included in API responses, and never exposed in trace data. If someone gains access to the SQLite file without the encryption key, provider keys are unreadable.
Every request gets a hash-chained ledger entry. Each entry includes a SHA-256 hash of the previous entry, creating a tamper-evident chain. If any record is modified or deleted, the chain breaks and verification fails.
The audit ledger records: the request, the response, the model used, the provider, token counts, cost, latency, and which middleware modules ran. This is the Brand product.
Stockyard scans prompts for injection attempts using pattern matching and heuristic scoring. Requests are scored for injection risk, and you can configure thresholds to block, warn, or allow. This runs as a middleware module and can be enabled or disabled at runtime.
Automatic detection and redaction of personally identifiable information before prompts reach the LLM provider. This includes patterns for email addresses, phone numbers, and other common PII formats. Configurable per module, and runs in the middleware chain before the request is forwarded.
Configurable content filtering can block or flag requests and responses based on content policies. This runs as part of the middleware chain alongside prompt injection detection and PII redaction.
All data stays on your server. Stockyard stores everything in a local SQLite file. Traces, costs, audit logs, cached responses, and encrypted keys never leave your infrastructure. There is no telemetry, no analytics reporting, and no usage data sent to Stockyard or any third party.
On the free Community tier, there are zero outbound calls to Stockyard infrastructure. On paid tiers, the only Stockyard-directed call is license key validation on startup. See Does Stockyard phone home? for details.
Stockyard sets security headers on all responses: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, and Permissions-Policy. These are applied automatically on every page and API response.
Management API endpoints require the admin key (STOCKYARD_ADMIN_KEY) passed as an X-Admin-Key header. Without it, management endpoints return 401. The admin key is not the same as the encryption key and is not used to derive encryption material.
Stockyard is a single statically linked Go binary with embedded SQLite. There are no external services, no shared infrastructure, and no network dependencies beyond the LLM providers you configure. The attack surface is the binary and the port it listens on.
Database queries use parameterized SQL. User-rendered fields are escaped to prevent XSS. The binary has zero runtime dependencies beyond the Go standard library and modernc.org/sqlite (a pure-Go SQLite implementation, no CGO).
The entire codebase is source-available at github.com/stockyard-dev/Stockyard under BSL 1.1.
Stockyard does not currently have: SOC 2 certification, HIPAA compliance certification, formal third-party security audits, or multi-tenant role-based access control. SSO/SAML is planned for the Pro tier but is not yet available. These may come as the product matures. If your organization requires them today, Stockyard may not be the right fit yet.