Our cloud, private link
We run it, and it reaches your data over a private link rather than the public internet.
In our cloud, in yours, inside your VPC, or with no connection to the outside at all. The architecture is the same in every case. Your data, your workflows and your audit trail stay in storage you control.
Pick the one your policy allows. Compute, agents and models stay inside whichever boundary you choose, and you can bring your own model keys.
We run it, and it reaches your data over a private link rather than the public internet.
The cluster sits in your account and under your boundary. Compute, agents and models never leave it.
Entirely inside your VPC, with your own model keys and no vendor egress.
Sovereign and non-hyperscaler clouds run the same architecture. It does not have to be a hyperscaler at all.
The runtime is a Kubernetes deployment. That cluster can sit on our side, on your side, or a combination of the two. The architecture does not change between them.
AgentFlow writes to object storage you own: S3, GCS, Azure Blob or MinIO. Everything there is versioned, so every change has a before and an after. None of it is held in our systems. If you stop using AgentFlow tomorrow, the record of what your team built and what it ran is still yours.
Several layers, each independent of the others.
OIDC and SSO. Every request carries a user-level token, so the agent acts on behalf of a particular person.
Policies scope each user to particular data through the semantic layer. The agent can work only with what that user could. Raw SQL and catalog browsing are not in the toolset, and a blocked tool reached another way is refused.
Operational systems are registered read-only unless you say otherwise.
A check on the structured response can reject an answer before it is returned, if it contains fields you have disallowed.
Each step can use only the tools it was given. You choose which tools an MCP server exposes and which hosts the runtime may reach. A server's token travels in the request to that server and never enters the model's context.
Secrets are scoped. A step names a model by its registry id, never by a raw key.
A step that touches sensitive data can be pinned to a model you host. Inside your VPC, with your own keys, nothing calls home.
When a step changes something in the real world, such as a hold in the MES or a write to the ERP, its life is fixed. The person approves exactly what will run, because the plan cannot change after they have seen it.
The step works out what it intends to do, and to what.
The plan is sealed with a fingerprint of its inputs. From here it cannot drift.
It goes to a named person in Slack, by email or in the product, with a timeout and an escalation path.
Only on approval, and only the frozen plan. Decline and the run stops.
An append-only entry: what ran, on what, and who said yes.
Run state is checkpointed along the way, so a run survives a restart and can wait days for a person without losing its place.
Every run is written to an immutable ledger that is part of the product, not a separate observability stack you have to buy and wire up. Look up a workflow and a run id, and this is what comes back.
in the order it ran, with its outcome.
each step executed, as it was executed.
and which tools the step was allowed to reach.
passed or failed, and what it checked.
per step.
who, when, and the fingerprint of what they approved.
[NEED: certifications e6data holds today, with report dates. Leave out anything in progress, or say that it is.]
[NEED: penetration-test cadence and who performs it.]
[NEED: link to the DPA and the list of subprocessors.]
[NEED: security contact address and where to request reports.]
Several independent layers. Sign-in at the product level. Then policies that scope a user to particular data through the semantic layer, so the agent can work only with what that user could. Operational sources are read-only unless you say otherwise. And a check on the structured response can reject an answer before it is returned if it contains fields you have disallowed.
Not on anything that matters. A step that changes something plans the change, freezes that plan with a fingerprint of its inputs, routes it for approval with timeouts and escalation, runs only on approval, and then writes an append-only record.
Yes. Look up the workflow and the run id and you get each step, the SQL it ran, the tools it called, the tokens and cost it spent, the outcome of every gate, and which person approved what.
In your own object storage. Workflow specs, the skill library, custom tools, project memory, run history and the audit log are all versioned there. None of it is held in our systems.
Only if you route them there. Models are chosen per step from a registry your admin controls. A step that touches sensitive data can be pinned to a model you host, and inside your VPC with your own keys, nothing calls home.
Then put them on the call. We will walk through the deployment shape that fits your policy, and everything it does and does not touch.
Read the docsAn actual person replies, usually within one working day.