No-Code AI Agent Builders Are Only Safe If the Builder Can't Do Damage

A visual builder for AI agents is an easy thing to demo and a hard thing to ship safely. Easy, because dragging steps onto a canvas and watching an agent take shape is genuinely satisfying. Hard, because the moment a non-engineer can compose an agent that files tickets, sends email and updates records, the ability to act on production systems belongs to whoever is holding the mouse — and the person building a flow is, by definition, running it before they know it works.

So the interesting question about a no-code AI agent builder is not how expressive the canvas is. It is what a half-finished flow can do to the outside world while someone is still building it. In SphereIQ's AI Factory, the answer is a set of properties that are invisible in a demo and decisive in production: the builder can read anything it is allowed to read, and it cannot change anything until a real run, past a real gate, on a deployment that is allowed to act.

What does a no-code AI agent builder actually build?

A flow is a graph of typed steps, and it can start in four ways — because a person asks a question, because a schedule comes round, because an event arrives from a connected app, or because a file is dropped in. That is a design decision worth pausing on. When every agent has to begin with someone typing, a scheduled digest and a webhook-triggered triage both end up modeled as a chat that nobody is having.

Between the start and the end sit the steps that do the work: retrieval over your permissioned knowledge, model calls, branches and loops, deterministic data reshaping, web and database lookups, document generation, and the actions that change something in another system. A library of ready-made agent templates means the blank canvas is rarely actually blank.

All of that is expressive. None of it is the point of this piece. The point is what happens the first time someone presses Run on a flow that is not finished.

Why should simulation be decided per step, not per run?

Most systems offer a "test mode" that is all-or-nothing — either the whole run is real or the whole run is fake. Fake is useless for testing retrieval, because the answer depends on the actual documents. Real is unacceptable for testing a write, because it sends the email.

Per-node simulation removes the dilemma. A step that only reads — retrieval, a database lookup, a model call — really runs, against your real data, so you see the true behavior. A step that changes something — sends, creates, updates, closes — is simulated, so you watch the flow decide to send the email and see exactly what it would have sent, without an email leaving the building.

That distinction is enforced where the work happens, not as a flag on the run. The engine walks the graph and, at each step, asks what kind of step it is; a read is performed, a write is described. You can build a flow that closes tickets and updates a CRM, run it end to end a dozen times while you get it right, and never touch a customer's helpdesk. When you promote it to run for real, every write still goes through the governed action lifecycle — keyed so it happens once, gated on approval by default, recorded afterwards. Simulation is how you build without consequences; governance is how you run with them. A serious platform needs both — the line between them is the same one described in AI agents that act vs. AI that answers.

Where does custom code run?

Some flows need a line of real code — to reshape an unusual payload, or to compute something the standard steps do not cover. Offering that is how a builder becomes powerful. Offering it safely is the whole problem, because a code step is arbitrary code written by whoever built the flow, running inside your infrastructure.

SphereIQ runs it in a sandbox with no way out:

• Sealed execution. Code runs as JavaScript in a WebAssembly engine inside a separate worker thread, with no filesystem, no network, no timers and no access to the host runtime.
• Data in, data out. Input arrives as JSON and a JSON value comes back — nothing else crosses the boundary.
• Independent limits. A memory cap on the engine, a second cap on the WebAssembly heap, and a wall-clock deadline that stops the worker from the outside if the code will not stop on its own. Each limit backs up the others.

Can a flow grant access its sources don't have?

The subtlest way a builder can leak is not by reading — retrieval already enforces permissions — but by writing knowledge back. A flow can save what it produced into the knowledge base for later questions, and that is exactly where a naive implementation opens a hole: it lets a flow create content readable by a wide audience out of documents that only a few people were allowed to see.

So a save is constrained by intersection. The knowledge a flow writes is granted to the target collection's readers intersected with the people who can already see every restricted source it drew on. If that intersection would let someone read something they could not read before, the save is refused, not silently widened. Permissions are written before the content, and a collection with no permissions is closed, not public.

Underneath all of this sits a deployment rule. Whether an instance may change anything at all is set by its environment. A builder running on a non-production deployment performs no external writes until someone explicitly enables them, and acts only as the accounts it is given. Every saved version of a flow is kept, so a change is reversible and a restore is itself recorded. It is the same principle behind running self-hosted in your own VPC: the safe default is the one that does nothing.

How to evaluate an agent builder

If you are assessing an agent-building platform, build a flow that does something destructive — closes a ticket, deletes a record — and run it before it is finished. Watch whether the destructive thing happens. Then ask where custom code runs and what stops it reaching the network, and what happens when a flow tries to save a restricted document to a widely shared collection.

The canvas sells the platform. What the canvas cannot do by accident is what makes it safe to give to your whole company.

Frequently asked questions