What an AI agent can change

If you are putting AI tooling into a customer's commerce system, someone will eventually ask: what can the agent change on its own? This page is the answer, so you can give it without guessing.

• Every person who can sign in to a tenant already holds a credential that changes its data. Their token reaches Integration Studio, over MCP or over its REST API: create, change, delete and run workflows, and manage the tenant's stored connection credentials and secrets. Nothing pauses to ask a human first, and nobody has to set it up — so this is available to the customer's own staff, not only to you.
• The other openly published surface only reads. The documentation server holds no credentials and reaches no tenant.
• Everything else is a credential you or the customer chose to hand out — an API key, a signed-in CLI session on a developer's machine, or whatever came with provisioned AI access.

This page describes surfaces and credentials rather than a configuration you can copy.

Two different things get called credentials here, and the difference is the whole point of the page. The agent's credential is the token or API key it authenticates with — that is what you issue, bound and take back. A connection credential is a secret the tenant has stored in Integration Studio so workflows can reach their ERP, shop, CRM or mail. An agent never sees a connection credential. It can still cause one to be used.

What an agent can reach

Each row is a credential an agent can hold and what that credential reaches — MCP servers, REST APIs and command-line tools alike, because the tool list is never the boundary; the credential is. Open below means anyone can point a client at it today, without revenexx setting anything up. Provisioned means it was arranged for a specific organisation.

Neither open MCP server takes a revenexx API key: the documentation server reads documentation, and the workflow server reaches Integration Studio. The one MCP route to the revenexx API, api-mcp, is provisioned rather than open. That is a narrow statement about the two open endpoints, not reassurance — see what a workflow reaches once it runs, below.

api-mcp is the revenexx API as four tools. Instead of one tool per operation it offers list-business-objects, list-endpoints, describe-endpoint and execute-endpoint: an agent discovers the domains in your tenant's API contract, the operations under one, an operation's schema, and then runs it. Only execute-endpoint writes, and a write policy on the server decides whether it may — read-only by default, so a read operation runs and a mutating one is refused until the policy is changed. That policy is set on the deployment, not on your tenant, so ask what it is set to for the access you were provisioned rather than assuming the default. Every call is relayed to the revenexx API with the credential the agent presented, and the API stays the authorization boundary: api-mcp changes how an agent finds an operation, not what the API lets that credential do.

Publishing an App capability also puts it in front of api-mcp. The same document that generates the SDKs and the API Explorer is what api-mcp reads: your summary is the line a model sees when it lists a business object's operations, and your request schema is what it gets back when it asks for the operation's description before executing it. See The published OpenAPI document. You do not connect that surface yourself — it is reached through provisioned AI access rather than a URL you configure. But if you publish a capability that writes, it is executable there whenever the write policy allows, so count your own app's write capabilities when you answer this question for a customer.

Provisioned AI access is arranged, not signed up for, and it is not only inference. A tenant can be given AI access for their own applications: model inference, and tool servers such as api-mcp that let an assistant work against the revenexx API. It is set up with revenexx per organisation rather than enabled from Cockpit, so an agent cannot acquire it by itself.

revenexx skills, the Skill Registry command, is deliberately not in that table, because it writes only to your machine — it replaces the target directory, so local edits there are lost — and does not itself reach a tenant. An agent with shell access can still run it, and a skill is instructions that land in the same context as your agent's tools: install from sources you trust, for the same reason as what the agent reads can be adversarial below.

The workflow MCP server: what it writes, and a token that reaches further

Unlike the documentation server, this endpoint has no per-client setup page of its own. It is an HTTP MCP endpoint at integrations.revenexx.com/mcp/workflows carrying the bearer token of a signed-in person, so the client configurations for the documentation server are the right shape with two headers added:

claude mcp add --transport http revenexx-workflows \
  https://integrations.revenexx.com/mcp/workflows \
  --header "Authorization: Bearer $REVENEXX_ID_TOKEN" \
  --header "X-Tenant-Id: $REVENEXX_TENANT_ID"

