In brief
- Keep provider keys server-side and scoped.
- Treat model output as untrusted input.
- Authorize every tool action independently.
Protect credentials at the boundary
Store keys in a secret manager or protected environment, send requests from trusted server code, scope access where possible, and rotate on exposure. Never ship a reusable provider key in a browser or mobile bundle.
Classify data before sending it
Define what customer data, source code, regulated information, and secrets may enter prompts. Apply redaction, retention, regional, and provider controls according to the data class.
Treat output as untrusted
Escape rendered content, validate structured output, sanitize URLs, and do not execute generated code or commands merely because they came from a model.
Authorize tools outside the model
The application must enforce identity, permissions, target scope, parameter validation, rate limits, and confirmation for consequential actions. The model proposes; trusted code authorizes.
| Control | Question |
|---|---|
| Identity | Who initiated this operation? |
| Permission | May they perform this exact action? |
| Scope | Are targets narrowly resolved? |
| Validation | Are parameters safe and typed? |
| Audit | Can the action be reconstructed? |
Frequently asked
Questions, answered plainly.
Can I put an AI API key in frontend code?+
Do not expose a reusable secret in client code. Proxy requests through an authenticated server boundary or use a provider-supported short-lived client credential.
Is prompt injection only a prompt problem?+
No. It is a trust-boundary problem. Limit untrusted content, separate instructions from data, and enforce tool permissions outside the model.
Should model output be HTML-rendered?+
Only after safe parsing and sanitization. Prefer text rendering unless the product specifically requires restricted rich content.
Sources and next paths