Skip to main content
Use this page as an evaluation checklist. The detailed security policy is maintained in Security and Data Privacy, and API-key guidance is maintained in Authentication.

Authentication

AIsa API requests use Bearer-token authentication unless the exact capability documentation states otherwise. Evaluate:
  • How keys are created, scoped, stored, and rotated.
  • Whether development and production use separate credentials.
  • Whether logs, errors, and analytics exclude credentials.
  • Which people or services can access the key.
Do not embed keys in client-side applications, public repositories, documentation examples, or agent prompts.

Request and response data

Review Security and Data Privacy for AIsa’s documented processing and retention model. Also consider the selected upstream provider, because provider-specific terms may apply to data required to fulfill the request. For sensitive workloads, identify:
  • The data fields sent to AIsa and upstream providers.
  • Whether the task can minimize or redact those fields.
  • Applicable regulatory or contractual restrictions.
  • Whether the result may contain sensitive data.

External actions

Writes require stricter controls than reads. Before an action that sends, publishes, creates, updates, or deletes external data:
  1. Verify the connected identity and permission.
  2. Display the intended target and side effect.
  3. Obtain confirmation where required.
  4. Avoid unbounded retries.
  5. Verify the external result.
Read access must not be treated as authorization to write.

Payments and billable calls

For programmatic payment or billable agent workflows, define spend limits, confirmation thresholds, duplicate-charge handling, and audit records. See:

Operational controls

Production integrations should define:
  • Request timeouts and rate-limit handling.
  • Separate retry policies for idempotent reads and side-effecting operations.
  • Budget or balance alerts.
  • Sanitized error reporting.
  • Dependency health checks and fallback behavior.
  • Verification before reporting that an operation succeeded.

Security questions for procurement or review

  • Which exact capability and upstream provider will process the request?
  • What data is sent, stored, or logged?
  • Which credentials and permissions are required?
  • Does the operation create an external side effect?
  • How are spend and retries bounded?
  • What evidence verifies the final result?
Use the exact API or Skill page to answer capability-specific questions. Do not rely on a general platform description for endpoint-level security assumptions.