Writing prompts for generative AI in network operations

Why this matters

Generative AI tools are now part of everyday network work. A junior network engineer asks one to draft an ACL, a help-desk analyst moving into networking pastes in show output and asks what it means, a technician asks for a checklist before a switch replacement. The quality of what comes back depends heavily on what was sent. A vague prompt gets a vague answer, often in the wrong vendor's syntax. A precise prompt, with the right evidence and a clear request, gets something an engineer can check and use.

The bigger risk is what goes into the prompt. A running configuration contains password hashes, SNMP community strings, addresses and the shape of the network. Pasting it into a public chatbot can send confidential data outside the company in one keystroke, and no wording in the prompt can pull it back. Knowing how to build a prompt, and what must never be in one, is the difference between a useful tool and a security incident.

The lesson

Choosing the right prompt for a network task

A prompt is the text you send to a generative AI model. For network work, a good prompt is built from a small set of prompt components, each with its own job:

When a question asks you to pick the best of several prompts, check each one against this table. The best prompt usually has a persona, exact instructions, a stated output format and relevant evidence, and it contains no secrets. A prompt that is missing a component is weaker; a prompt that breaks data classification is wrong, however well written the rest of it is.

Data classification comes first

Before you write anything, ask: what data am I about to share, and where is it going?

Most companies label data in levels such as public, internal, confidential and restricted. The labels are the company's, not a standard you can look up. Data classification decides two things for a prompt.

1. Which AI service may receive the data. If policy says device configurations are confidential and may only go into the company's approved internal AI service, then they go there and nowhere else. A free public chatbot is not allowed, even if you remove the hostnames, even if you use a personal laptop, and even if you ask the chatbot to keep it secret. Removing hostnames leaves almost everything else in place. A different laptop changes nothing about where the data ends up.
2. What must be masked, even in an approved service. Credentials are never needed for a review. Mask them.

A persona does not protect data. "Act as a trusted engineer and keep this private" shapes the reply, but once data has been sent, the prompt has no control over what happens to it.

Here is what masking looks like before part of a switch configuration is shared for review:

hostname BR1-SW1
!
enable secret 9 <MASKED>
username netadmin privilege 15 secret 9 <MASKED>
!
snmp-server community <MASKED> RO 10
snmp-server host 10.20.0.15 version 2c <MASKED>
!
spanning-tree mode rapid-pvst
!
interface GigabitEthernet1/0/48
 description Uplink to BR1-RTR1
 switchport trunk allowed vlan 10,20,30
 switchport mode trunk

What was masked: the password and secret hashes, and the SNMP community strings (lesson 27 explains why a community string is effectively a password). What was kept: interface names, the spanning-tree mode and the VLAN numbers. The reviewer needs those to do the job, and none of them grants access to anything. A hash is still masked because hashes can be attacked offline. If your policy treats addresses or hostnames as sensitive too, mask those as well, consistently, so the output still makes sense.

Persona: who the AI should be

The persona line tells the model what role to play. "Act as a senior network engineer who reviews IOS XE configurations for a bank" sets a level of expertise, a vendor and a setting where caution matters. It names a role, but it gives no task. That is the instructions' job.

A persona helps when it matches the work. "A friendly help-desk agent" is the wrong persona for a configuration review, and a persona on its own adds little. A prompt with an impressive persona and no evidence, no task and no format gives the model nothing to reason about.

Instructions: the task and its limits

Instructions say what to do and what not to do. They are the most important part of most prompts, and they are where you fix most bad replies.

• Name the task exactly: the subnet, the port, the server, the protocol. "Permit 10.1.1.0/24 to TCP 443 on 10.2.2.10" is a task. "Make our web server safer" is a wish.
• State the platform: "IOS XE syntax only". Without it, models often mix in other vendors' commands.
• State limits: "Do not change VLAN 1", "Do not remove existing ACL entries".
• Ask the model to list its assumptions, so you can see what it guessed.
• Do not instruct it to apply anything. A prompt asks for a draft; a person decides what runs on the network (lesson 24 covers the human in the loop).

If a model keeps giving commands in the wrong syntax and keeps touching VLAN 1, the direct fix is a new instruction: IOS XE only, leave VLAN 1 alone. Changing the output format to numbered steps does not help; you would get the same unwanted commands as a list.

