Where your data lives, and what an agent can never do.

The whole platform is in one EU region

No third-party storage in the path

Orchestra uses no external database — no Supabase, Neon or AWS RDS — and no external object storage — no Amazon S3, Cloudflare R2 or Cloudinary. Everything we store sits on our own EU infrastructure. Backup snapshots are held in a Railway Storage Bucket on the same platform (§10).

Where data does leave the EU

Orchestra is an AI platform, so at runtime it forwards content to the model providers that power your agents and to the tools you connect. Some of those are outside the EU. That is a processing transfer, not a storage transfer, and it is governed by DPAs and Standard Contractual Clauses (§12, §13). If your policy forbids any processing outside the EU, there is an EU-only configuration (§13).

• Dedicated instance. Your agents run in their own container, provisioned as their own Railway service, with their own persistent volume. Nothing about your agents runs in a process shared with another customer.
• Dedicated storage. Configuration, workflows, uploaded files and agent working data live on your volume only. They are never written to the shared platform database.
• Per-instance secret. Each instance holds its own 256-bit random token. The platform authenticates to your instance with that token and no other, and the comparison is constant-time. A compromised instance cannot impersonate another, and it holds no platform-wide credential.
• Platform keys stay on the platform. Keys Orchestra supplies — transcription, search, trial model access — are held server-side and are never injected into or readable from a customer instance.
• Instance identity is not on the disk. A volume carries no identity of its own. It cannot be attached elsewhere and used to act as your tenant.
• Agents cannot grant themselves authority. A small set of routes — who may open a published page, what a secret contains, which version visitors are served — accept only a call originating from a person in the portal, never an agent’s own token. An agent cannot approve its own work.

• In transit. HTTPS/TLS on all traffic to and between Orchestra services, and on all calls out to providers and connected tools.
• At rest, application layer. Third-party API keys, OAuth refresh tokens and messaging bot tokens are encrypted with AES-256-GCM — a fresh random IV per value and an authentication tag, so a tampered ciphertext fails to decrypt rather than decrypting to something else.
• At rest, infrastructure layer. Railway encrypts environment variables and volumes at rest.
• Credentials are write-only from the UI. A key you enter is never returned by the API and is masked in the portal. It is not stored as an environment variable on your container.
• Card data never reaches us. Payment details are handled by Stripe under PCI-DSS. Orchestra stores subscription metadata only.

Sign-in

• One-time codes, not passwords. Sign-in uses a cryptographically random six-digit code sent to your email. Orchestra does not store passwords for the portal.
• Codes are hardened. Ten-minute expiry, five attempts maximum, and a rate limit of three codes per address per fifteen minutes. Issuing a new code invalidates the previous one.
• Short-lived sessions. API tokens expire after one hour. Portal admin sessions use httpOnly, secure, sameSite cookies.
• Separate code namespaces. Codes issued for a published Canvas page live in a different store from portal sign-in codes and are scoped to a single instance, app and page. A code someone is tricked into typing on a page they were invited to can never satisfy portal sign-in — by construction, not by a filter.

Inside a workspace

• Organizations. An instance is owned by an organization and people are members of it. Removing someone from the organization removes their access.
• Capability-based roles. Roles map to named capabilities rather than hardcoded screens: manage workspace, members, billing, instance, agents, organization profile and published apps. Today there are two roles — admin, with all capabilities, and member, who can use the workspace but change nothing about it.
• Administrative access is a separate role with its own gate, not a flag on a normal account.
• Origin allowlist. The API accepts browser calls only from Orchestra’s own origins.

You choose an access level per integration

For every integration you connect — Gmail, Drive, Slack, a CRM, a ticketing system — Orchestra classifies each available tool as read, write or delete, and builds the permission request from the level you choose.

The boundary is enforced by the provider, not only by us

Orchestra requests the minimum OAuth scopes your chosen level requires. If you grant read-only access, the agent physically cannot write or delete in that service, because the credential it holds was never granted those permissions. That check happens at Google, at Slack, at your CRM — not inside Orchestra.

And it is enforced a second time, by us, at execution

Each connection you make gets its own dedicated authorization config carrying its own tool allowlist. Before any tool runs, Orchestra checks the tool against that allowlist and returns a hard refusal if it is not there. This second gate exists deliberately: the upstream allowlist is a discovery filter, so treating it as an execution policy would leave a gap. Orchestra closes it.

