How we protect provider credentials

When you connect OpenAI, Anthropic, or Google to shim, we store the credential needed to execute approved inference requests on your behalf. Here is what happens to that key.

• Secret-backend storage

  Production deployments store provider credentials in the configured external secret manager. The application database holds a tenant-bound reference, not the plaintext key. Fernet is restricted to local-development deployments.

• Encrypted in transit

  All public traffic runs over HTTPS using modern TLS. HSTS is enforced for one year with includeSubDomains.

• Write-only after creation

  Once you paste a key, the dashboard only ever shows a masked suffix (...****abc1). It is never returned in plaintext to any client, including yours.

• Decrypted on demand

  Decrypted provider credentials are resolved for one invocation and are never placed in process-global state. Rotation or revocation therefore applies to subsequent requests without changing a shared SDK client.

• Tenant-isolated lookups

  Every credential lookup is scoped by tenant_id and an expected secret purpose at the resolver boundary.

• Revocable in one click

  Revocation removes the tenant's secret reference and schedules deletion from the configured secret backend, so it cannot be resolved for a new invocation.

How we handle your prompts

Every request you send through shim passes through a fixed pipeline. Here is what that pipeline does, in order, and what is retained at each step.

1. 1

   Auth & model admission

   Your sk-shim-* key is verified against a SHA-256 hash: we never store the plaintext key. Admission estimates are computed in memory and discarded, and provider-reported usage is settled later. Chat Completions and Anthropic Messages require an approved, priced model. OpenAI Responses may omit it and use the provider default. Explicit unapproved models are rejected before execution.

2. 2

   PII scrubbing

   When enabled by tenant policy, configurable detectors run before the prompt is sent upstream or operational facts are logged: Microsoft Presidio plus custom recognizers for AWS access keys, modern GitHub tokens, JWTs, Turkish national ID (TCKN) and tax ID (VKN), and Luhn-checked credit card numbers. Each organization can enable or disable detection per entity class.

3. 3

   Rate, quota & spend policy

   RPM, TPM, request quota, loop protection, and spend limits are evaluated before the upstream call. Required capacity and budget are reserved so concurrent requests cannot silently oversubscribe the tenant's policy.

4. 4

   Provider call

   The gateway forwards the governed request through the native OpenAI, Anthropic, or Google Gemini Developer API using the request-scoped credential. If PII redaction is enabled, the selected provider receives the redacted payload.

5. 5

   Usage & audit settlement

   shim returns the response and settles reserved usage and cost against actual results. Durable records include request identity, endpoint, model, status, token and cost facts, and policy outcomes: never the raw prompt or response body.

Encryption & data handling

Infrastructure & availability

• Where it runs

  Backend on Google Cloud Platform (Cloud Run, europe-west3 / Frankfurt). Frontend on Vercel. Multi-region active-active is on the roadmap.

• Network

  All public traffic over HTTPS. HSTS is enforced for one year with includeSubDomains on both the gateway and the marketing site. Redis and any internal services run inside a private VPC and are not publicly routable.

• Monitoring

  Sentry for error telemetry, configured with send_default_pii=False so default user emails, IPs, and cookies are not collected. A before_send sanitizer strips request payloads, authorization data, cookies, and sensitive custom fields before events leave the application.

• Failure mode

  shim does not silently bypass required governance. If required state is unavailable, the affected request fails explicitly. A missing, corrupt, or expired OpenAI Responses continuation mapping is rejected before the OpenAI call.

• Status page

  A public status page is on the roadmap. In the meantime, incidents are communicated to affected customers by email.

Compliance & certifications

We list the actual posture for each framework. Where we are not certified, we say so. Where work is underway, we will name the auditor and timeline once they are contractually firm.

Need our Data Processing Agreement? legal@getshim.tech

Access controls & audit

• Internal access

  Production access is restricted to a small number of engineers under documented controls. Provider secret values live behind the configured secret-backend boundary, so application-database read access alone does not reveal plaintext credentials.

• Secret-backend boundary

  Production configuration requires a supported external secret manager. GCP Secret Manager, AWS Secrets Manager, and Azure Key Vault backends are supported. Fernet is a local-development implementation and is rejected for production startup.

• Request analytics

  Every gateway request is recorded with organization_id, api_key_id, timestamp, endpoint, model, status, token counts, cost, and policy outcomes: never the raw prompt or response body. These are visible to your organization's admin in the dashboard and exportable as CSV / JSON.

• Admin-action audit log

  Audit and compliance views preserve evidence for credential lifecycle events, shim API-key issuance and revocation, policy changes, request outcomes, and usage settlement. Reports support oversight. They are not a certification or a substitute for legal advice.

Vulnerability disclosure

We welcome reports from the security community.

• Reporting address: security@getshim.tech
• Scope: *.getshim.tech and the sk-shim-* API. Out of scope: upstream provider systems, social engineering, denial-of-service.
• Response SLA: acknowledgment within 2 business days, triage update within 5.
• Safe harbor: we will not pursue legal action against good-faith research that respects user privacy, follows the scope above, and gives us a reasonable window to remediate before public disclosure.

A formal bug-bounty program and a published PGP key are on the roadmap.

Sub-processors

Third parties that may process customer data on our behalf. We update this list as our infrastructure changes. Material additions are communicated to active customers by email.

Documents & contact