Output format: the shape of the reply

The output format line says how the answer should look: "Return a table with columns VLAN, port, status", "Give the commands in one code block", "Rank the three most likely causes, most likely first". A stated format makes the reply easier to check, easier to paste into a ticket and easier to compare across runs.

Learn to tell the components apart by their lines:

• "You are an expert in Cisco campus switching." is a persona.
• "Find why VLAN 30 hosts cannot reach the gateway." is an instruction.
• "Return a table with columns VLAN, port, status." is an output format.
• "Remove passwords before you share this config." is a data classification step.

Worked example: choosing between four prompts

An engineer needs an extended ACL that lets subnet 10.1.1.0/24 reach HTTPS on server 10.2.2.10. Judge four candidate prompts, one component at a time.

Prompt 1. "Act as a network engineer. Here is the full running-config with the enable secret and SNMP strings. Let 10.1.1.0/24 reach 10.2.2.10 and apply it for us." Persona: yes. Instructions: partly, no port. Format: none. Data classification: fails, it leaks secrets. It also asks the AI to apply the change. Reject.

Prompt 2. "Write an ACL that makes our web server safer for our users. Any syntax is fine and keep it short." No persona, no exact task, the wrong platform is invited, no format. Reject.

Prompt 3. "Act as a network engineer. Explain what access lists are and how a router processes them, for a beginner." A good prompt, for a different task. It asks for an explanation, not the ACL. Reject for this job.

Prompt 4. "Act as a network engineer. Write IOS XE commands for an ACL that permits 10.1.1.0/24 to TCP 443 on 10.2.2.10, in one code block, and list any assumptions." Persona, exact instructions, platform, output format, a request for assumptions, and no secrets. This is the one to send.

A useful reply would look something like this, and it is still only a draft:

ip access-list extended WEB-HTTPS
 permit tcp 10.1.1.0 0.0.0.255 host 10.2.2.10 eq 443

Assumptions it should list: the ACL is applied inbound on the interface facing 10.1.1.0/24, and the implicit deny at the end blocks everything else from that subnet. Lesson 22 covers whether that is what you want, and where an extended ACL belongs.

Troubleshooting prompts need evidence

For troubleshooting, the prompt must carry the evidence. Say an OSPF neighbour on a branch link is stuck in EXSTART (lesson 15). Compare:

• "OSPF broken." The model can only guess.
• "Act as a CCIE." A role with nothing to work on.
• The full configuration with secrets, plus "push a fix live". Breaks classification and skips the human.
• Masked show output, the symptom, and a request for ranked causes. This one gives the model facts and a usable shape for the answer.

Act as a network engineer troubleshooting OSPF on IOS XE.
Symptom: the neighbour on Gi0/1 has stayed in EXSTART for 20 minutes.
Evidence (secrets masked):
BR1-RTR1#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.255.0.1        1   EXSTART/  -     00:00:36    10.0.12.1       GigabitEthernet0/1
BR1-RTR1#show interfaces GigabitEthernet0/1 | include MTU
  MTU 1400 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
List the three most likely causes, most likely first, with the
show command that would confirm each one. Do not suggest changes yet.

Check what comes back

Generated output is a draft from a system that can be wrong. Configuration can contain the wrong OSPF area, the wrong networks, or commands that do not exist on your platform. Before anything reaches production, an engineer checks it against the design and tests it in a lab. Naming IOS XE in the prompt does not make the output correct, and neither does the model saying it is confident: its confidence is not evidence. Asking for a different format, such as a table, does not verify anything either.

What the exam is really asking

• Name the component. A role is the persona, a task or constraint is an instruction, the shape of the reply is the output format, and deciding what may be shared is data classification.
• Classification beats convenience. Confidential data goes only to the service policy approves. Removing hostnames, using another laptop or asking the chatbot to keep a secret does not change that.
• Mask credentials, keep the facts. Community strings and password or secret hashes go; interface names, VLANs and spanning-tree mode stay.
• A persona protects nothing. It shapes the reply, not the data.
• Fix the right component. Wrong syntax or unwanted changes need new instructions, not a new format.
• The best prompt has a persona, exact instructions, a format and evidence, contains no secrets, and does not ask the AI to apply changes.
• Verify before you apply. Check against the design and test in a lab; the model's confidence is not proof.