{
  "mcpServers": {
    "revenexx-workflows": {
      "url": "https://integrations.revenexx.com/mcp/workflows",
      "headers": {
        "Authorization": "Bearer ${REVENEXX_ID_TOKEN}",
        "X-Tenant-Id": "${REVENEXX_TENANT_ID}"
      }
    }
  }
}

Both headers are required, and both are easy to get wrong. The token is the sign-in token a person gets from ID — the same one your app sends to the rest of the platform, not a credential you create for this server. The tenant header is not the one the rest of these docs use: this endpoint reads X-Tenant-Id and wants the tenant's id, where the platform API reads X-Revenexx-Tenant and wants its slug. Treat that as a divergence to check rather than a settled convention. Leave the tenant header out and a token authorizing exactly one tenant still works, which is why this usually surfaces first on the separate identity you give the agent — the one whose membership covers more than one tenant. How you set a header is your client's business, so check its own documentation. The variable names are yours to choose, since nothing on the platform reads them. Keep the token in the environment rather than inline: a config file holding a live session token is the thing most likely to end up in a repository. The service behind the endpoint is documented in full. The Integration Studio API reference covers the same tenant, the same token and the same operations over plain HTTP.

Its write tools cover the whole lifecycle: creating, updating, deleting, laying out and activating a workflow; adding, replacing and deleting a trigger; and starting a run. Deleting a workflow takes more with it than the workflow: its revision history, every one of its runs, its triggers, the missed runs waiting to be replayed, and the state stored for that workflow alone — the sync cursors and correlation mappings listed under its reads below. No run log reconstructs those, and one tool call is all it takes.

One tool marked read-only is not really a read. resolve-node-config is marked read-only by the server, and it asks a node to resolve its options against the connection it points at — which makes the platform call the customer's ERP or CRM with the stored connection credential. It never sees the credential; it can still cause its use. Count it with the writes.

Its reads are wider than the name suggests. An assistant can read run results and the step-by-step execution record, including each step's inputs and outputs. A payload too large to sit in the record inline is not out of reach: it is resolved on the way out, so what bounds a read is how many pages the agent asks for. Reading those payloads is opt-in per call — but it is the agent's option, not a setting you hold. It can also read the tenant's connection credentials — identifier, type, name and status, never the secret; and stored state such as sync cursors and correlation mappings. For an order-sync workflow, those step payloads are orders and prices.

Read the current tool list off your own MCP client rather than off this page. Integration Studio's schemas are marked v0-draft, so the set changes; your client always shows what the server offers today. Watch changelog.revenexx.com for changes.

Most MCP clients let you allow or deny individual tools. Allow the reads you want rather than denying the writes, and leave resolve-node-config out of the allowed set. A deny list admits every tool added later — the day this server gains a new tool, a deny list written today silently permits it, and an allow list does not.

Tools are not the only read path, though. This server also publishes workflows, runs and triggers as MCP resources — a separate primitive, and a client that filters tools does not necessarily filter those. Check what yours does before you describe the allow list as covering the server.

Be clear about what that control is, because this is the only place on the page where it is worth saying: it lives in your client, not in the platform. A different client, or the same client reconfigured, gets the tools back. It is a convention you enforce, so write it into your own runbook and say so to the customer.

• It is self-service. Nobody provisions it. Anyone who can sign in to the tenant and open Integration Studio can drive this server — which means the customer's own staff can connect an assistant without asking you or us.
• There is no read-only mode. No setting turns the mutating tools off, and there are no per-ability roles inside Integration Studio: anyone who can open it for a tenant may read and write everything that tenant owns — workflows, credentials and secrets alike. No setting closes the server off for a specific tenant either: the endpoint authenticates the token, resolves the tenant, rate-limits and records the channel the call arrived on, and there is no gate beyond that.
• The agent's credential is the whole boundary, and it is a coarse one. What that token can reach in the tenant is what the agent can reach.

The token reaches further than the tools

