Low-code and no-code agent platforms like Dify let a user assemble a working LLM application — a prompt, a set of tools, a knowledge base, an agent loop with conditional logic — through a visual builder, and publish it without writing orchestration code. The visibility a security team gets out of the box is scoped to the workspaces they administer; seeing every app built across the organization, what credentials each one holds, and enforcing an authorization boundary between what a builder can wire together and what it should be allowed to do in production is a separate, org-wide capability that has to be deliberately configured or added.
The governance question here is different from a code-first framework. It is less about a specific coverage gap in a library's API and more about what happens when the barrier to creating an agent drops from "write and review code" to "drag a few nodes onto a canvas."
What a platform like Dify provides
Dify is representative of a category: a visual builder for LLM applications that combines prompt orchestration, a knowledge base for retrieval-augmented generation, tool integrations, and an agent mode that lets the assembled application decide, at runtime, which tools to invoke to answer a request. Applications are built by connecting nodes on a canvas — a prompt node, a knowledge retrieval node, a tool-call node, a conditional branch — rather than writing the equivalent logic in Python or TypeScript.
This is genuinely valuable for the problem it solves: it lets product managers, support leads, and other non-engineers build and iterate on an LLM-backed workflow without waiting on an engineering sprint. Published apps typically expose an API endpoint or a hosted chat interface that other systems or users can call.
The platform manages what happens inside the app's own logic — routing between nodes, calling the configured model, running the knowledge base retrieval. Extending a security team's existing agent inventory, identity system, or audit pipeline to cover every app built inside it, across every workspace, is a deliberate integration your team configures, not something workspace-level administration does automatically.
Where the governance gap sits
1. The population of agents can outgrow the review process
The core risk of a low-code builder is not any single feature — it is throughput. When building an agent no longer requires a pull request, a code review, or even an engineer, the number of live, tool-connected applications running inside an organization can grow far faster than a security team's ability to track them. An app assembled by a support lead over lunch, connected to a customer database tool and a knowledge base, can be published and generating traffic before anyone outside that person's team knows it exists. This is exactly the pattern described in the rise of shadow AI and why governance matters — low-code platforms do not create shadow AI, but they remove the friction that used to slow its growth.
2. Tool credentials are scattered across many small configurations
Connecting a tool or an external API inside a visual builder typically means pasting a credential into a form field on that specific app's configuration. Multiply this across dozens or hundreds of apps built by different teams, and you get a large number of dispersed places where a production API key, a database credential, or a third-party token lives — each one a candidate for being over-scoped, forgotten after the app is deprecated, or reused across apps that should have independent, revocable credentials. This is the same problem least privilege for AI agents addresses for hand-coded agents, at a larger scale and with less visibility, because there is no code repository to grep for hardcoded secrets.
3. Publishing an app is not the same as authorizing its access
A builder can wire a tool node to an app and publish it without a separate approval step confirming that the app should have access to that tool, that data source, or that spend budget. Unless the platform is configured with an approval workflow gating publication, or unless publication is followed by a review that checks the app's assembled configuration against policy, the assembly step and the authorization step collapse into the same click. This is where a low-code platform needs the same discipline described in how to classify AI agents by EU AI Act risk tier applied earlier: classify and review before an app goes live, not after it has been running for months.
4. Visual logic is still logic — and still needs a security review
A node-based canvas can express the same risky patterns as code: a tool with delete access wired to an untrusted input path, a knowledge base retrieval with no access filtering, an agent loop with no bound on iterations or spend. The visual format does not make these patterns safer; it makes them faster to build and, for someone used to reviewing pull requests, easier to miss, because the review surface is a canvas rather than a diff.
What good looks like
| Risk | Why it is specific to low-code platforms | Control to add |
|---|---|---|
| Agent sprawl | No code review gate before publishing | Register every published app in a central agent inventory |
| Scattered credentials | Secrets entered per-app in the builder UI | Centralize and scope credentials outside the builder where possible; audit what each app holds |
| Unreviewed authorization | Publishing and authorizing collapse into one action | Require an approval step before an app goes live, tied to its actual tool/data access |
| Invisible risk patterns | Visual canvas, not a diffable code review | Periodic review of published apps' tool and data connections against policy |
Treat every app built on a low-code agent platform as a first-class agent in your inventory — the same as one built with any code-first framework — and require the same identity, least-privilege scoping, and audit trail before it is allowed to hold real credentials or touch production data. The convenience of the builder is real; it does not exempt what it produces from governance. For the inventory and classification work this depends on, see building an AI agent inventory and the AI governance guide.
Common questions
Does self-hosting a low-code platform reduce the governance risk compared to a hosted version?
Self-hosting gives you control over infrastructure — where data and credentials are stored, who can reach the builder UI — but it does not reduce the underlying governance gap. The same population-growth risk, the same scattered per-app credentials, and the same missing review-before-publish step apply whether the platform runs on your own infrastructure or a vendor's. Self-hosting is an infrastructure-control decision, not a substitute for the agent inventory and review process the platform still needs layered on top of it.
Should non-engineers be prevented from publishing apps to production entirely?
Not necessarily — restricting who can build is a heavier-handed control than most organizations need, and it forfeits the platform's main benefit. A more proportionate control is separating "build and test" from "publish to production," with the latter gated behind a review step that checks the app's tool and data connections against policy, regardless of who authored it. This preserves the speed advantage for iteration while adding the checkpoint that matters for production risk.
How does this compare to shadow IT in general — is it really a new problem?
The underlying dynamic is the same one organizations have dealt with for other self-service tooling: when the barrier to creating something with real access drops, adoption outpaces the review process built for a higher-friction world. What is specific to low-code agent platforms is that the artifact being created holds live credentials and can take autonomous action, which raises the stakes of an unreviewed deployment considerably higher than an unreviewed spreadsheet or a personal automation script. A spreadsheet with a formula error produces a wrong number that someone eventually notices; a published agent with an over-broad tool connection can act on that error before anyone reviews the output, which is why the review gate matters more here than it did for earlier generations of self-service tooling, where the worst-case outcome of an unreviewed artifact was usually a bad decision made by a human reading it, not an autonomous action taken against a live system without anyone reading anything at all before it happened, which is a materially different failure to recover from after the fact than one a human could have caught before it shipped.