Agents Are Getting Easy to Build, Using Them Isn't

CTRL AI DEL is Dailoqa's weekly, no-nonsense look at what's actually happening with AI in financial services. This issue looks at agentic AI deployment, why building an agent is no longer the hard part, and what actually separates a safe rollout from an expensive mistake.

It has now become quick and simple to build an AI agent but it is still not easy to deploy one safely within a regulated business. When it comes to deploying agentic AI in the financial services sector it is necessary to have human approval during the training phase, to have clearly defined access limits, to have forensic-quality audit trails, to carry out a phased rollout, and to incorporate least-privilege security from the beginning rather than adding it in afterwards.

The Excel Lesson

People are now widely discussing how fast they were able to develop agent-based solutions using the latest large language models, and they are sharing their experiences about which platform performed best for each task. The chatter has moved on from ChatGPT's early days to what the latest model generation makes possible, and social media is full of one page guides on which platform suits which job, alongside people explaining how they built a working solution to a real work process in under half a day. It is feeding a familiar sense of FOMO in AI circles, again. And yet, it is genuinely good news that agentic know-how is being demystified and moving into the mainstream. This technology should be in as many hands as possible, so people can experiment with it, learn from it, and occasionally break something in the process.

But allow an old timer a moment to pull this back down to earth. This is not the first time a breakthrough has swept through the business world with this kind of energy. My mind goes back to the trading floor, to a simpler time, when we first got our hands on Excel. I mentioned this once to someone even older than me, who looked into the distance and mentioned VisiCalc and Lotus 1-2-3 before Excel even came up. I felt slightly better about my own place in the timeline after that.

To us, Excel was more than just a spreadsheet; it was truly liberating. There was no need to ask a programmer to take a week in order to carry out a simple analysis. You could create a model, run a scenario and have the answer in just a matter of minutes. It ended up being the standard tool placed on each desk.

It was also a potential disaster. The same ease which gave it so much power also made it hazardous. It only required an accidental mistyping of a formula and a careless save to corrupt the whole model. The next person to open it, or you yourself a week later, would then be using a defective tool without realizing it. The human involved was not the safety measure that people thought them to be. At that moment, the human was the source of the failure.

Why the Promise Still Needs Guardrails

Agentic AI now has a similar potential, combining various functions into a system that is much more unified and eliminating the unreliable human element in the process. The concept is that an AI model is able to carry out a complex workflow, process the data, and perform a task with a consistency that no individual could maintain over a long period. This leads to fewer accidental errors and more reliable automation. In theory, it sounds very much like an ideal scenario.

The situation is not very lenient. An agent that has been well constructed is only as useful as the business process it is inserted into, and it's in this area that most of the enthusiasm gradually fades. It has never been difficult to build the agent; it is only when integrating it into a business that is already subject to regulation, under constant supervision and, in some cases, dependent on habit that the difference appears between those who actually launch something and those who are still just playing around on weekends.

The industry data backs this up. A recent survey found that forty two percent of companies had abandoned most of their AI initiatives, more than double the share reported the year before, and the average organisation scrapped nearly half of its AI proofs of concept before they ever reached production². Building a working demo was rarely the obstacle. Getting that demo through a bank's existing controls and into a process people actually rely on was.

It wouldn't be valid grounds for slowing down merely out of caution; rather, it shows the need to be clear about where the actual work lies. The part involving the agent is the easy ninety percent, while turning a single piece of software into a reliable member of a regulated team is the difficult ten percent that decides whether or not any of this actually happens.

We have described this elsewhere in this series as a dial rather than a switch, and the same idea applies directly to deployment. A newly built agent handling a low-stakes, well-understood task can run with the dial turned up toward more autonomy fairly quickly. The same agent handling something closer to client money, regulatory reporting or credit decisions needs the dial turned down, with a person checking its work at defined points until the evidence says otherwise. The mistake most teams make is setting the dial once, at launch, and never revisiting it as the agent proves itself or, just as often, does not.