The MCP server is a conversational front end to a REST API, and the token opens both. The Integration Studio API publishes many more operations than the server offers as tools, including writes the tool list has no equivalent for, and its surface is wider in two ways that matter:

• It manages connection credentials and tenant secrets. Creating, changing and deleting stored connection credentials, and creating, changing and deleting tenant secrets, are REST operations. The MCP server deliberately has no tool for any of that — the API does.
• It executes and replays. Testing a connection credential, running a single node, replaying a dead-lettered message, retrying and resuming a run are all endpoints. Running a single node is an author-time test, but it uses the real connection credential against the real system.

So an agent that can make plain HTTP calls — which is most coding agents — is not bounded by the tool list at all. An allow list bounds one client's conversation; it does not bound the credential. If the agent has the token and a way to make requests, assume the whole API.

The token, and how to take it back

This server takes a person's sign-in token, not a scoped API key. That has three consequences worth planning for.

The agent acts as whoever signed in. Its reach is that person's tenant membership, and inside a tenant there is nothing narrower. So give the agent its own sign-in identity, a member of only the tenants it needs, rather than borrowing a colleague's session.

The token is short-lived and refreshed. It behaves like any other session token — it expires, an OIDC client refreshes it, and calls fail with 401 when refresh stops working. See Sessions. An unattended agent needs a refresh strategy that survives expiry, and a cut-off agent keeps working until its current token runs out. That holds for a session token, which is what a person signing in gets; a long-lived machine token does not expire on its own, so confirm which of the two the agent's identity actually carries before you describe any of the timing below. Note also where that token comes to rest: in most setups it is a value in an MCP client's config file on a developer's machine.

Taking the credential back is an identity action, not a key revocation. There is no key list with an entry to remove. You end that identity's session and remove its access to the tenant, after which it can no longer refresh — see Sessions. An already-issued access token stays valid until it expires, so the token's remaining lifetime is the window in which a cut-off agent can still act — and that window has no end of its own if what it holds is a long-lived machine token. Plan for that window rather than assuming the cut is instant, and stop the agent's in-flight runs as well, because ending a session does not stop work already running.

Stopping a run, and what you can put back

A run an agent started is stoppable, but neither control lets the step that is running finish. Cancel interrupts it: the node is signalled to abort, is given a few seconds to clean up, and is then killed — and because the engine reconciles it afterwards, the call returns before the run stops reading as running. Terminate kills the run outright with no cleanup. Both are available in Cockpit and as API endpoints, so you can script containment rather than clicking it. See Runs.

Three limits to plan for before you rely on that.

• Stopping does not undo, and it can stop mid-write. Whatever the run already sent to a customer's ERP has been sent, and a step interrupted part-way can leave a half-written record at the other end. The run's per-step timeline records each step's input, which is what you reconcile against by hand.
• Deactivating or deleting the workflow does not stop a run already going — and set-workflow-active and create-trigger are tools the agent holds, so an agent that is still authenticated can undo those containment steps.
• Restore brings back more than the graph, and takes some things away. Integration Studio can restore an earlier revision, in Cockpit or over the API. It re-applies the graph and its variables, and it re-applies that revision's trigger set authoritatively — so a trigger that did not exist at that revision is removed, including one the customer's integration depends on. Execution mode is not restored; the current value stays. Only a change to the graph writes a revision, so a trigger-only edit leaves nothing to roll back to. And restoring is itself a save, so it produces a new revision rather than rewinding.

What the agent reads can be adversarial

An assistant connected to the workflow server reads run payloads — orders, customer records, imported catalogue rows, webhook bodies. Much of that content originated outside your customer's organisation: a shopper typed it, a supplier's feed supplied it, a third party posted it. In the same session, the same assistant holds tools that create and start workflows.

So text an attacker controls arrives in the same context as tools that can act. Nothing on this surface inspects tool arguments for that, and nothing asks a human before a write. Treat it as your problem to contain:

