Skip to main content
Keep authorization and data-access decisions in your application. Model output, retrieved text, and media can inform a decision, but should not determine which permissions the caller receives.

​
Protect API keys

  • Store PERCEPTRON_API_KEY in a server-side secret manager or environment variable. Keep it out of browser bundles, mobile application packages, public notebooks, source control, and model messages.
  • Use separate keys for workloads that need independent revocation, and revoke keys that are unused or exposed. Separate keys in one organization still share organization-level request limits.
  • Redact authorization headers and secrets from logs, error reports, and screenshots. Send requests over HTTPS and keep certificate verification enabled.

​
Treat supplied content as data

Instructions can appear in an image, an OCR result, a web page, or a tool response. Keep that material separate from trusted system instructions and identify where it came from. For example, ask the model to summarize a retrieved document rather than treating the document’s instructions as commands for your application. Prompt wording alone is not a permission boundary. Enforce access checks and tool restrictions in code even if the prompt says to ignore malicious instructions. Return only the passages or media needed for the task, and avoid putting credentials or unrelated private records in the conversation. Treat model output as untrusted when displaying it. Escape text or render only supported annotation elements; do not insert arbitrary generated HTML into a page or execute returned code. Validate coordinates, selectors, timestamps, and data schemas before using them. Reject invalid geometry rather than silently clamping it into a plausible observation.

​
Authorize tool execution

The model proposes function calls; your application decides whether and how to execute them.
  • Dispatch only explicitly registered function names. Parse arguments as JSON and validate types, allowed values, required fields, and size limits before dispatch. Function strict does not enforce this validation for you.
  • Check the requesting user’s permission for each resource and action. Keep database credentials and service tokens in the tool implementation; do not expose them as model-visible arguments or results.
  • Use parameterized queries and APIs with structured arguments. Do not concatenate model-generated values into shell commands, SQL, or unrestricted filesystem paths.
  • If a tool fetches a URL, validate its scheme, destination and redirects, and enforce download-size and timeout limits. A model-selected URL should not grant access to private network services.
  • Apply the application’s confirmation policy before consequential writes, and use operation IDs or idempotency controls where available. A retried model request must not automatically repeat an action that already succeeded.
tool_choice: "none" is a best-effort generation control, not an execution guard. Stop dispatching calls when the application’s permissions or budgets prohibit further work, regardless of what the model returns. See tool calling for the request contract and agent budgets for bounded execution.

​
Control media access

The Files API checks the caller’s organization when accessing uploaded files. A file ID is not a substitute for your application’s per-user authorization: check that the user may access the media before including it in a request or returning its contents. Use file references or appropriately restricted media URLs for private inputs. A signed URL grants access to whoever holds it until its access conditions expire; keep it out of public examples and logs, limit its scope and lifetime, and allow enough time for the intended request to fetch it. Do not assume that a private bucket makes a signed URL safe to share publicly. Remove unnecessary personal or proprietary data before uploading. Apply access controls to your saved prompts, generated answers, crops, overlays, and batch results as well as to the original media. Protect exported files in your own storage, and use the delete endpoint when an uploaded file is no longer needed; manage copies in your application separately.