Everything an agent achieves outside of producing text, it achieves through a tool. A tool is simply a function the agent is allowed to call: look up a customer, query a database, read a file, create a record, draft an email, call an internal service.
This is the layer where agents stop being interesting and start being consequential, and it is the layer that most deserves the attention of whoever in your organisation signs off on production access.
The security framing that actually helps
Here is the reframe that makes the risk legible to people who have never worked with AI.
Granting a tool to an agent is granting production system access to a new integration, with two unusual properties: it decides for itself when to call things, and it occasionally does something surprising.
Everything your organisation already knows about integration security applies. Least privilege. Scoped credentials. Separate identities per system. Rate limits. Audit logging. Reversible operations wherever possible. None of this is AI-specific practice, and teams that have run production integrations before have the right instincts already — they simply need to be told that this is what they are looking at, rather than at a chatbot.
The two unusual properties add requirements on top. Because the agent chooses when to call, argument validation matters more than usual: a schema check before execution catches a large proportion of bad calls at zero cost. And because it occasionally surprises you, the blast radius of every tool should be bounded — an agent with delete permissions on a production database is a decision someone should have to make deliberately and defend.
Read, write, send
The most useful way to classify tools is by what happens when they go wrong.
Read tools — query a record, search documents, check a status — are recoverable. A bad read wastes tokens and possibly retrieves something the user should not see, which is why permissions still matter. But nothing in the world changed.
Write tools — create a record, update a field, add a comment, save a draft — change state, usually reversibly. A wrong write is an operational annoyance that someone can correct, provided you can find it, which is provided you logged it.
Send tools — email a client, submit a bid, post a payment, respond to a citizen, publish something — are irreversible and leave the building under your organisation's name. There is no undo.
The rule that follows is simple and worth being dogmatic about: agents get read tools freely, write tools with care, and send tools only through a human. Not because the model is unreliable in some general sense, but because the cost asymmetry is brutal. Ninety-nine good emails do not compensate for the one sent to the wrong client with the wrong number in it.
Where volume genuinely demands automated sending, the pattern that works is to make the agent's send a low-stakes one — an internal notification, a status update on a case, an acknowledgement — while anything carrying commercial or legal weight waits for approval.
Fewer tools, sharper descriptions
There is a counterintuitive finding that shows up consistently: agents get worse as they get more tools.
Given six tools with clear, distinct purposes, selection is reliable. Given twenty with overlapping descriptions — one that searches documents, another that searches the knowledge base, a third that searches attachments — the agent starts choosing plausibly and wrongly. The failure is not dramatic; it just quietly does the less useful thing.
The mitigations are unglamorous. Keep the toolset small and the descriptions sharply differentiated, describing when to use each and explicitly when not to. Scope the available tools to the task at hand rather than exposing everything at once. And where two tools do similar things, merge them, or remove one.
This is also an argument for building narrow agents rather than one general one. An agent that handles tender intake needs six tools. An agent that handles everything needs forty, and will be worse at tender intake than the narrow one.
What tools look like in practice
For a document and bid workflow: read the tender documents, query the compliance register, look up past submissions, check certificate expiry dates, create a checklist item, draft a clarification question, flag for review. Six reads and two writes, and no sends at all — the submission itself stays entirely human.
For an internal operations workflow: read an inbox, extract from an attachment, look up a client record, create or update that record, draft a reply, notify a person. Again, drafting rather than sending.
For a public-service workflow: classify a request, look up a service definition, check whether required details are present, create a case, assign it to a team, send an acknowledgement to the citizen. Here one send is automated — but only the acknowledgement, which is a low-consequence message with fixed content. The substantive response to the citizen still comes from a person.
The pattern across all three: many reads, a few constrained writes, and sends either absent or trivial.
Standard interfaces
A note on where this is heading. There is now a common protocol — the Model Context Protocol — for exposing tools to agents in a standard way, and the major platforms have adopted it. This is genuinely useful, because it means a tool you build for one agent framework works with others, and connectors for common systems increasingly exist off the shelf.
It changes nothing about the governance question. A standard connector to your document store still needs scoped credentials, still needs to respect the asking user's permissions, and still needs its calls logged. Ease of connection is not a substitute for a decision about what should be connected — and the ease is precisely what makes an explicit decision necessary, because it is now trivially simple for someone to wire an agent into a production system over a lunch break.
What can go wrong
Beyond wrong tool selection: tools that fail silently and return an empty result the agent interprets as "nothing found"; credentials shared across tools so that a compromise of one exposes all; agents given a person's full permissions rather than a scoped service identity, so the audit trail shows a human doing things they never did; and the absence of any budget ceiling, so a looping agent discovers an expensive API at three in the morning.
Every one of these is preventable with controls your organisation already knows how to apply.
How to start small
Give the agent one read tool. Prove the workflow end to end with a human doing everything else. Add the second read tool. Then add one write tool that produces something reversible — a draft, a flag, a comment — and watch what it does for a few weeks with every call logged and reviewed.
Grant a send tool only when you have evidence from that log, and only for the lowest-consequence message in the workflow. That evidence is what an evaluation suite gives you, which is the next article in this series.
How CloudNala can help
We design the tool layer the way we would design any production integration — scoped service identities per system, argument validation before execution, read-write-send classification with approval gates on the third category, per-tool logging, and budget ceilings enforced outside the agent. It is the least exciting part of an agent project and the part that determines whether it passes a security review.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za