Security and privacy

How to handle keys, what to avoid sending, and the boundaries of this service.

Key handling

• Keys are shown in full once. Store them in a secret manager or environment variable.
• One key per service or machine so revocation is surgical.
• Revocation takes effect immediately.
• Never put a key in client-side JavaScript, a mobile binary, or a public repository. Anything shipped to a user is public.
• If a key leaks, revoke first and investigate afterwards.

What to avoid sending

This is a third-party gateway sitting between you and the upstream provider. Treat it as an external processor:

• Do not send data you are contractually barred from sharing with a subprocessor.
• Do not send regulated data — health records, payment card numbers, government identifiers — without a legal basis for doing so.
• Redact secrets before sending logs or config files to a model. Agents that read whole files will happily read your .env.

Prompt injection

Any content the model reads can attempt to instruct it — web pages, files, tool results, issue comments. Consequences follow from what the model can *do*, so constrain that:

• Give database tools a read-only role.
• Scope API tokens to the minimum needed.
• Require human approval for irreversible actions.
• Never eval model output or execute generated SQL against a writable connection.

Transport

All traffic is HTTPS. Reject plain HTTP in your own client configuration; a base URL of http:// would send your key in cleartext.