• Do not put read and write tools in one agent when the reads include third-party content. In practice that means two client profiles against the same server with different allow lists — a configuration split, not a boundary, with the caveat above.
• Do not let an agent's output configure the next call unreviewed — a credential id, a trigger target or a node's destination chosen from data it just read is chosen by whoever wrote that data.
• Assume the run history is hostile input, not a log. It is the richest source of attacker-supplied text this surface exposes.

Data residency and AI training

The second question after "what can it change" is "where does what it reads end up". Two answers come from the terms rather than from how a setup is wired — but read the scope of the first one carefully, because it is narrower than it looks.

The models revenexx runs are in the EU. The terms commit revenexx to operating only AI models hosted in EU data centres, and to not transmitting customer data to models processed outside the EU. That commitment can only change with advance notice and a special right of termination.

Anonymised data may be used for training, and there is an opt-out. The terms allow revenexx to use irreversibly anonymised customer data to train and improve its models. A customer can object at company level, and the objection takes effect across their whole platform use within thirty days. The terms name a Datennutzung für KI-Training ("data use for AI training") setting alongside the written route; treat the written objection as the one to use, because no such setting is in Cockpit today. It applies going forward: data already folded into a trained model cannot be pulled back out.

Raise the training opt-out with the customer yourself, before their security review finds it. Tell them anonymised training is on unless they object, that the objection is company-wide with no per-user or per-end-customer granularity, and that the objection is filed in writing rather than toggled in a screen.

Subprocessors, and how long prompts, completions and tool payloads are kept, are governed by the data-processing agreement rather than by the platform. Read the DPA for the customer in front of you; neither answer can be inferred from this page.

API key, SDK and CLI access

An agent becomes write-capable the moment you hand it a credential and a way to make requests: an API key and the API, an SDK, or the CLI, which is the same API with a friendlier front end. At that point it can do everything the key's scopes allow, immediately.

Two things about this path are easy to get wrong.

A signed-in CLI is a second credential, and it carries no scopes. The CLI authenticates with an API key or with a browser sign-in saved on the machine — see Authentication. An agent with shell access on a developer's machine inherits that saved session and everything the person behind it can do. Giving the agent a scoped key only bounds it if the key is actually the credential in use, so set it in the agent's environment and confirm which credential the CLI resolved.

The CLI's confirmation prompt is not there for an agent. Every delete command asks first and defaults to no — but the prompt appears only when both stdin and stdout are terminals, and --force skips it. An agent is neither of those things, so the command runs silently: a delete with no --force from a non-interactive caller proceeds rather than failing. Treat the CLI as having no confirmation on an agent's path, and do not use its absence of --force as a safety net. See Interactive use.

An SDK is the same API and the same key, with one behaviour worth knowing: the SDKs do not retry for you. A 429 surfaces to your code, so an agent that loops without honouring Retry-After keeps calling a limit it has already hit. The CLI does retry — 429, 502, 503 and 504, honouring Retry-After — but only for methods that are safe to replay: GET, HEAD, PUT, DELETE and OPTIONS. POST and PATCH are deliberately excluded, so an agent's writes are exactly the calls that come back unretried.

What is enforced, and what is not

Both does not exist rows describe the open surfaces. What a provisioned setup includes is arranged with revenexx, so establish that for the tenant in front of you rather than reading it off this table.

Rate limits exist, but do not present them to a customer as a brake on an agent, and check which limit you are quoting. The published API limit is per tenant and shared across every key and user, so it is fast enough for an agent to do a great deal of damage inside it — and a looping agent slows the customer's production integrations while it does. The workflow server and Integration Studio's API are limited per identity instead, so the separate sign-in identity recommended above also gets its own separate quota rather than competing with production traffic.

There is no spend ceiling you can set on an agent, and nothing on the platform stops a runaway loop for you. Put a call budget and a kill switch in your own runner, and do not promise a customer a ceiling the platform does not enforce.

Where approval exists, and where it does not

