Skip to main content
AIsa routes requests to upstream model and data providers and is designed to keep as little of your data as possible.

​
Data processing

  • Requests are processed in real time to route each call to the right upstream provider, and responses are returned directly to you.
  • AIsa does not use your data for training or analytics.

​
Prompt and output retention

AIsa follows a no-storage policy for request content:
  • Prompts and inputs are not stored.
  • Responses and outputs are not stored.
  • Request payloads are processed transiently and discarded when the request completes.
This applies to every API: models, embeddings, video, social, web search, scholar, and finance.

​
Operational metadata

AIsa keeps limited metadata needed to run and protect the platform - request timestamps, API key identifiers, endpoint and model, token counts and cost, rate-limit counters, and status or error information. This metadata does not include prompts, inputs, or outputs, and is not used for training or content analysis. It is what you see in Usage & Logs.

​
Authentication and transport

  • Every request is authenticated with an API key or an OAuth session; unauthenticated requests are rejected. See Authentication.
  • With MCP and the CLI, OAuth tokens are held by the client and refreshed automatically. Agents must not read, copy, or reuse a client’s OAuth tokens.
  • All endpoints are served over HTTPS only. Protocol versions and cipher configuration are managed at the infrastructure level.
You are responsible for keeping API keys secret, limiting what each key may spend, and rotating keys.

​
Upstream providers

To fulfil a call, AIsa forwards the data that call needs to the selected provider, and nothing more. AIsa does not persist request content before or after forwarding. Data handling by the provider is governed by that provider’s terms; review them when your use case requires it. For sensitive workloads, decide which fields are sent, whether they can be minimized or redacted, which regulatory or contractual rules apply, and whether the result itself may contain sensitive data.

​
Agent safety controls

  • State-changing actions: For operations that create, update, delete, or send data externally, ensure your agent confirms the target and intended changes with the user before executing. Never enable unrestricted automatic retries on side-effecting operations, and verify the result in the external system before reporting success. Permission to read is never permission to write.
  • Budget boundaries: Give each agent its own API key with a spending limit; that limit is the hard ceiling. On endpoints that declare maximum-price support, and in MCP use, a maximum price also rejects a call whose estimate is too high before any provider is called. It checks the estimate and does not cap the final charge. See Billing & Credits.
  • Operational resilience: In production, configure timeouts, handle rate limits gracefully, alert on low balances, and avoid printing raw credentials in application logs.

​
Questions for a security review

  • Which capability and upstream provider will process the request?
  • What data is sent, and what is logged?
  • Which credentials and permissions are required?
  • Does the operation have an external side effect?
  • How are spend and retries bounded?
  • What evidence verifies the final result?
Answer capability-specific questions from the exact endpoint or Skill page, not from a general platform description.