You stay in control of the catalogue

• Revoke any integration at any time. Revocation takes effect immediately.
• Each connected account is visible in your workspace, with what it can do.
• Integrations are enabled per environment, so an entire category can be switched off centrally.

• Approval gates in workflows. Any step in an automated workflow can be configured to pause. It surfaces as a pending gate that a person approves, rejects or revises before the run continues.
• Command execution is governed by its own approval configuration, set to full security mode on every instance.
• Adopt autonomy gradually. The intended path is review-before-act on day one, widening to unattended execution only where you have watched it work.

An AI agent reads untrusted content by design — the body of an email, the contents of a web page, a document someone sent you. Any such content can attempt to issue instructions. Orchestra’s containment model has five layers:

1. Least privilege (§5). An injected instruction cannot exceed the scopes the credential was granted. Read-only stays read-only, whatever the text says.
2. Execution-time allowlists (§5). A tool outside the connection’s allowlist does not run, regardless of what asked for it.
3. Approval gates (§6). High-impact steps stop for a person.
4. Tenant isolation (§2). The blast radius of any single instance ends at that instance.
5. Authority routes are portal-only (§2). An agent cannot widen its own permissions.

Our recommendation to you. Grant each agent the lowest access level that lets it do its job, and keep approval gates on any step that sends, publishes, pays or deletes.

• No sale of personal data. Ever, to anyone.
• No training. Neither your data nor your agents’ content is used to train Orchestra models, or anyone else’s on our instruction.
• No advertising trackers. The application sets no cross-site advertising cookies and builds no advertising profiles. The marketing website uses analytics that load only after you consent via the cookie banner.
• Conversation content is not centralised. Orchestra’s shared systems do not retain the content of your agents’ conversations. That working data stays on your dedicated EU instance, where your agents need it.
• Runtime transmission is inherent to the product. Delivering AI features requires sending content to model providers and to the tools you connect. Where Orchestra supplies the key, that provider is a sub-processor and is listed in §12. Where you supply your own key, the call is made under your own account and the provider’s own terms.

• Workspace activity log. Creations, deletions, invitations, role changes, member removals, renames and reconciliations are recorded with the actor — a person, or a named agent — the object, and a human-readable summary.
• Provisioning trace. Every deployment step for your instance is recorded, which is how support can answer “what happened at 14:32” without asking you to reproduce it.
• Operational visibility in-product. Recent agent errors, token and session usage, workflow run history and pending approval gates are all surfaced in the portal.
• In-house error tracking. Orchestra runs no third-party error or product-analytics SaaS in the application — no Sentry, PostHog, Segment or Datadog. Fewer places your data can be.

• Nightly snapshots. Your entire volume — configuration, workflows, files, databases — is archived nightly on a per-tenant schedule spread across the fleet.
• Databases are snapshotted safely. Live databases are captured with an online-backup API rather than copied raw, so a snapshot taken mid-write is still consistent.
• Pre-upgrade gate. Before any deliberate redeploy or platform upgrade, a snapshot is taken first. Migrations are forward-only, so a restore point is a hard requirement, not a convenience.
• Retention. Seven daily, four weekly, six pre-upgrade and three manual snapshots per tenant.
• Restore is proven, not theoretical. A full restore to a fresh service was drilled and verified: about fifteen minutes to a byte-faithful replica, with sessions, workflows, files, databases and configuration all intact. A restored instance adopts its new identity automatically and cannot write into the original tenant’s snapshot history.

On deletion, Orchestra runs an ordered teardown: billing is stopped, provider keys are revoked, network routes are removed, the container and its volume are destroyed, stored credentials are deleted, and the account record is removed. Deletion completes within 30 days, subject to legal retention obligations.

Your rights — access, rectification, erasure, restriction, portability, objection and withdrawal of consent — are exercised at legal@hiorchestra.com, answered within 30 days. You may also lodge a complaint with your national data protection authority; in Spain, the Agencia Española de Protección de Datos.

We publish two lists, because the distinction matters legally and operationally.

Platform sub-processors — Orchestra supplies the credential

Customer-connected integrations — activated by you, with your own account