There is no setting that makes an agent ask before each change. But approval machinery does exist, and some of it is the platform's, so do not tell a customer that nothing anywhere asks.

• Your MCP client's per-call prompt. Most assistants ask the person at the keyboard before invoking a tool. Today that is the only thing on an agent's path that asks a human at all. Like the tool allow list, it is the client's, with the consequences that follow: an "always allow" choice retires it silently, and an unattended agent has nobody to ask. Put it in your runbook as a convention, and never describe it to a customer as a guarantee.
• A permission lane for orders. Placing an order accepts two different permissions: one places it, the other creates it pending approval instead. Which lane a call takes follows the person the call acts for. Both lanes are the same route, so a key cannot be issued for one and not the other. See Orders.
• An order-value threshold. An order above the configured value is accepted as pending rather than placed, instead of being rejected. See Orders and Market settings for where it is configured.
• Consent before an app is installed. A merchant is shown an app's whole access register (what it may read, write and call out to) and installing is their decision. See Consent.
• Staging inside a workflow. The pricing-rules guide describes a workflow that stages proposed prices for someone to approve. It describes the pattern rather than walking you through it, and there is no approval node in the catalogue — you assemble it from two ordinary workflows, and it is your build.

Approval is a property of specific operations and permissions, not a mode you can switch on for everything. If your customer needs it across the board, you build it, and you describe it as your control.

One mechanism is worth naming precisely so nobody mistakes it for approval. An App capability can be gated on a permission that refuses a request naming no acting person, with a 403. That controls which people in a tenant may call an operation, and it is useful. It does not prove a human was present. The acting person is asserted by the caller and then resolved to a permission set inside the tenant, so it bounds which person's permissions apply — it does not evidence that the person did anything. Anyone holding the tenant's key can assert any contact in that tenant. See Person permissions, treat it as role enforcement, and never present it to a customer as a human-in-the-loop guarantee.

How to bound an agent

Start against a tenant with no production connections stored. Everything below is least privilege; this is the one control that makes a mistake survivable. Confirm your allow list actually blocks the write tools there, and rehearse the containment sequence, before you point an agent at a tenant whose credentials reach a live ERP. App development already works this way — see Testing. A customer without a non-production tenant needs one stood up before an agent is connected at all.

Give the agent its own API key, and grant it only the capabilities it reads. A call needing a scope the key lacks fails with 403, so the scope list is a real boundary rather than a convention. There is no read-only switch, though: scopes are named per capability, and a namespace-level grant includes the write operations in that namespace — a grant covering orders includes placing one. Enumerate instead. Your own tenant's contract is the authoritative list: GET /v1/openapi.json, or the API Explorer — take every GET operation's capability key, and treat anything with POST, PUT, PATCH or DELETE as a write. See Versioning and API keys. Note that a tenant's surface grows as apps are installed, so re-read it rather than granting a namespace once.

Set that key in the agent's environment, so it wins over any sign-in session saved on the same machine.

Give the agent its own sign-in identity for the workflow server, in only the tenants it needs. The API-key lever does not reach that server, and inside a tenant there is no narrower setting. Make it an account created for the agent rather than a colleague's own, signed in once, with the agent holding the refresh from there — the identity is the boundary, so keep its tenant membership as small as the work allows. That membership is the only part the platform enforces: which tenant inside it a call acts on is the header the agent sends, so treat every tenant in the membership as reachable from one conversation.

Allow only the read tools in your MCP client, resolve-node-config excluded, rather than denying the writes, if the agent should only read. Check that the client your customer standardised on can actually enforce it, over the server's MCP resources as well as its tools.

Do not reuse a CI key. A deploy key has write scopes because it needs them.

Give the documentation server nothing. https://revenexx.dev/mcp takes no credentials. If a setup asks you to configure one, that setup is wrong.

Keep the rest of your writes behind your own code, where the confirmation, the validation and the record-keeping can live somewhere you can point at during a review.

What an operator can reconstruct afterwards