Six Rules for Deploying Safely

Start with a human checking the agent's work

Do not simply switch an agent on and hope for the best. There will not be one agent, and there will not be one type of agent either. Different processes will need different kinds of agent, almost the way a spreadsheet has different functions for different jobs. Treat a new agent the way you would treat a new employee. Let it propose actions and decisions, and require a person to sign off before anything happens. This is as much a training period as it is a risk control. The person learns how the agent reasons and where its information actually comes from. The agent, in effect, learns from the correction it receives. Trust gets built before anyone hands over full control.

Define the problem and the people before the technology

This point is worth repeating because it gets skipped so often. Do you genuinely understand the problem you are solving, and everything it touches. Are you certain you know what you are actually trying to fix. Are the people and functions connected to that problem properly involved, not just informed after the decision has already been made. They will have opinions once the system goes live, and it is far better to hear those opinions early than to absorb them as resistance later.

On a trading floor, everyone eventually learned who actually owned a given spreadsheet model, whose numbers people trusted, and whose required a second look before anyone traded on them. That same informal ownership map exists today around every process a firm is considering handing to an agent, it is just rarely written down. Skipping the step of surfacing it does not make the ownership questions disappear. It just means they surface later, usually at the worst possible moment, in the middle of a live incident rather than a planning meeting.

Set boundaries as carefully as you set ambition

The importance of an agentic system lies in its autonomy, but that freedom must have clear boundaries. After the problem has been defined and the appropriate people have been involved, the next issue to consider is what the agent is permitted to do, where it is allowed to act, and on what authority. How reliable is the underlying data and how easy is it to audit? Are there any systems that are completely off limits? You should approach this in the same way that you would train a very capable working dog, you want it to retrieve the ball, not to create a mess in your neighbour's garden. The rules should be set with great precision and at the same time allow the agent to identify exceptions that you hadn't yourself anticipated.

FIn a KYC or trade surveillance workflow, this usually means being explicit about which source systems an agent is allowed to read from, which fields it can write to, and which decisions still require a named human sign-off regardless of how confident the agent's output looks. A firm that has not answered these questions before launch will end up answering them during an audit instead, which is a considerably less comfortable place to work them out.

Log everything, without exception

When an Excel model broke, there was usually a rough trail back to the mistake. When an agent fails without proper logging, there is only a black box and a serious problem on your hands. The audit trail needs to be forensic, recording what action was taken, why, what data informed it, and which tools were used to carry it out. Security researchers increasingly treat this as non negotiable rather than best practice, recommending default deny tool access, short lived credentials, and a human step built into any action that cannot be undone⁴. When something eventually breaks, and something eventually will, that record is the only thing that tells you what actually happened.

Expand scope only after the agent has earned it

Nobody launches a rocket on its first flight with a full payload, and the same logic applies here. Start an agent on a task that is low risk and low impact. Let it prove itself. Only once it has demonstrated real reliability does it make sense to expand what it is trusted to do. Citigroup took exactly this approach with its AI wealth assistant, rolling it out to a limited client group first rather than the whole book at once, precisely because memory and context reliability at scale still needed to be proven in practice³. A crawl, walk, run approach costs time up front. It is considerably cheaper than the alternative.

Treat access control as a security problem, not an afterthought

An autonomous agent is a new entry point into a firm's systems, and it deserves to be treated as one of the more serious security risks in the building. Apply the principle of least privilege properly, giving an agent only the access a specific task genuinely requires, scoped to that task rather than standing permanently open. Microsoft's own security guidance now recommends a dedicated identity for every agent, task based roles scoped to specific resources, and a documented, named owner for each one, precisely because authentication alone only confirms who an agent is, not what it should actually be allowed to do¹. The upside of agentic AI is real. A single unscoped credential is enough to undo most of it.

