An AI with production access, and the perimeter around it

Nothing changes without your confirmation

Every mutation follows the same sequence: OrchestrAI proposes a plan, shows the cost estimate and blast radius, and waits. Nothing runs until you approve it. Destructive operations go further and require a typed risk phrase, so a stray "yes" cannot tear down production. Read-only work such as inventory, drift scans, and cost analysis never changes anything.

Credentials and access

• AWS. You create an IAM role in your account with an external ID and the permissions you choose. OrchestrAI assumes that role through STS for each run and works with session credentials that expire. It never needs long-lived access keys.
• GCP. You create a workload identity pool and a service account with the permissions you choose. OrchestrAI exchanges a short-lived identity token for a one-hour impersonation token per run. No service-account key is ever uploaded.
• Azure. You register an app in Entra ID with a federated credential trusting OrchestrAI. Each run exchanges an identity token for an access token scoped to your subscription. No client secret is ever uploaded.
• Connected services. Integrations such as GitHub, Datadog, or Snowflake use API tokens you provide. They are envelope-encrypted with a per-record key wrapped by a cloud KMS, decrypted only for the run that needs them, and deleted when you disconnect the service.
• Least privilege is yours to set. OrchestrAI operates only within the permissions the role or account carries. Start read-only if you want to see inventory, drift, and cost before granting anything more.
• Scoped inside the product. Role-based access with org and project scoping decides who can run what, where, and with which credentials. Sensitive changes can route to named approvers before they run.

Spend controls

Every plan carries a cost estimate before execution. Per-project spend caps are enforced at run time, not just displayed. A sandbox mode lets you rehearse changes without touching real infrastructure.

Audit trail and replay

Every run records what was requested, what was planned, who approved it, what changed, and the logs and artifacts it produced. History is durable and replayable for incident reviews, security questions, and compliance requests.

What we store, and for how long

• Account data. Email, basic profile from your sign-in provider, plan, and billing status. Card numbers are held by our payment processor, not us.
• Cloud connections. The role, workload identity, or federated credential you grant, plus its configuration. No long-lived cloud keys are held; per-run tokens are discarded when the run ends. Connection records are removed when you disconnect the account or delete yours.
• Run history and the ledger. Prompts, plans, approvals, run logs, and the managed-resource ledger, kept while your account is active so the product can do its job and you have an audit trail.
• Analytics. Product analytics for our own sites and app. Analytics never sees the contents of your cloud accounts.

Data is encrypted in transit. If you stop using OrchestrAI, the infrastructure in your cloud accounts is yours and stays exactly as it is. The full policy is at /privacy.

Compliance status

Until then, the controls on this page are what you can verify yourself: connect an account read-only, watch a proposed change wait for your confirmation, and read the run log afterward.

Reporting a vulnerability

If you find a security issue, email security@orchestrai.io with enough detail to reproduce it. You will get a human reply. Please give us a reasonable window to fix the issue before publishing.