Credential policy, vault & proxy pools

merido gives operators three credential-related controls: a ToS policy engine that governs which clients may use subscription credentials, a BYOK vault for managing encryption keys, and proxy pools for routing outbound traffic. A related antiban layer shapes outbound requests to match first-party clients.

Credential ToS policy

Some upstream providers' terms restrict using a subscription credential (e.g. Claude Pro, ChatGPT, Copilot) from non-approved clients. The policy engine lets you decide how strictly to honor that:

GET  /api/policy                 # list policies: defaults, overrides, verdict tallies
PUT  /api/policy/{provider_id}   # override enforcement: off | warn | enforce
POST /api/policy/test            # simulate a verdict (no side effects)
POST /api/policy/reset-verdicts  # clear the in-memory verdict counters

Each provider ships with a default stance, and you can override it per provider:

• off — the credential is allowed for any client.
• warn — an unapproved client is allowed but flagged with a warning.
• enforce — an unapproved client is denied (and the request can fall back to another route).

The policy evaluates (provider, credential kind, client). Plain API keys are always allowed; the rules apply to OAuth subscription credentials, matching the client by user-agent / source. Overrides are stored as settings and verdict counts (allow / warn / deny) are surfaced in the list response.

BYOK vault

The vault encrypts org secrets at rest under per-org data-encryption keys (DEKs), each wrapped by a master KMS. It's off by default (secrets use the single built-in cipher); enable it with MERIDO_VAULT_ENABLED.

GET  /api/vault/status   # enabled?, KMS backend, active DEK version, KMS health
POST /api/vault/rotate   # rotate the org DEK and re-seal all secrets
POST /api/vault/byok     # import a customer-supplied 32-byte DEK (base64)

What it protects: OAuth tokens, IdP client secrets, and connection (provider) API keys — all re-sealed when you rotate or import a key. The KMS backend is selectable: an in-memory default, HashiCorp Vault Transit (MERIDO_VAULT_BACKEND=vault), or AWS KMS (MERIDO_VAULT_BACKEND=aws), with MERIDO_VAULT_KEY_ID. The vault fails closed: if the KMS is unavailable, secret operations error (503) rather than ever falling back to plaintext, and the failure is audited (vault.kms_failure). A re-seal interrupted by a crash resumes idempotently on the next startup.

Proxy pools

A proxy pool is a set of outbound proxies (HTTP/HTTPS/SOCKS5) you can attach to a provider connection so its upstream requests egress through a chosen IP.

GET    /api/proxy-pools                # list (URLs returned MASKED)
POST   /api/proxy-pools                # add { url, label?, active? }
DELETE /api/proxy-pools/{id}           # remove
POST   /api/proxy-pools/{id}/toggle    # flip active
POST   /api/proxy-pools/assign         # assign/unassign { connection_id, pool_id? }
POST   /api/proxy-pools/{id}/health    # liveness probe through the proxy

Proxy URLs are sealed at rest with the same cipher as provider keys, and only a masked form (http://user:***@host:port) is ever returned to the dashboard. Assignment is by stable pool id, so two proxies that happen to mask to the same string stay distinct. The health probe sends a timed request through the proxy and reports whether it's up, its latency, and any error. Clearing the assignment (pool_id absent / null) routes the connection directly again.

Antiban

For OAuth/native credentials, merido can optionally reshape outbound requests so they resemble traffic from the provider's first-party client — spoofing client headers (e.g. the Claude CLI's user-agent and x-stainless-* headers, or Copilot's editor headers) and cloaking third-party tool names before they reach the upstream (restoring them on the response). This is opt-in and applies only to OAuth/native credentials, never to metered API keys.

ToS risk

Spoofing client fingerprints and cloaking tool names may violate an upstream provider's terms of service. These helpers exist for interoperability and parity; enable them only where you accept that risk.

Related

• Add providers & keys — where connections and their credentials live.
• Access control & teams — who can manage these controls in an org.
• TLS interception (MITM) — the other feature that carries a ToS caveat.