Overview#
A platform drawing on dozens of external AI models, enrichment services, and intelligence feeds needs a single place to track which providers are healthy, what they cost per call, and how they perform under load. The Provider domain is that registry: it stores provider definitions, monitors their availability, collects telemetry on every request, and manages the user API keys needed to access them securely.
Key Features#
- Provider registry with definitions including name, category, description, and capability tags
- Health monitoring with status checks, availability tracking, and error details
- Telemetry collection for individual requests with latency, cost, token usage, and success tracking
- Aggregate statistics with success rates, average and high latency, and total cost/token summaries
- User API key management with encrypted storage and upsert operations
- Rate limit configuration per provider
- Category-based organisation: LLM, enrichment, OSINT, threat intelligence, and blockchain
Use Cases#
Relevant sectors include intelligence agencies, financial crime investigation, and law enforcement.
- Managing a registry of external AI and intelligence providers with health monitoring
- Tracking per-provider telemetry to optimise cost, latency, and reliability across services
- Securely storing and rotating user API keys for third-party provider access
- Monitoring provider health to enable automatic failover and degradation handling
Integration#
The Provider domain connects with LLM integration, OSINT provider services, blockchain analytics, and prompt management systems.
Open Standards#
- GraphQL (June 2018 specification): All provider registry queries and mutations, definitions, health, telemetry samples, and API key management, are exposed exclusively through a GraphQL schema, enabling strongly-typed, self-documenting access to the registry.
- JSON Web Token (RFC 7519) and JSON Web Key (RFC 7517): Every request to the provider registry is authenticated by validating a JWT signed with RS256; the service fetches and rotates the public key set from a JWKS endpoint, enforcing issuer and audience claims.
- OAuth 2.0 Bearer Token Usage (RFC 6750): The middleware extracts and validates access tokens presented as HTTP Bearer credentials, providing the authentication context that gates all provider domain operations.
- PBKDF2-HMAC-SHA256 (RFC 2898 / NIST SP 800-132): User API keys stored in the registry are protected at rest using a key derived via PBKDF2-HMAC-SHA256 with a configurable salt and a minimum of 600,000 iterations, aligned with OWASP 2023 guidance.
- Fernet symmetric encryption (AES-128-CBC with HMAC-SHA256): The encrypted blob stored for each user API key uses the Fernet scheme, which combines AES-128-CBC confidentiality with a HMAC-SHA256 authentication tag to prevent tampering.
- Prometheus exposition format: Authentication failure counters and other operational metrics collected alongside provider telemetry are exported in the Prometheus text-based exposition format for scraping by compatible monitoring systems.
- JSON (RFC 8259): Telemetry samples are serialised as JSON documents for storage in the rolling state cache and returned as the canonical wire format for all provider registry API responses.
- W3C Trace Context / OpenTelemetry: The middleware propagates distributed trace context on all provider calls using the W3C Trace Context specification, enabling end-to-end latency attribution across provider invocations.
Last Reviewed: 2026-02-05 Last Updated: 2026-04-14