AGENTFLOW · SECURITY AND DEPLOYMENT

It runs where your policy says it has to.

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.

DEPLOYMENT

Four ways to deploy. One architecture.

Pick the one your policy allows. Compute, agents and models stay inside whichever boundary you choose, and you can bring your own model keys.

SAAS

Our cloud, private link

We run it, and it reaches your data over a private link rather than the public internet.

BYOC

Your cloud account

The cluster sits in your account and under your boundary. Compute, agents and models never leave it.

IN-VPC

In your VPC

Entirely inside your VPC, with your own model keys and no vendor egress.

SOVEREIGN

On-prem or air-gapped

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.

YOUR STORAGE

Everything it learns stays with you.

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.

IN YOUR OBJECT STORAGE
workflow specsskill librarycustom toolsproject memoryrun historyaudit log
ACCESS

It sees what the user is allowed to see.

Several layers, each independent of the others.

Sign-in

OIDC and SSO. Every request carries a user-level token, so the agent acts on behalf of a particular person.

Data

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.

Sources

Operational systems are registered read-only unless you say otherwise.

Answers

A check on the structured response can reject an answer before it is returned, if it contains fields you have disallowed.

Tools

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

Secrets are scoped. A step names a model by its registry id, never by a raw key.

Models

A step that touches sensitive data can be pinned to a model you host. Inside your VPC, with your own keys, nothing calls home.

APPROVALS

Nothing changes without a signature.

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.

  1. 01Plan

    The step works out what it intends to do, and to what.

  2. 02Freeze

    The plan is sealed with a fingerprint of its inputs. From here it cannot drift.

  3. 03Approve

    It goes to a named person in Slack, by email or in the product, with a timeout and an escalation path.

  4. 04Run

    Only on approval, and only the frozen plan. Decline and the run stops.

  5. 05Record

    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.

THE LEDGER

Three months later, you can still read the run.

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.

  1. 01
    Every step

    in the order it ran, with its outcome.

  2. 02
    The SQL

    each step executed, as it was executed.

  3. 03
    Every tool call

    and which tools the step was allowed to reach.

  4. 04
    Every gate

    passed or failed, and what it checked.

  5. 05
    Tokens and cost

    per step.

  6. 06
    Every approval

    who, when, and the fingerprint of what they approved.

COMPLIANCE

The paperwork.

Certifications

[NEED: certifications e6data holds today, with report dates. Leave out anything in progress, or say that it is.]

Testing

[NEED: penetration-test cadence and who performs it.]

Agreements

[NEED: link to the DPA and the list of subprocessors.]

Contact

[NEED: security contact address and where to request reports.]

Questions from security reviews

How do you stop it from touching data a user shouldn't see?

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.

Can it act on operational systems without a person watching?

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.

If something goes wrong three months from now, can we reconstruct what happened?

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.

Where does our intellectual property live?

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.

Do prompts or data leave our boundary to reach a model?

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.

TALK TO US

Send this page to your security team.

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 docs

An actual person replies, usually within one working day.