Security and Data Handling

Security controls apply at different layers. Authentication, network restrictions, model access, routing region, retention, and upstream provider policy should be evaluated together.

Data path

A model request can involve:

  1. your application and logs;
  2. the Token360 API gateway, routing, metering, and operational records;
  3. the selected upstream model provider;
  4. optional assets, generated media, webhooks, or download storage.

A control at one layer does not automatically configure the others.

Credentials and account security

  • Store API keys in a server-side secret manager.
  • Use separate keys by environment and service.
  • Apply expiration, spend limits, and IP restrictions where appropriate.
  • Enable authenticator-app MFA for console access.
  • Enterprise administrators should regularly review members, model access, and tenant-wide key metadata.

IP policies

Token360 supports per-key IP rules for eligible accounts and a tenant-wide enterprise IP policy. A tenant policy applies globally to the tenant's inference keys. Plan an emergency access and rollback procedure before enforcing a narrow allowlist.

IP allowlisting limits network origin; it does not replace key rotation, MFA, or application authorization.

Data residency

Enterprise data-residency configuration constrains eligible inference routing to the configured compliance jurisdiction where supported. Availability depends on the selected model and configured routes.

Data residency describes where eligible inference is routed. It is not, by itself, a statement about application logs, webhook destinations, asset storage, retention duration, or whether an upstream provider uses data for training. Review the applicable agreement and privacy documentation for those commitments.

Retention and content visibility

Retention differs by data type and feature. Before sending sensitive data, determine the applicable policy for:

  • request and response content;
  • request metadata, usage, latency, and cost;
  • uploaded assets and asset groups;
  • generated images, audio, and video;
  • signed download URLs;
  • webhook request bodies and your webhook receiver logs;
  • support material you choose to provide.

The console may show metadata even when prompt or output content is unavailable. Signed media URLs can expire without deleting the underlying resource; use the documented download endpoint to obtain a fresh URL when supported.

Data inspection control

For generation requests, Token360-DataInspection: true|false requests the documented upstream inspection behavior. Omission defaults to false. Support varies by route, and models without a configured switch keep their upstream behavior.

This header is a content-inspection routing control. It is not a retention, residency, or training opt-out.

Webhooks

  • Use HTTPS endpoints.
  • Verify the Token360 signature when a signing secret is configured.
  • Compare the timestamp and raw request body when validating the HMAC.
  • Make handlers idempotent because delivery can be retried.
  • Return a 2xx only after the event is durably accepted.
  • Do not place credentials or sensitive records in webhook URLs.

Sensitive workloads checklist

  • Confirm the model and route are approved for the data classification.
  • Minimize or redact personal and confidential data before inference.
  • Configure workspace, model access, IP policy, and residency.
  • Define retention and deletion requirements for assets and generated media.
  • Ensure application logs do not record authorization headers or unnecessary content.
  • Test access denial from an unapproved key, model, and IP.
  • Keep request and trace IDs for audit without storing the API-key secret.

For binding retention, privacy, residency, or training commitments, use the current Token360 agreement and legal documentation applicable to your account.

Was this page helpful?