Shift log: lock down the AI API call path

The first security boundary in an AI app is not the prompt. It is the route from your user, through your application, to the model provider. Before shipping a chat box or coding assistant, walk that route and check who can send requests, which data leaves your system, and what a response can trigger.

Keep the provider key behind your server

1. Send requests through a backend you control. Never embed a provider key in browser JavaScript, a mobile package, a public repository, or a downloadable configuration file. Anything delivered to a user's device should be treated as readable by that user.

For local development, use an environment variable and keep local secret files out of version control. For deployment, use your platform's secret-management facility. Separate development and production credentials, restrict access, and verify that errors never print authorization headers. If a key leaks, revoke it; deleting the visible copy is not enough.

Verify the destination before sending real data

2. Configure the API destination explicitly and require HTTPS with certificate verification enabled. Do not let a user-provided URL silently become your backend's API destination. Where practical, allow only approved outbound hosts.

Relay365 is a pay-as-you-go relay desk for multiple model families and can fit applications that want one integration point. Its API base is https://api.api365relay.com; OpenAI clients add /v1. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients. Before using any relay, review its data handling, retention, access controls, and upstream routing. A compatible API does not automatically mean identical security behavior.

Check the user's identity and spending boundary

3. Authenticate users before accepting paid requests, then authorize access to the specific workspace, conversation, or document involved. A valid login does not grant access to every stored conversation.

Apply server-side limits to request size, concurrency, request frequency, and output length. Track spending per user or tenant and define an enforceable budget boundary. Provider-side limits, where available, are additional protection rather than a substitute. Limit retries so a timeout cannot produce an uncontrolled request loop.

Reduce the data that crosses the API boundary

4. Send only the context needed for the task. Remove passwords, session tokens, unnecessary personal information, and unrelated customer records before constructing a request. Check uploaded files and retrieved documents, not just the visible chat message.

Use synthetic examples while testing a model such as Gemini 2.5 Flash. Before introducing production data, establish which information may leave your environment and who approved that decision. Do not assume that a provider or relay disables storage or training use unless its applicable terms and settings confirm it.

Treat retrieved text and model output as untrusted

5. Assume that documents, web pages, and user messages can contain instructions designed to redirect the assistant. Keep trusted application instructions separate from external content, but do not treat prompt formatting as an access-control mechanism.

Never let model output decide authorization or become executable code without an appropriate controlled process. Escape generated text when rendering it, validate structured responses against a schema, and use parameterized database queries. The model should not be able to obtain secrets simply by asking another component for them.

Put approval gates around consequential tools

6. Start with read-only tools and narrowly scoped credentials. Enforce tool permissions in application code, including which records, paths, and destinations each user can access. Validate tool arguments even when the model produces well-formed output.

Require explicit confirmation before consequential actions such as sending messages, deleting files, or making purchases. Show the proposed action and target clearly. Test attempts to bypass these checks through uploaded documents or misleading tool results.

Prepare logs and a shutdown path before launch

7. Record request identifiers, timing, model selection, errors, and usage without logging secrets or full prompts by default. Restrict log access and define retention. Practice revoking a key, disabling a tool, and stopping outbound requests.

If Relay365 fits your integration and data-handling requirements, create an account and run this checklist with synthetic data first. Release only after the same checks pass in the deployed environment.