Trust Center
Security architecture, documented as built
How AI Context Orchestrator protects your credentials and your data: the encryption behind the Vault, a stateless execution model, zero retention of run content, and the guardrails around every run. Written for security and IT leaders; every statement describes the product as it is built today.
Last reviewed: October 9, 2026 · This page covers the application's architecture. Hosting location, TLS termination and backups depend on the deployment and are covered by the agreement for it.
Principles
- Vault encryption
- AES-256-GCM
- Every credential is encrypted at rest and bound to its organization.
- Execution
- Stateless
- Each run is compiled fresh from the AST; the server carries nothing over between runs.
- Run content on disk
- 0 bytes
- Tasks, answers and tool results are never written to the database.
- On every plan
- BYOK
- Live runs use your own Claude API key, under your Anthropic account.
- On tokens
- 0% markup
- We never bill tokens: with BYOK, Anthropic bills your key directly at its own prices.
Architecture and data flow
Your browser
Canvas
- You edit the workflow (the AST) here.
- Blueprint exports are built here, locally.
- Speech becomes text in the browser.
AST + task in; SSE events out (text, never secrets)
Our server
API + Vault
- Checks your role and your plan.
- Decrypts the credentials the run needs, in memory.
- Compiles one request per agent from the AST.
One request per agent, with your key
Anthropic API
Your key (BYOK)
- Runs the model under your Anthropic account.
- Data handling follows your agreement with Anthropic.
Tool calls with your stored token
Your tools
MCP servers
- Called through Anthropic's MCP connector.
- With the token you stored, per request.
Voice: the browser turns speech into text on the device or through its own speech service. Audio never reaches our server.
The browser is where workflows are designed and exported. The server holds the Vault and orchestrates runs, but it doesn't keep what runs produce. Model calls go to Anthropic with your key; tool calls go to the MCP servers you chose.
Vault: AES-256-GCM encryption
Every credential (API keys, tokens, database URLs) is encrypted on the server the moment it arrives, and no API ever returns it.
| Property | Implementation |
|---|---|
| Algorithm | AES-256-GCM, authenticated encryption: confidentiality and integrity in one step. |
| Master key | 256-bit key from the VAULT_MASTER_KEY environment variable. In production the Vault won't operate without it, so the key never sits next to the data. |
| Initialization vector | 96 bits, random, new for every secret and every rotation. |
| Integrity | 128-bit authentication tag: a single changed byte makes decryption fail instead of returning altered data. |
| Tenant binding | The organization id and the secret id are authenticated with the ciphertext: a row copied to another organization or secret doesn't decrypt. |
| Key version | Each row records the version of the master key that sealed it, the basis for rotating the master key. |
| Who sees plaintext | Only the server process, in memory, for the request that needs it (a run or a connection test). API responses carry metadata only: name, provider, dates. |
| Workflow files | Canvas nodes store an opaque reference (sec_…), never the value. Exported files use ${NAME} placeholders. |
Rotating a credential replaces its value under the same reference, so every workflow that uses it follows without edits. Deleting it removes the encrypted row.
Stateless AST execution
A workflow is a declarative document, the AST (abstract syntax tree), validated against a strict schema before anything runs.
- Compiled per run. Each Live run sends the AST and the task. The server validates it, compiles one Messages API request per agent and starts the run. The server reuses nothing from earlier runs on its own: no conversation history, no cached prompts. A partial re-run (Re-run from this node) replays answers that your browser kept from the last run and sends back, only for the steps that didn't change.
- One compiler for review and run. The Compiled prompt shown in the inspector is built by the same code that builds the request: what you review is what runs.
- Ephemeral run state. While a run executes, its events are held in server memory so a dropped connection resumes exactly where it stopped. They're discarded 15 minutes after the run ends and never touch the disk.
- Your workflow, your copy. The AST is saved in your account only as your workspace, so you can reopen it, and it goes when you delete the workspace.
- The Co-Pilot is stateless too. Its conversation lives in your browser (kept there for up to 7 days so a reload doesn't lose it, and removed on Start over, approval or sign-out); each step is sent whole, forwarded to Anthropic with your key, and not kept. What it designs is validated against the same AST schema and Canvas rules before it opens, and nothing runs until someone presses Run.
Zero retention of run content (BYOK)
The platform is designed to hold as little as possible. This is what is stored, and what never is:
| Data | Stored? | Where, and for how long |
|---|---|---|
| Run input, model answers, reasoning and tool results | No | Streamed to your browser; held only in server memory until 15 minutes after the run ends, for reconnection. Never written to the database. |
| Company Memory links | No | Where your organization has link fetching switched on, a Live run fetches each Reference's web link as it starts and sends the page's text with the step to Anthropic under your key. Only public https addresses are fetched; the text is held with the run in server memory (15 minutes) and never written to the database. |
| Your workflows (the AST, with the prompts you write) | Yes | In your account as workspaces you can open, export and delete; also in your browser's local storage. Deleting one also unpublishes its public app, if it has one, and removes the app's copy of it. A workflow exported as a package is cleaned on our server first (no credentials, private addresses, quoted words or private ids, and a Reference's text only if you include it) and isn't kept by us; a workflow imported from a package keeps only the package's id, version and fingerprint. |
| Packages shared inside your organization | Yes, inside your organization only | Where your organization has sharing switched on: a package you publish from a workflow (its name, summary and setup notes, and each version as a cleaned copy of the workflow: no credentials, private addresses, quoted words or private ids, and a Reference's text only if you include it), who published it and when. Only people in your organization see a published package; a draft only you; a withdrawn one only you and your admins. Each version stays as it was published. What happened with it is kept as codes, never text: imports, refusals, Pre-Flight's result after an import, "It worked" and problem reports (broken, unsafe, misleading or incompatible), kept 12 months. A successful run of an unchanged copy counts as evidence by its fingerprint, never its content. Your collections are visible to you only. Withdrawing hides a package and stops new copies; deleting a withdrawn one removes its versions and events. Copies people made stay their workflows. Nothing is shared with another organization. |
| Solutions shared with other organizations (the Community) | Only what an admin submits and our reviewers approve | Where your organization has the Community on: only when an organization's admin submits a published solution, ticking that they have the right to share it, and our reviewers approve it, other organizations can read its listed version (its name, summary, setup notes, what it needs, and a cleaned copy of the workflow: no credentials, connections, private addresses or private ids, and a Reference's text only if it was included) and use it as their own workflow, after accepting its terms. Our reviewers read a submitted version and the submitting organization's name. Your organization's name is shown only if your admin chooses so; a person's name never is. When someone uses it, everything they do stays in their organization; your admins see only numbers (copies made, "It worked", problems reported), never who. Withdrawing it, or deleting it, takes it out of the Community; copies already made stay theirs. |
| Your account (sign-in) | Yes | Your name and e-mail, whether Google or Microsoft confirmed the e-mail, which of them you sign in with (its account id), your organizations and roles (and, during the beta, that your organization is on the beta plan), and your sessions (when each ends and the browser's name). Not your password (we never see it), your profile picture, your IP address, or the access tokens Google or Microsoft issue: sign-in uses none. A session ends 7 days after it was last extended or when you sign out, and an ended session is deleted within the hour. When an admin invites someone: the invited e-mail, the role, who invited and when, and a fingerprint (hash) of the link, never the link itself; an invitation works for 7 days and is deleted 30 days after it's used, revoked or expired. |
| Computers connected through the Bridge | Yes, without your files | Where your organization uses the Bridge: each connected computer's name and system, the Bridge's version, a public key (the private key never leaves the computer), the names you gave the folders it allows (never their location on the computer), whether it's online, and who connected it. For each job sent to it: what kind, how it went and when, never its content; kept 12 months. A pairing code is kept only as a fingerprint (hash). The files on the computer never reach us. The Bridge only calls out, accepts only jobs our platform signed, and the computer's own settings decide what it allows: we can't widen them. When a workflow step runs on the computer, Claude Code works there, in the one folder chosen, read-only; only the step's answer comes back to the run (with anything that looks like a key or password hidden first), kept in memory for 15 minutes like any run's content and never stored. Its usage there is Claude Code's own estimate, on that computer's key. |
| Credentials | Yes, encrypted | In the Vault (AES-256-GCM) until you delete them. |
| Integration metadata | Yes | Tool, server URL, status, account label, last test result and, for a sign-in (OAuth), when its access token expires, so it can be renewed in time. The credential itself, and the token that renews it, are in the Vault. |
| Connected services' action lists | Yes | The actions each connected service reports when it's tested or refreshed: names, the vendor's own descriptions and its read / change hints. Also which capabilities are switched on, by whom and when. Kept until you disconnect the service. Never what a tool was asked or what it answered. When someone runs Test Capability, the values they type go to that service and its answer is shown on their screen only; neither is stored. |
| Usage metrics and run facts | Yes | Per run: mode, engine, status, token counts, time, error code and the agent where it failed, the workflow (title and id) and its project, who started it (id and name at the time) and whether it re-ran from a node. Each run also keeps a fingerprint (hash) of the workflow it ran, so Project health can tell whether a workflow was tested as it is now; it can't be turned back into the workflow. No prompt or answer text. Kept 12 months. |
| Server logs | Errors only | Unexpected failures are logged with their error message for diagnosis. Prompts and answers are not logged. |
| Copies of the database before an update | Yes, up to 30 days | Before an update changes how our database is organized, the server keeps a copy of the whole database on its own disk, so the update can be undone: the 3 most recent copies, none older than 30 days. They hold the same data as the rows above, credentials still encrypted. Something you delete can remain in a copy until that copy is removed. |
| Co-Pilot conversations and analyses | No | Held in your browser (up to 7 days; removed on Start over, after building or on sign-out); each step passes through our server to Anthropic with your key and isn't kept. A document you upload is read in your browser: only its text travels, inside that step. Only token counts go to the usage dashboard. In a Live step the proposal also sees the names of the capabilities your organization switched on (not the tools' details). Starting a project, it also sees which services are connected and which capabilities are on (names and states only), never another project, a Reference's content or a run's content. Nothing more is kept. |
| Co-Pilot design briefs | Yes | Your first message (up to 4,000 characters) and what a person approved: the proposal with the quotes of your text, what was left out on purpose and the work methods chosen. Kept with the workspace the Co-Pilot created (Briefing on the Canvas) until the workspace is deleted. |
| Source sentences on Canvas nodes | Yes | Up to 6 quotes of your own text (300 characters each) per node, saying why it exists (Process X-ray), kept with the workspace until it's deleted. Never sent in runs, never exported. |
| Co-Pilot Memory | Yes | Short facts your team chose to save (at most 50, 240 characters each; text that looks like a password or key is refused), until someone deletes them. Sent to Anthropic, with your key, only with Live Co-Pilot steps. Admins can turn it off or forget everything. |
| Asset Library | Yes | The prompts, notes and Sub-Agent configurations your organization saves, until someone deletes them. A Sub-Agent added to a workflow from it records which saved configuration it came from (its id only). |
| Shortcuts | Yes, the definition | A shortcut's name, who it's shared with, its owner and its versions: which Library items, Company Memory documents or Co-Pilot memory it points at (their ids, not their text), its rules and its budget. A test shows you the text it would bring in, once, and keeps only what it found: states, sizes and a fingerprint (hash) of each item's text, which can't be turned back into the text. When a run's task, an agent's instructions or a Reference uses a shortcut, the run brings that text in just before the step that needs it (or when the agent asks for it), as part of that step's input: in server memory, never stored. What each run used is kept with its facts: which shortcut and version, how it went and those fingerprints, never the text (12 months). Your favorite and recent shortcuts are kept in your browser. Kept until someone deletes the shortcut. |
| Voice audio | No | Never reaches our servers (see Voice below). |
| Payment details | No | Handled by Stripe; we keep only the customer and subscription ids and the subscription status. |
| Blueprint exports | No | Built in your browser and downloaded directly. When the workflow uses connected services, the export also asks the platform which actions are switched off, to write them as deny rules; nothing is sent elsewhere. |
| Partial re-run cache | No | The last run's answers, kept in your browser tab's memory to replay unchanged steps; gone when the tab reloads or closes. |
| Human approval decisions | The decision, not the task | Per approval step: approved, rejected, timed out or stopped, how long it waited, whether the task was edited and who decided. Kept 12 months. The task shown for approval (and any edit) is part of the run's content: streamed, never written to disk. |
| Public app submissions | No | A visitor's answers are sent to Anthropic under the creator's key to run the workflow, and not kept. Only the run's facts are recorded (outcome, token counts, the app and the workflow it came from, per-agent numbers). |
| Per-agent run facts | Yes | Per agent in each run: its name (from your workflow), engine, outcome, error code, tokens, time, calls and tool calls, and which shortcuts each step used (name, version, state, size). No content. Kept 12 months. |
| Tool calls and capability tests | Yes | Per call of a connected service's tool, in a run or a Test Capability: which service, tool and capability, whether it worked, and how long it took. Never what the tool was sent or what it answered. Kept 12 months. |
| Daily totals | Yes | Numbers per day for the organization and each workflow, project, agent and engine: runs, outcomes, tokens, estimated cost and time ranges, for trends. Kept 24 months. |
| Activity log | Yes | Who did what, and when: projects, workflows, connections and their capabilities, secrets (their names), approvals, stopped and resumed runs, public apps, shortcuts with their tests and their use in runs, plan and setting changes, and changes in a project's health (recorded by the system). Names and codes only, never content or credential values. Each entry is chained to the previous one by a hash, so an edited history shows. Kept 12 months; admins see every entry, everyone else sees their own. |
| Projects | Yes | Name, description, owner and whether it's archived, and which workflows it holds. Archived projects keep their workflows and history. Optionally, which of the organization's capabilities a project may use (who added each, and when), and its objective, expected outcome and how it's measured, in your own words. |
| Template videos | No | Embedded from YouTube (privacy-enhanced mode) or Loom only when you open a template that has one. |
BYOK on every plan. Every default plan runs Live on your organization's own Claude API key, so model usage happens under your Anthropic account and its terms. On these plans, no customer's traffic runs on a shared key. We don't charge for tokens and add no markup: plans are a flat subscription, and Anthropic bills the tokens to your key directly.
Execution security
Agents act only through the tools you give them. Our servers don't execute code written by you or by the model: Skills are tool contracts, and tools run on the MCP servers you connect, called through Anthropic's MCP connector.
- Circuit breaker. When one agent makes more tool calls in a minute than your plan allows, the run pauses until a person resumes or stops it; with no answer in 10 minutes, it stops.
- Hard limits. Delegation is capped at 4 levels deep and each agent at 40 model turns per run.
- Cancellation. Stopping a run aborts the in-flight API request; nothing more is billed after that.
- Rate limits. Per user: 10 run starts per minute, with separate budgets for credential writes and connection tests.
- Plan gates on the server. Monthly Live-run quotas and premium options are enforced by the API, not only by the interface.
- SSRF protection. Addresses people type (custom MCP servers, database hosts) are resolved and checked before our server connects to them; in production, private, loopback, link-local (including cloud metadata) and multicast ranges are refused.
- Human approval. A workflow can pause before a hand-off until a person approves, edits or rejects the task; with no answer in 10 minutes, the hand-off is rejected.
- Public apps. A published workflow runs for visitors on the creator's key, with per-visitor and per-app rate limits and a daily cap the creator sets. Connected systems are left out of public runs unless the creator allows them, and workflows with a human approval step can't be published.
- Work methods. A work method only changes the instructions an agent receives. Runs on the platform run no code: script methods fall back to structured steps. In the Claude Code export, scripts the AI writes run in your own environment, which asks before it runs commands; the export grants no permissions.
Access control and tenant isolation
- Sign-in. People sign in with Google or Microsoft (scopes
openid email profileonly); we never see a password. The session is a signed, httpOnly cookie checked on the server on every call; it lasts 7 days, is extended while you use the app, and signing out ends it on the server. Your organization, role and status are read from our database on every call, so a change applies at once. Joining an organization takes an e-mail address the provider confirms: a person joins through the beta list or through an invitation link an admin copies for one e-mail, which works only for that e-mail's account, for 7 days. Admins change roles, suspend and remove members; an organization always keeps one active admin. Development builds also have a demo sign-in for testing; production builds don't contain it. - Roles. Org admin, Builder and Viewer. Viewers read workflows but can't edit, export, run, test connections or touch credentials; billing is for admins only. Only an admin shares anything outside the organization (a public app) and, where the Production gate is on, moves a workflow into Production; there, a step that can change data in another system runs live only after a person approves.
- Checked on every call. Each API route checks the permission it needs on the server; the interface only mirrors it.
- Organization scoping. Every query for credentials, connections, workspaces, runs and usage is filtered by the caller's organization, taken from their verified session; a run and its event stream are visible only to the organization that started it.
- OAuth. Connections authorized with OAuth use a state parameter against CSRF, PKCE where the vendor supports it, and only return to pages of this app.
- Signed billing events. Subscription changes come only from Stripe webhooks with a verified signature; events older than the last one applied are ignored. The one exception is the beta plan: we give it to every organization in the beta, nothing is bought, and it's noted on the organization, not as a subscription.
Voice commands and privacy
- Speech is recognised by the browser (Web Speech API). Our servers never receive audio.
- Where the browser supports on-device recognition, the audio stays on the device; otherwise the browser sends it to its vendor's speech service (Google's, for Chrome). The command bar always shows which one is in use.
- The On this device only setting turns the fallback off entirely.
- Commands are interpreted in the browser by a deterministic grammar: no AI model, no server call. They act with the same permissions and guardrails as the mouse, and destructive commands ask for confirmation.
Shared responsibility
| The platform | Your organization |
|---|---|
| Encrypts every credential and never returns it to a browser | Issues least-privilege tokens and rotates them |
| Enforces roles and plan limits on the server | Assigns roles: Viewer for people who only read |
| Pauses runaway runs and caps delegation | Reviews the Compiled prompt and simulates before going Live |
| Keeps run content off the disk | Agrees retention for model traffic with Anthropic (BYOK) |
| Refuses private network targets in production | Secures the MCP servers it connects |
Whoever operates the deployment keeps VAULT_MASTER_KEY in a secret manager, apart from the database, and restricts access to the server environment: holding both the database and the master key is what it takes to decrypt credentials.
Questions from security teams
Do you train AI models on our data?
No. We don't train models. Live runs go to Anthropic under your own key and your agreement with Anthropic.
Can your staff read our credentials?
They're encrypted at rest and no API returns them. Decrypting takes both the database and the master key, which lives only in the server's environment; the deployment's operator controls who can reach that environment.
What happens to a run's content after it ends?
It stays in server memory for 15 minutes so a dropped connection can catch up, then it's discarded. It is never written to the database.
Can we delete our data?
Yes. Workspaces, credentials and connections can be deleted in the app at any time. Run facts and the activity log are kept for 12 months and daily totals for 24, then deleted automatically; subscription records are kept for billing. Something you delete can also remain for up to 30 days in a copy of the database taken before an update. To delete your whole organization, or to get a copy of its data, your organization's admin writes to support (the address is in the app's Help).
Does voice go through your servers?
No. The browser handles speech; the app only uses the recognised text, in the browser.
What does the Co-Pilot send to Anthropic?
The conversation with it, including the text of a document you upload (read in your browser: the file never reaches our server), and the Solutions Engineer's instructions, under your organization's key. Never credentials: a design only names the environment variables that will hold them. With the Co-Pilot Memory on, also the facts your team saved, the names of the systems you connected and the titles and summaries of your last five Co-Pilot designs. In Live steps, also the names and descriptions of up to 30 shortcuts you can use, never what they point at.
Does the platform write or run scripts for our work?
No. When you choose a work method that uses scripts, the platform writes instructions only. In the Claude Code export, the AI writes and runs scripts in your environment, which asks before running commands; runs on the platform run no code and work in structured steps instead.
Which third parties are in the data flow?
Anthropic (the model API, under your key), Google or Microsoft (sign-in: they tell us your name and e-mail), Stripe (payments), the MCP servers you connect and, for voice without on-device recognition, your browser's speech service. When you open a template that has an explainer video, YouTube (privacy-enhanced mode) or Loom serves it.
Do you charge for tokens or add a markup?
No. No plan has a per-token charge: with BYOK, Anthropic bills the tokens straight to your key at its prices, and our plans are a flat subscription.
Can a public app act on our systems?
Only if its creator allows it. By default, Skills and Connectors are left out of public runs, so a visitor's text can't make an agent use your connected systems.