Change notice. Customers with a DPA in place receive at least 30 days’ notice before a sub-processor is added or replaced, with the opportunity to object. Subscribe to change notices →

Transfer safeguards

Stored data does not leave the EU. Processing transfers occur when AI inference, or a tool you connected, is provided from outside the EU. For those, Orchestra relies on the European Commission’s Standard Contractual Clauses, the EU–US Data Privacy Framework where the sub-processor is certified, adequacy decisions where they apply, and each sub-processor’s Data Processing Agreement.

EU-only configuration

For customers whose policy is that no personal data is processed outside the EU, Orchestra can provide a restricted configuration: inference routed to EU-based model providers, non-EU transcription and speech services disabled, and connected integrations limited to those compatible with your requirements. This is an enterprise configuration and is scoped per customer — the default platform configuration does use US AI providers.

What we have

• EU data residency for all stored data (§1).
• A Data Processing Agreement offered under GDPR Article 28, available signed for enterprise.
• Documented lawful bases, data subject rights and retention periods.
• A 72-hour breach notification commitment (§15).
• A published sub-processor list with 30-day change notice (§12).
• An EU-only processing configuration for customers who need it (§13).
• Audit rights: we make available the information needed to demonstrate Article 28 compliance, and contribute to audits on reasonable notice.

Contracting entity and law. Orchestra is operated by AGENTIC DYNAMICS LLC. Our terms and DPA are governed by Spanish law, with jurisdiction in Barcelona. For EU users, mandatory GDPR and national provisions take precedence where they conflict.

• Notification to customers and, where required, the competent supervisory authority, without undue delay and within 72 hours, per GDPR Article 33.
• Under the DPA, Orchestra notifies the customer as controller with enough detail to meet their own Article 33 and 34 obligations.
• Contact. security@hiorchestra.com for security incidents, legal@hiorchestra.com for data protection matters.

• We welcome responsible disclosure and will validate and remediate legitimate issues promptly.
• Please give us a reasonable opportunity to fix an issue before disclosing it publicly.
• Please do not access, modify or exfiltrate other customers’ data while testing, and do not run denial-of-service or spam tests against production.
• There is no paid bounty programme today. We do credit reporters who ask to be credited.

• Independent, backwards-compatible deploys. The portal, the API and the agent image deploy separately. Instance changes are rolled through a staging environment before reaching customer instances.
• Versioned instance migrations. Every change to a tenant’s environment runs as a recorded, one-time migration, so what happened to your instance is reconstructible.
• Least-privilege secret handling. Provider keys are injected into an instance at boot and are never written to the platform’s environment variables or returned to a browser.
• Dependency hygiene. Automated dependency vulnerability alerts on the application repositories.
• Confidentiality. Personnel with access to production are bound by confidentiality obligations, and access is limited to those who need it to operate the service.

Published so you can plan against it, not as a commitment to dates.

Where is our data stored?

European Union, Amsterdam. Application, API, database, your agent instance and its disk. No external database or object storage.

Is our data used to train models?

No — not ours, and not anyone’s on our instruction.

Is the platform multi-tenant?

The control plane is; the runtime is not. Your agents run in a dedicated container with a dedicated volume.

What stops an agent from deleting our data?

The credential it holds was never granted delete permission unless you granted it, the provider enforces that, and Orchestra independently blocks any tool outside the connection’s allowlist at execution time.

How are credentials protected?

AES-256-GCM at the application layer before storage, TLS in transit, never returned to the browser, and never stored as environment variables on your container.

Who at Orchestra can see our data?

Agent working data lives on your instance, not in our shared systems. Access to production is limited to personnel who need it and is bound by confidentiality obligations.

Are you SOC 2 or ISO 27001 certified?

No. See §14 for exactly what we do and do not have.

Do you have an SLA?

Not on standard plans. Enterprise agreements can include one in writing.

Can we get a DPA?

Yes — available at /legal/dpa, countersigned on request.

Can you keep everything inside the EU, including inference?

Yes, as an enterprise EU-only configuration (§13).

How do we delete everything?

Request it. The instance, its volume and stored credentials are destroyed and the account removed within 30 days.

How do you handle prompt injection?

We contain it rather than claim immunity — see §7 for the five layers and our recommendation.