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.
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:- Verify the connected identity and permission.
- Display the intended target and side effect.
- Obtain confirmation where required.
- Avoid unbounded retries.
- Verify the external result.
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?