Before You Let AI Touch Your Network, Do These 7 Things
The Safety Checklist for AI in Networking
You’ve been getting better AI outputs. Maybe you’ve tightened up your prompts. Now you’re looking at an AI-generated config and thinking: do I actually push this?
Good instinct. Here’s how to act on it.
PLAN BEFORE YOU EXECUTE
If you use Ansible, you already do this. You run --check before you run the real thing. It shows you what would change without changing anything. You review. Then you commit.
AI coding tools have the same concept. Claude Code calls it plan mode. Cursor and Copilot have equivalents. The AI lays out what it wants to do, you look it over, and you say yes or no.
William Collins demonstrated this live during our workshop. He pasted a prompt into Claude Code. The tool checked his guardrails, showed the plan, and waited. He reviewed it, said go ahead, and only then did it execute. “I’m a human in the loop right now,” he said.
Eric put it simply: “Show me the configuration before you do anything else in plan mode. Once satisfied, then we turn around and enable agent mode.”
You wouldn’t run an untested playbook on prod. Same rule applies here.
SET RULES BEFORE THE CONVERSATION STARTS
This one’s less obvious, but worth knowing about. If you use Claude Code, Cursor, or Gemini CLI, you can drop a markdown file into your project that gives the AI standing instructions. CLAUDE.md for Claude Code. .cursor for Cursor. agents.md if you want something that works across tools.
Think of it as onboarding your AI the way you’d onboard a contractor. Here’s how we do things. Here’s what you’re not allowed to touch. Here are the standards.
Eric explained during the panel: your org-wide rules go in a global file (package management preferences, coding standards, security policies). Project-specific constraints go in a project-level file. William added that you can even go folder by folder. His advice: “Don’t build one gigantic monolithic file. Spider-web it out.”
What goes in them? Eric said the number one request from practitioners is rules that “decrease hallucination, decrease uncertainty, build reliability, and build trust.” Things like: reference this documentation, don’t improvise on syntax, follow our naming conventions.
TREAT YOUR API KEYS THE WAY YOU TREAT YOUR PASSWORDS
An attendee at our workshop asked: what’s the best practice for storing API keys so they’re not sitting in plain text .env files?
If you’ve used Ansible Vault, you know the principle already. You encrypt sensitive data (OSPF passwords, SNMP strings, credentials) so they never exist as plain text on disk. They get decrypted at runtime, used, and that’s it.
Same logic applies to your AI tooling. William’s setup: he keeps API keys in a 1Password vault. A script pulls them into environment variables at login. When he logs out, they’re wiped.
No keys on disk. No keys in code. No keys in commit history.
“The secrets managers are there,” he said. “The technology isn’t stopping any of us. It’s just getting organized and doing it.”
START BY READING, NOT WRITING
John Capobianco’s advice is probably the most practical thing anyone said across the entire event: don’t start by pushing config. Start by pulling data.
Have an AI agent run “show ip interface brief” and send you a Slack summary of what it sees. You’re not changing anything on the network. You’re just getting a faster view of data you already look at.
“That’s completely 100% safe,” John said. “And it saves us hours of human copy-paste.”
Start there. Build trust with read-only operations. Move to documentation and testing. Only go to configuration management once you’re confident in the tooling.
BUILD A SANDBOX
Before AI runs against production, give it a lab.
John recommended ContainerLab and Cisco CML for building virtual copies of your network. “You can make a pretty good digital twin,” he told us. “Where you run your AI agents, where you run your automation.”
Let the AI break things in there. That’s the whole point: find out how it fails where it doesn’t cost you anything.
PUT AN APPROVAL GATE ON ANYTHING THAT WRITES
John’s framework: let the AI do the reasoning, the research, the drafting. But before it pushes anything to a device, make it stop and wait. A ServiceNow ticket. A Slack message. Whatever your team uses.
“A human expert can review the code, review the config, review the agent’s proposal. And then we approve that.”
He calls it “the best of both worlds.” The AI handles the grunt work. You handle the judgment calls.
DON’T FORGET WHAT YOU ALREADY KNOW
This was William’s point during the panel, and honestly, it’s the most important one.
Version control. Pinning your dependency versions. Running proper tests. Doing code review. None of that goes away because you’re using AI now. If anything, it matters more.
“All those DevOps principles, all those automation principles, that stuff becomes more important than ever,” he said. “Because that helps you catch when maybe the AI missed something.”
Look, none of this is fancy. It’s the engineering discipline you already have, pointed at a new tool. Check mode before execution. Encrypted secrets. Code review. Testing. Approval gates. You know all of this.
The gap between “I use AI for side tasks” and “AI runs in my production workflow” isn’t a technology gap. It’s a process gap. And the process is stuff you’ve been doing for years.
Start with read-only. Set your rules. Build from there.