AI in Automation
The AI drafts; a human and your code decide
One rule runs through every page in this domain: an AI (artificial intelligence) assistant proposes, and deterministic code plus a named engineer dispose. Across a network-automation workflow the large language model (LLM) does the fast, fallible first draft (writing an Ansible task, choosing a tool call, summarizing device state), while the decisions that actually reach a live device stay in your code and in a human review. The exam trap this model helps you dodge is mistaking output that is fluent, confident, and even executable for output that is correct, authoritative, or safe. Code that imports and runs can still push the wrong configuration, a model's stated confidence is not a correctness signal, and 'you are read-only' written in a prompt is guidance, not a control. When an answer choice trusts the model itself, it is usually the one to avoid.
The domain unfolds in five steps, from 'should we?' to 'is it correct?'
Read the five subtopics of this 20% domain as one path from adopting an assistant to signing off its work. First, adopt deliberately: AI-Assisted Code: Benefits and Risks weighs the productivity gain against the three costs the blueprint names, data privacy, intellectual-property (IP) ownership, and the duty to validate. Second, threat-model the system: AI Security Risks maps what can go wrong once an LLM drives device changes, using the OWASP (Open Worldwide Application Security Project) Top 10 for LLM Applications as the catalog of failure modes. Third, expose your network as tools: Building an MCP Server with FastMCP stands up the interface that offers network data and actions to an agent through the Model Context Protocol (MCP), a vendor-neutral standard, built here with the FastMCP Python framework. Fourth, build the agent: LLM Conversational Agents assembles the loop that consumes that server, where the model asks and your code acts, with guardrails enforced in code. Fifth, verify before shipping: Evaluating AI Recommendation Accuracy checks every recommendation against ground truth in Cisco Modeling Labs (CML) and with the pyATS test framework, behind a human sign-off, before it reaches production.
When two answers both work, keep the human and the code in control
When two options are each technically plausible, the exam rewards the one that keeps a human and deterministic code in charge of the model. Prefer least privilege over a cleverly worded system prompt, a code-enforced allow-list or approval gate over a trusted response, and validation against your source of truth over the model's own confidence. In practice that means scoping tools narrowly, gating any state-changing action behind human approval, bounding the agent's loop, and checking results against ground truth before anything ships. Three tells recur across the domain: encryption in transit is not privacy, two models agreeing is not proof, and 'it ran' is not 'it is correct.'
From 'should we?' to 'is it correct?': the domain's five steps
| Step | Question it answers | Control that keeps the AI in its lane | Drill into |
|---|---|---|---|
| Adopt | Should we use an AI assistant, and what does it cost? | Scrub secrets, honor data residency, license-scan and review every draft | AI-Assisted Code: Benefits and Risks |
| Threat-model | What can go wrong once an LLM drives device changes? | OWASP LLM Top 10; least privilege at each seam, not prompt wording | AI Security Risks |
| Expose tools | How does the agent reach network data and actions? | MCP primitives: a tool acts, a resource is read-only, scoped per server | Building an MCP Server with FastMCP |
| Build the agent | How does the model actually drive the automation? | Model asks, code acts; allow-lists and approval gates enforced in code | LLM Conversational Agents |
| Verify | Is the recommendation correct before it reaches production? | Check against ground truth in CML and pyATS; human sign-off first | Evaluating AI Recommendation Accuracy |