There is no single platform-wide feed of everything an agent did, and none of the per-domain records reliably names the credential behind a change. Read them as records of what happened, and build attribution yourself.

• Workflow runs, revisions and an audit log. Integration Studio keeps runs, revisions and an append-only audit log covering credential, secret, workflow and trigger creates, edits and deletes, plus run start, finish and failure — with the actor and the moment. This is the strongest of the records here, because the actor is taken from the sign-in token rather than a field the caller fills in; because a change made over MCP also records the channel it arrived on and the name the client reported for itself, which is the one place on this page where a record separates an agent from a person at a keyboard; and because you can read it yourself: the Integration Studio API exposes the audit log as an endpoint, scoped to the caller's own organisation and tenant, so you can pull it on a schedule instead of opening a screen. Four limits: the actor is an opaque subject id, so you need your identity directory to turn it into a person, and rows the platform wrote itself carry no actor at all; that client name beside it is not the actor's equal — the client sends it about itself in the clientInfo of the MCP initialize handshake, so the caller chooses it, and it is a hint rather than attribution; rows are pruned on a retention window — a year by default, and not a contractual commitment — with no bulk export, so pull it before you need it; and delete-workflow is one of the agent's write tools, which destroys the workflow's revisions, all of its runs, its triggers, its missed runs and its own stored state, though the audit row recording the deletion survives.
• Order history. GET /v1/orders/{id}/events is described in the API as the audit trail, and no public endpoint updates or deletes those rows — a property of the API's shape, not a tamper-evidence guarantee, so do not present it as one. Its actor field is a plain string the platform does not promise resolves to an identity, and it can be null. Treat it as unverified attribution. It is also read per order, so you need the order ids before you can ask.
• Stock movements. GET /v1/inventories/movements is an append-only ledger — no update, no delete, a correction is another booking. It records what moved and why. It carries no actor field at all, so it will not tell you who or what caused a movement.
• Reads are not audited. Nothing records that an assistant listed a tenant's credentials, pulled a run's payloads or read stored state. Every record above is a record of a change. If a customer needs to know what an agent looked at, that is yours to log, at your client.
• Your own logs. Still the primary account of what your agent did with your credential.
• An App's own events and tables. If you are building an App, make its writes observable on purpose: emit an event per change, or keep an append-only table with read and create and no update. See Entity access.

Nothing correlates the whole set into one view, and nothing alerts you that an agent acted — these are records you go and read, not signals that arrive. If a customer needs to reconstruct agent actions end to end, or to be told when one acts, design that record yourself, and price it.

What to tell a customer's security review

Accurate as of 11 September 2026. This surface changes, so re-read the page before repeating any of this in a later quarter. These are stated as facts about the surface rather than as a script — put them in your own words when you take them to a customer.

