Hi there!
Before today’s piece, here’s a practical way to explore the same production-safety questions hands-on.
In this four-hour workshop, Sif Baksh will guide you through building a RAG-powered NetOps assistant that answers from your own runbooks and device configurations, with guardrails around how those answers are produced and used.
You’ll leave with four completed labs and a workflow you can continue testing after the session.
Four hours. Four labs. For AI Network Engineer readers, use code LIMITED40 for 40% off all passes.
P.S. Sif’s book, Building AI Agents for Network Operations, covers the same architecture in greater depth. You can bundle it with the event pass at checkout or purchase it separately if the workshop date doesn’t work for you.
Now, back to the tool boundary.
You’re building the tool layer for a network agent. You already have a device inventory and an SSH library that works.
There’s an obvious shortcut sitting right there:
One function. Every command. Every vendor. Anything you haven’t anticipated yet.
You could ship it this afternoon.
Don’t.
A general-purpose tool means you don’t have to enumerate what the agent might need.
That is also what makes it dangerous.
The model composes the action, while your policy layer receives an arbitrary string at runtime and has to decide whether it is safe. Every new command and vendor behaviour expands the set of cases that layer must interpret correctly.
You end up building a command parser and treating it as a security boundary.
Narrow tools move that decision from runtime to design time.
That tool has one purpose. It accepts a known argument, returns a defined shape and cannot be persuaded to perform an unrelated operation.
The safety property is structural. It does not depend on the model remembering an instruction or your code correctly interpreting a new command string.
Sif Baksh draws this boundary clearly in Building AI Agents for Network Operations: prompts can guide behaviour, but code enforces policy.
A tool that cannot perform an unsafe action is stronger than a prompt asking the model not to perform one.
Your first tool set does not need to cover every operational possibility. It needs to cover a small number of useful, low-risk questions.
device_status(device) · Low risk
Allow authenticated users and approved devices.
interface_status(device) · Low risk
Allow and log every call.
bgp_summary(device) · Low risk
Allow and log every call.
show_command(device, command) · Medium risk
Accept commands only from a fixed allowlist.
run_command(device, command) · High risk
Replace with narrower tools.
Configuration-change tools · High risk
Require approval, a ticket reference, a diff, and a rollback plan.
Restart or clear-session tools · High risk
Keep out of scope for the first pilot.
show_command() is the compromise.
It is general enough to support several read-only checks, but the requested command must match an approved list. If it is not on that list, the tool refuses the request and records the decision.
This is different from checking whether an arbitrary command looks safe. The allowlist defines what is permitted before the agent runs.
More tools also mean more possible actions to evaluate, test and audit. Start with tools that map to real operational questions. Add another only when you can define its purpose, inputs, outputs and failure behaviour.
Once a tool exists, other components start depending on it: the agent, another client and eventually someone else’s workflow.
Treat it as an interface with a documented contract:
Two fields do disproportionate work:
blocked_when forces you to decide how the tool fails before you discover its behaviour during an incident.
owner puts a name against future decisions. If every tool belongs to everyone, nobody owns the boundary when it needs to change.
Once other components depend on the tool’s name, arguments or return shape, changing them becomes a compatibility decision, not a casual refactor.
Every invocation should leave a structured record, including blocked requests.
The decision block is the important part. It records not only what happened, but why the system permitted it.
Blocked calls are useful too. They show which capabilities users keep requesting. That gives you evidence for deciding whether to build a narrow version properly or keep the boundary closed.
Keep secrets and full tool payloads out of these records. Log enough to audit the action without creating another place for sensitive data to collect.
Start with three checks:
1. Inventory the tool surface
List every tool the agent can call. For each one, describe the worst thing it could do if called with the least helpful arguments the model could construct.
If the answer makes you uncomfortable, narrow or disable the tool.
2. Put tool access in configuration
This lets you enable capabilities for a limited pilot, keep write tools disabled until the approval path exists and reduce the agent’s scope without changing its prompt.
If the agent starts behaving unexpectedly at 4 p.m. on a Friday, how quickly can an operator who did not build it disable its tools?
If the answer involves finding a repository, editing a prompt and waiting for a deployment, the shutdown path is not ready.
The safest agent is not the one you expect to make good decisions every time.
It is the one whose tools make the dangerous decisions unavailable.
Further reading: This issue draws on Building AI Agents for Network Operations by Sif Baksh. Chapter 9 covers authentication, secrets, approval workflows, observability, staged rollout and the production go/no-go review. Appendix A includes tool-contract, runbook and readiness worksheets.
What’s next: Narrow tools define what an agent can do. The next production question is who can request an action, and who has the authority to approve it.
Cheers,
Sayali
Editor-in-Chief
Upcoming live workshops
The tool boundary is only half the production story. The next questions are what happens after an agent proposes a change and how access is governed. These two upcoming sessions approach those problems from different sides.
Aug 27th · Agentic AI for Infrastructure Engineering: From Chatbots to Operators
Ritesh Vajariya, founder & CEO - AI Guru, will show you how to build an infrastructure agent that reads pod events, correlates live metrics and proposes fixes—but executes them only after approval.
You’ll work through seven production-grade failure scenarios injected into your own local Kubernetes cluster, which you can keep and rerun after the session.
If your Docker and Kubernetes fundamentals need shoring up before you get there, The Ultimate Docker Container Book (4th edition) by Dr. Gabriel Schenker is the deepest single resource we carry on containers through orchestration, and its latest edition adds AI-driven DevOps patterns on top.
Aug 29th · Active Directory and Entra ID in a Modern Hybrid Architecture
Professor Robert McMillen breaks down how traditional Active Directory and Entra ID work together in real hybrid environments: domains and group policy on one side, cloud identity and SSO on the other, and Entra Connect bridging them. Built for IT pros moving into infrastructure or identity-focused roles.
Since the session is already an add-on to the Azure basics going in, Microsoft Azure Fundamentals Certification and Beyond (built around the January 2026 AZ-900 update) is worth having on hand beforehand, especially if you’re eyeing the certification alongside the hands-on identity work.
If you’re a regular reader, hit reply and tell me which content would be most useful for your team: hands-on agent patterns, security and guardrails, or practical tool reviews.
If this issue helped sharpen the conversation, please like it or leave a comment so more platform, cloud, security and infrastructure engineers can find it.
Thanks for reading The AI Network Engineer by Packt. Subscribe for free to receive future issues.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.