Read back, all of this can look like a long list of reasons for caution. It is not meant as one. The point is not to move carefully for its own sake, it is to move competently, which is a considerably higher bar. The potential in agentic AI is genuine, and so was the potential in that first spreadsheet decades ago. The reason why Excel was safe enough to base a career on wasn't the tool itself but the discipline that developed around it, this included version control, sign-off procedures, and shared conventions regarding who was allowed to make changes to what. These conventions took a long time to be established on the trading floor, mostly being worked out the hard way, through each instance of a corrupted model. Agentic AI does not have to go through that same timeline; the lessons have already been learned. It too needs the same kind of discipline, but this time built in from the very beginning rather than being added on after a problem had already occurred. If that aspect is handled correctly, then all the other excitement is fully justified.

FAQ

Why is it easy to build an AI agent but hard to deploy one safely?

Building an agent is now largely a configuration exercise on top of an existing model. Deploying it safely means integrating it with legacy systems, compliance requirements and existing staff workflows, which takes considerably more time and judgement.

What does human-in-the-loop mean for AI agents?

It means a person reviews or approves an agent's proposed action before it takes effect, particularly during the early period when trust in the agent's judgement is still being established.

How do you define access boundaries for an autonomous AI agent?

By assigning to each agent a separate identity, a defined set of allowed tools, and short-lived credentials associated with the task in question, rather than providing it with access to the wider systems.

What should an AI agent audit trail actually log?

What action was taken, why it was taken, what data informed the decision, and which tools or systems the agent used to carry it out, in enough detail to reconstruct the decision later.

What is a phased rollout for AI agents, and why does it matter?

What this involves is beginning an agent with a simple and low-risk task, demonstrating its reliability, and then only after that expanding the range of its duties. This is important since failures discovered early on in a small-scale task are much cheaper to address than failures that are identified later when operations have reached a larger scale.

How do you secure an AI agent with least-privilege access?

By granting only the minimum amount of access that is required for a particular task, that is, setting the permissions for the task rather than for the operator, and then revoking or expiring the credentials when the task is finished.

What's the biggest risk of deploying agentic AI too quickly in a regulated business?

Losing the ability to explain what happened after something goes wrong. Without logging, scoped access and a phased rollout, a single failure can be both hard to trace and hard to contain.

6. Glossary

• Agentic AI Deployment, the process of integrating a working AI agent into a live, regulated business environment, as distinct from building or prototyping the agent itself.

• Human-in-the-Loop, an oversight model where a person reviews or approves an agent's proposed action before it is carried out.

• Least Privilege, a security principle under which an agent is granted only the minimum access required to complete a specific task, and nothing more.

• Audit Trail, a forensic-level record of what an AI agent did, why, using what data, and through which tools.

• Phased Rollout, a staged deployment approach that starts an agent on a low-risk task and expands its scope only after it proves reliable.

• Scoped API Access, access to a system or tool limited to a specific task or time window, rather than standing, general purpose credentials.

• Agent Sprawl, the accumulation of disconnected, inconsistently governed AI agents and tools across an organisation.

7. References

1. Microsoft Security Blog, Least Privilege for AI Agents, Identity, Access, and Tool Binding, July 2026. https://www.microsoft.com/en-us/security/blog/2026/07/16/least-privilege-for-ai-agents-identity-access-and-tool-binding/

2. Future Processing, From Pilot to Production, Why Banking AI Projects Get Stuck in PoC, 2026. https://www.future-processing.com/blog/banking-ai-projects-stuck-in-poc/

3. Cryptopolitan, AI Agents Are Stuck in Pilot Mode Because Banks Still Do Not Trust Them, May 2026. https://www.cryptopolitan.com/ai-agents-are-stuck-in-pilot-mode/

4. Iternal AI, AI Agent Security Checklist 2026, Agentic Risks and Controls.

   https://iternal.ai/ai-agent-security-checklist