1. Anyone with access to a tenant in Integration Studio can point an AI assistant at it today, with nothing provisioned and nobody asked. There is no separate edit permission and no per-ability roles, so this is not a role that can be trimmed — it is everyone with tenant access. The assistant can create, change, delete and run workflows over integrations.revenexx.com/mcp/workflows, which means it can act through every connection the tenant has stored: ERP, shop, CRM, mail. There is no read-only mode, no setting that closes the server off for a particular tenant, and it acts as whoever signed in. A customer needs a policy for what their own staff may connect, not only for what you connect for them.
2. The boundary is the person's token, not the tool list. An MCP client can be configured to allow only the read tools — the right way round, since a deny list admits every tool added later — but resolve-node-config belongs outside that allowed set: the server marks it read-only, and it still makes the platform call the customer's ERP or CRM with a stored connection credential. The setting itself lives in the client, not in the platform — and tools are not the only read path, since the server also publishes workflows, runs and triggers as MCP resources that a tool filter does not necessarily cover. The same token also opens Integration Studio's REST API, which creates, changes and deletes stored connection credentials and tenant secrets. A tool restriction is a practice somebody maintains, not a boundary anyone can rely on.
3. Containment is an identity task, not a key revocation. Cutting an assistant off means ending that identity's session and removing its tenant access, not deleting a key. Three consequences: an already-issued token stays valid until it expires — and a long-lived machine token does not expire on its own at all — so the cut is not instant; ending the session does not stop a run already going, so in-flight runs have to be stopped separately; and stopping a run does not undo it — whatever it already sent to a customer's ERP has been sent. An assistant that is still authenticated can also start another run.
4. Where we have provisioned AI access to an organisation, what came with it is arranged with revenexx and can include api-mcp, whose one writing tool is refused by default, and an app's own write capabilities — so the tool set and the write policy have to be established for that organisation rather than inferred.
5. Any further write capability comes from a credential somebody holds, and the two kinds are not equally bounded. An API key is limited to its scopes and to the one tenant it is issued for, and the platform enforces both — a call outside them is rejected. A saved sign-in session is not: it carries no scopes, reaches every tenant the person is a member of, and hands an agent with shell access everything that person can do. So running an agent read-only is an API-key answer only — enumerate each read capability rather than granting a namespace, because a namespace grant covering orders includes placing one — and for a session there is no read-only path at all. The CLI's confirmation prompt is no help here either: it appears only for an interactive caller, so destructive commands are not confirmed on an agent's path.
6. There is no blanket approval mode on the open surfaces. Approval exists on specific operations — an order can be routed to a pending state by permission or by value threshold — but those are buyer-side role controls, resolved from the person a storefront call acts for, so they cannot route a call made with an API key and no acting person. The only thing on an agent's path that asks a human today is the MCP client's own per-call prompt, and that is a client default rather than a platform control: an "always allow" retires it, and an unattended agent has nobody to ask. None of it proves a human saw a change. Anything broader is something you build, own and can point at.
7. An assistant that reads run payloads is reading text an attacker may have written. Orders, customer records, imported catalogue rows and webhook bodies arrive in the same context as tools that create and start workflows. Nothing on the platform inspects tool arguments for that, and nothing asks a human before a write. Containing it is your architecture: keep the reading agent separate from the writing one, and treat run history as hostile input rather than as a log.
8. Changes leave records in each domain, but they tell you what changed more reliably than who changed it. Integration Studio exposes an append-only audit log over an API, with an actor taken from the sign-in token, and it can be pulled on a schedule — though that actor is an opaque subject id you need your own identity directory to resolve, rows the platform wrote itself carry no actor at all, and the retention window is a default rather than a contractual commitment, with no bulk export. A change made over MCP also records the calling client's name, but the client reports that about itself, so read it as a hint rather than as attribution. Deleting a workflow destroys its runs, its triggers, its missed runs and its own stored state. Commerce records carry an actor the platform does not promise resolves to an identity, or none at all. Nothing joins them into one view, nothing alerts anyone, and reads are not recorded at all.
9. Rate limits are not a brake, and there is no spend ceiling. The published API limit is per tenant and shared across every key and user, so a looping agent can do a great deal of damage inside it — and slow the customer's production integrations while it does. Nothing on the platform stops a runaway loop. Put a call budget and a kill switch in your own runner, and do not promise a customer a ceiling the platform does not enforce.
10. The models we run are in the EU, per the terms — which cover our own models, not the model behind an assistant you or the customer connects, and not a workflow's own AI nodes, which call whichever provider the tenant stored a credential for. Those are yours to document, and worth confirming against the customer's own contract before you repeat the commitment. We may also train on irreversibly anonymised data unless a customer objects: a company-level opt-out, filed in writing, effective within thirty days, not retroactive, per the terms.

Related

• Integration Studio — what a workflow can do once it runs
• Runs — cancelling and terminating a run
• Revisions and audit — restoring a revision, and what a restore changes
• Sessions — the sign-in token the workflow server takes
• API keys — creating a scoped key, and what a 403 means
• Authentication — which credential the CLI resolves, and in what order
• Model Context Protocol — the documentation server and per-client setup
• AI Studio — its preview status, and the AI-adjacent things that work today