TL;DR
- What it is: A low-code or no-code AI agent is built by a business team using a drag-and-drop tool, and it still makes autonomous decisions with real accounts.
- Why it evades governance: Inventory and review processes trigger on a system being classified as an agent. A workflow assembled in an afternoon by an ops team rarely gets that label.
- What it looks like today: Reporting on shadow AI in financial institutions puts unsanctioned tools well ahead of sanctioned ones, concentrated in treasury, payments, and correspondent banking.
- What closes the gap: Classify systems by what they do, regardless of who built them or which tool they used.
- The honest caveat: The most-cited shadow AI figures come from AI-security vendors monitoring their own customers, without an independent audit behind them. Treat the scale as directional.
A low-code AI agent gets built the same way a spreadsheet macro used to. Someone in operations needs a task handled, finds a tool that lets them wire it up without writing code, and has it running by the end of the week. The agent reads a queue, makes a decision, and takes an action on a live account.
Nobody files a change request for that, because nobody thinks of it as a system. It looks like automation, the same category as a scheduled report or an email rule. The governance program built for engineering-owned models never gets a chance to say no, because it never gets asked.
This piece assumes low-code tools are useful, because they are. The question is what happens when an autonomous agent exists inside a regulated workflow and no one classified it as one.
A low-code agent still makes autonomous decisions. It skips the people who would normally review that.
A low-code or no-code AI agent is a system built through a visual, drag-and-drop interface, with no code involved, typically by a business analyst, an operations lead, or someone with the informal title “citizen developer.” The building tool is different. What the agent does is not.
Once connected to a queue, a case system, or a communications channel, a low-code agent can prioritize accounts, draft outreach, escalate a case, or close one out, the same class of decision an engineering-built agent makes. What matters for governance is whether a human reviewed the decision logic before it touched a live account, and whether that review is on record.
Engineering-owned agents usually clear that bar because they pass through a development pipeline with checkpoints built in: a ticket, a code review, a deployment approval. A low-code agent built inside a workflow tool skips all of that by design. The tool’s entire pitch is building without waiting for engineering.
Why your model inventory has no line for it
The short answer: Model inventories and AI governance programs are built to catch systems that get classified as models or agents at creation. A low-code workflow built by a business team is rarely labeled that way, so it never enters the process that would classify, review, or track it.
This is the exact failure mode a governance program built for engineering-owned systems is not designed to catch. The inventory process assumes someone flags a new system as a model or an agent at the point it’s built. Engineering teams are trained to do that, because it’s how their systems get funded, reviewed, and shipped. A business team assembling a workflow in a low-code tool has no equivalent trigger. They are solving a staffing problem, and building a model never enters the picture.
The Conference of State Bank Supervisors made this concrete on 16 September 2026, when it released a new AI Supervisory Framework for state examiners. One piece of that framework is an AI Use Case Risk Tiering Worksheet, a tool examiners can use to tier an institution’s AI use cases by risk. That worksheet only works on use cases the institution names. A low-code agent nobody classified as an AI use case doesn’t reach the worksheet, tiered or not.
At the federal level, SR 26-2 and OCC Bulletin 2026-13, which replaced SR 11-7 in April 2026, explicitly exclude generative and agentic AI from their scope, calling both “novel and rapidly evolving.” That leaves examiners without a fixed federal rulebook for agent oversight and puts more weight on what an institution can show about its own inventory. A business-built agent that was never inventoried in the first place is the weakest point in that story.
Put the two paths side by side and the gap looks like a structural feature of the process, present by design. An engineering-built agent moves through a ticket, a code review, a deployment approval, and lands in the model inventory with an owner attached. A business-built low-code agent moves from an idea to a live workflow directly, with no ticket, no review, and no inventory entry, because nothing in that path asks for one.
What shadow AI already looks like inside a regulated institution
The short answer: Reporting on AI use inside financial institutions found unsanctioned tools substantially outnumbering approved ones, concentrated in functions that touch regulated data directly, and used for tasks that normally require a documented, auditable process.
Forbes reported in May 2026 on shadow AI data collected by the AI-security firm Reco, finding that unsanctioned AI tools outnumber sanctioned ones by roughly four to one inside the financial institutions Reco monitors. A separate January 2026 survey by BlackFog found 49% of employees at the organizations it surveyed use AI tools their employer hasn’t approved, and 69% of C-suite executives at those organizations considered that acceptable.
The same Forbes reporting placed shadow AI activity heaviest in treasury operations, payments processing, and correspondent banking, the parts of a bank where an unlogged decision has the most direct financial and regulatory exposure. It cited use in drafting SAR narratives, structuring AML case notes, and generating risk scores, tasks that normally leave a paper trail specifically because a regulator will ask for one.
IBM’s 2025 data found breaches involving AI systems cost organizations $670,000 more on average than other breaches, and separately found that 97% of organizations reporting an AI-related security incident had no access controls on their AI tools at all. None of these figures describe low-code agents specifically. They describe the environment a low-code agent gets built into, one where a business team already has the tools, the motive, and, per this reporting, the tacit permission to build first and ask later.
Closing the gap starts with classifying agents by what they do
The short answer: The fix is to extend inventory and classification triggers to catch a system by its function, an autonomous agent acting on a live account, regardless of who built it, what tool they used, or whether it was ever called an “agent” internally.
An engineering review gate assumes an engineer is in the loop. A low-code environment removes that assumption entirely, so the classification trigger has to move earlier and get broader. The practical version of that is an agent action catalog: a list of what an agent is allowed to do, mapped to an approval threshold, that applies the same way whether the agent was built in a code repository or a drag-and-drop canvas.
iTuring’s Model Governance module handles the part of this that a policy document can’t enforce on its own: an immutable audit trail and maker-checker approval on every model and agent decision it governs, regardless of which team built the underlying logic. That closes the record-keeping gap once an agent is inside the governed environment. It doesn’t solve the classification gap on its own, the moment a business team decides whether to bring a new workflow into that environment at all.
That decision has to be a policy one before it’s a technical one. Three questions do most of the work: does this workflow act on a live account without a human approving each action, does it use data covered by an existing model risk or data governance policy, and would a regulator reasonably ask who approved it. A “yes” to any one of those puts a low-code workflow in the same review path as an engineering-built agent, no exceptions for how it was built.
Sources
- Conference of State Bank Supervisors AI Supervisory Framework, CSBS, 16 September 2026. https://www.csbs.org/csbs-artificial-intelligence-supervisory-framework
- SR 26-2, Board of Governors of the Federal Reserve System, 17 April 2026. https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm
- “Shadow AI Has Reached Financial Infrastructure. Compliance Hasn’t,” Dara Abasiita, Forbes, 6 May 2026. https://www.forbes.com/sites/daraabasiita/2026/05/06/shadow-ai-has-reached-financial-infrastructure-compliance-hasnt/ (citing data from Reco and a January 2026 BlackFog survey)
- IBM Cost of a Data Breach Report, IBM, 2025, as cited in the Forbes reporting above.
