Skip to main content

Command Palette

Search for a command to run...

Day 34: Why tool access is where AI becomes operational risk

Why giving AI tools means designing permissions, observability, rollback, and approval paths.

Updated
3 min readView as Markdown
Day 34: Why tool access is where AI becomes operational risk
V
I’m Vamsi, a builder focused on production AI systems. I write Production AI Field Notes to break down the architecture behind reliable LLM apps, RAG, agents, multi-agent workflows, evaluation, observability, safety, and governance. My goal is simple: help builders move beyond impressive AI demos and design systems that can be tested, operated, trusted, and improved in the real world.

A model without tools can be wrong. A model with tools can be wrong and send the email, update the record, issue the refund, or delete the rows.

That is the exact line where AI risk stops being reputational and becomes operational.

A tool call is a real operation, not a longer answer.

Once a system can search, write, update, purchase, message, or delete, permission design matters as much as prompt quality.

Treat the tool list like attack surface

Because that is what it is. Four rules that hold up:

  • Strict schemas. Typed parameters with validation, not free text handed to a powerful system. A tool that accepts an arbitrary query string is a tool whose behaviour you have not actually specified.
  • Narrow beats general. Five specific tools (get_order_status, issue_refund_under_50) are safer than one run_query. Narrow tools are easier to validate, easier to log, easier to reason about, and dramatically harder to misuse.
  • Read-only by default. Write access is granted deliberately, per tool, with a scope and a reason someone can recall in six months.
  • Every call logged with arguments, result, and the requesting context. When something goes wrong, the tool log is the investigation.

The blast-radius question

For each tool, ask: what is the worst outcome if this is called with the worst possible arguments, at the worst possible moment, by an agent that has been confidently misled?

Not "would the model do that": assume it might, because day 57 covers exactly how an attacker arranges for it to. The question is what currently prevents the damage, and the answer needs to be a system property rather than a hope about model behaviour.

If a tool's worst case is unacceptable, the fix is one of three things: narrow its scope, require human approval, or make it reversible. "The prompt tells it to be careful" is not on the list.

The audit nobody schedules

Here is the uncomfortable pattern: agent systems accumulate tools faster than anyone reviews them. Each addition is individually justified, added under deadline, and never revisited. Six months in, nobody on the team can enumerate what the agent can actually do.

Put a recurring review on the calendar. Print the tool list, and for each one confirm it is still needed, still correctly scoped, and still logged. It takes twenty minutes and it is the cheapest control in this entire series.

Closing thought

Tools turn answers into actions. That is the whole value, and the whole risk, and the two arrive together.

Day 34 of 60 Days of Production AI Systems.


Previous: Day 33: Why planning reduces wasted AI actions
Next: Day 35: Why agent memory is not one database

Day 34 of 60 · Agentic AI Foundations (chapter 6 of 10)

Agentic AI Foundations

Part 4 of 6

A practical foundation for agentic AI. This series explains why agents need outcomes, boundaries, stop conditions, loops, planning, tools, memory separation, and reflection that changes the next action.

Up next

Day 35: Why agent memory is not one database

Why useful agent memory has to be separated, scoped, and governed.