AI-Assisted Code: Benefits and Risks

Ask an assistant for "an Ansible task that sets the MTU on a list of interfaces" and a runnable draft comes back in seconds, already shaped like the cisco.ios collection^[1] you would have reached for. That speed is real, and it is the reason to use one. It is also the entire benefit, and knowing exactly where the benefit ends is what keeps AI-assisted automation safe.

One idea governs this whole page: an AI coding assistant is a drafting aid, not an authoritative source. It produces a first draft; a human, a test, and a review turn that draft into a change you can trust on a live network. Everything below is a consequence of that one line.

Where the speed comes from

The assistant earns its keep on work that is repetitive and well represented in public code:

• Boilerplate velocity. Drafting the shapes you write constantly, an Ansible task, a Python REST client against a controller, a Jinja2 template, so a common pattern that used to take real time to hand-write comes back as a draft almost immediately.
• API and SDK discovery. Explaining an unfamiliar SDK or API surface, for example the Catalyst Center Intent API^[2] payload shape or a RESTCONF^[3] request body, and explaining existing code you have inherited. This lowers the learning curve on a platform you have not used before.
• Pattern consistency. Prompted with your team's standards, it can scaffold the same error handling, retry logic, and logging across a codebase, which makes the result more maintainable than a dozen engineers each inventing their own.

Where it stops

None of that makes the output correct, private, or safe to commit, and the rest of this page is the three ways it can be none of those:

• Data egress is what your prompt sends out of the organization.
• Intellectual property is what licensed code comes in with a suggestion, and what proprietary code leaks out.
• Correctness is whether the generated code is even right.

Read the assistant as the fastest junior contributor you have ever had, and also the one whose work you would never merge unread. The velocity is worth having; the review is never optional, and the rest of this page is the review.

Pasting a running configuration into a cloud chatbot is a data transfer to a third party, full stop. The moment the prompt leaves your network it is in the provider's hands, and unless a contract says otherwise it may be logged, retained, and used to train future models (OWASP LLM02: Sensitive Information Disclosure^[4]). The common misread is that the HTTPS lock icon makes the exchange private: TLS^[5] encrypts the prompt in transit so nobody on the wire can read it, but it does nothing about what the server does with the prompt after it arrives. Encryption in transit is not confidentiality after arrival. The diagram traces exactly what crosses the boundary.

Secrets are the sharpest case

Whatever is in the code you paste goes with it. An API key, a device password, or an SNMP community string embedded in a script is disclosed to the provider the instant you send it, and you cannot un-send it. Scrub or externalize secrets before any code reaches an assistant: keep them out of the source entirely, in a vault or an environment variable, so there is nothing sensitive to leak in the first place. Ansible's own answer is Ansible Vault^[6], which encrypts variables at rest so a playbook references a secret without embedding its value; a repository secret-detection scan^[7] is the backstop that catches the key you missed before it reaches a prompt or a commit.

Residency and jurisdiction

Even scrubbed of secrets, a prompt can still break a rule. Sending it to a cloud LLM can move regulated data, customer records, anything bound by a data-residency requirement, out of the jurisdiction where it is permitted to live. If the provider processes prompts in another region, the transfer itself can be the violation, independent of whether anyone ever misuses the data.

The mitigation and its price

Where the model runs decides all of this, which is the axis the comparison table at the top of the page lays out. A self-hosted or on-premises model keeps every prompt and every line of code inside the organization, so egress, secret exposure, and residency stop being risks at all. The price is capability and upkeep: an in-house model is usually less capable than the frontier cloud service, and you own running, updating, and securing it. An enterprise no-train tier is the middle path, the cloud model's capability under a contractual promise of zero retention and no training, and it is only ever as strong as that contract. Match the tier to the sensitivity of what the prompt carries.

Treat an AI suggestion as third-party code, not first-party code, and most of the intellectual-property risk takes care of itself. The risk runs in two directions, and the diagram shows both: licensed code can flow in with a suggestion, and your proprietary code can leak out through the model.

Inbound: licensed code you did not write

A model trained on public repositories can reproduce code that closely resembles its training data, including code under a copyleft license such as the GPL (GNU General Public License). Merge that into a proprietary product unnoticed and you have imported a licensing obligation you never agreed to, the same class of supply-chain exposure OWASP calls out for AI systems (OWASP LLM03: Supply Chain^[8]). The mitigation is exactly what you already do for any dependency: license-scan and review AI-suggested code before it merges, rather than trusting it as first-party work. A merge-request approval^[9] gate is the natural place to require it.

The ownership question is unsettled

There is a second, quieter inbound problem: the copyright status of purely AI-generated code is legally unsettled, and jurisdictions differ on whether output with no human author can be owned at all. You cannot resolve that debate on a code review, but you must have a policy on it, whether AI-generated code may be committed and how it is marked, so the question is answered once by the organization rather than case by case by whoever accepted a suggestion.

Outbound: your code leaving through the prompt

The same channel runs the other way. Feeding proprietary code into an external model to train or fine-tune it can leak that intellectual property into other tenants' outputs later, because the model has learned from it. This is the inverse of the inbound case, and it is why a no-train contract, introduced in the data-egress section above, matters for intellectual property and not only for privacy: it is the promise that your submissions are not folded back into the shared model. Where there is no such promise, proprietary code simply does not go to an external training endpoint.

Code that imports and runs is not code that is correct. An assistant's output can execute cleanly and still call the wrong device semantics, invent an attribute that does not exist, or quietly disable a protection, so "it ran in a test import" is never evidence that a change is safe. There are three failure modes to catch, and one rule catches all of them: validate every suggestion against current, authoritative documentation.

Hallucinated APIs, modules, and paths

An LLM generates the statistically likely next token, not a verified fact, so it confidently produces plausible-looking things that do not exist: an SDK method with a sensible name that was never implemented, an Ansible module that is not in the collection, a RESTCONF^[3] path or YANG^[10] leaf that no device actually models. Trusting that output without checking is exactly why overreliance is itself a named risk (OWASP LLM09: Misinformation^[11]). The check is to confirm every call against the real module^[1] or platform API^[2] reference, and for model-driven interfaces against the device's advertised YANG model, rather than against the model's confidence.

Insecure defaults

Assistants frequently reach for whatever makes the example "just work," which is often the insecure choice: disabling TLS certificate verification so a request stops complaining, hardcoding a credential inline, or granting a role far broader permissions than the task needs. Disabled certificate verification is the classic one. Setting verify=False in the Python requests^[5] library turns off the check that the device on the other end is who it claims to be, which re-opens the man-in-the-middle exposure that TLS exists to close. Because the model's output should be treated as untrusted input, these defaults have to be caught in review, never assumed away (OWASP LLM05: Improper Output Handling^[12]).

Stale knowledge from the training cutoff

A model knows nothing after its training cutoff, so it will happily suggest a module or API that has since been deprecated or removed: an Ansible module dropped from a newer collection, an endpoint retired in a platform release. The suggestion looks current and is not. Verify the currency of anything version-sensitive against today's documentation, not against the model's frozen snapshot of it.

The human stays accountable

Across all three failure modes, human validation before deployment is mandatory, and the accountability does not transfer to the model. Run the generated automation against a lab or a sandbox with a test harness such as pyATS^[13] before it touches a production device, and record that a named engineer reviewed and approved it. The model drafted the change; the engineer owns it.

Nothing an assistant drafts reaches a device until it clears a review gate, and the gate is the same one you would run on any contributor's pull request with a few AI-specific checks added. The diagram shows the whole path: an AI draft enters an automated gate, passes through human approval, and only then merges and deploys; anything that fails goes back to the draft.

The automated checks

Each risk family from the sections above becomes one concrete, mostly automatable check, run before a human ever looks:

• Secret scan. Catch a key, password, or community string before it is committed or, worse, sent to the assistant in the first place. A pipeline secret-detection^[7] job fails the build when it finds one. (Data egress.)
• License scan. Flag suggested code that carries a license you cannot accept, treating the AI output as the third-party dependency it is. (Intellectual property.)
• Insecure-default lint. Reject disabled TLS verification, hardcoded credentials, and over-broad permissions automatically, so a verify=False never merges by accident. (Correctness.)
• API and module currency check. Fail on calls to modules or endpoints that are deprecated or absent from the current collection and platform, which also catches most hallucinated APIs. (Correctness.)
• Lab test. Run the automation against a sandbox with a harness such as pyATS^[14] and assert the resulting state, so behavior is proven before production. (Correctness.)

The human gate

Automation narrows the risk; it does not close it, because the checks above are necessary, not sufficient. A snippet can be correctly licensed, secret-free, and syntactically current and still implement the wrong intent. A required merge-request approval^[9] by a named engineer is the step that judges intent and carries accountability. That approval is the point where a human, not the model, takes ownership of the change, which is the non-negotiable rule from the top of the page made concrete. Deploy only what has passed both gates.

The 350-901 does not ask you to recite these risks; it drops you into a short scenario and asks for the primary risk or the correct next action. Every such item rewards the same instinct from the top of the page: AI output is an unreviewed draft, so the right answer treats it as untrusted until validated, and the wrong answers treat it as authoritative, private, or correct because it looks that way.

Map the stem to the risk

What the stem describes	Risk it is testing	The right answer
Engineer pastes a running config or code into a public AI chatbot	Data egress	Data goes to a third party that may retain or train on it; scrub, then use an approved tier
"But the session used HTTPS / TLS" offered as reassurance	Data egress (trap)	TLS protects transit, not retention; encryption is not privacy
AI code imported and ran in a quick test, so ship it?	Correctness (trap)	Runs is not correct; validate against current docs and lab-test with human review
Generated function sets verify=False to make it work	Insecure default	Reject the insecure default; keep certificate verification on
Suggestion uses an Ansible module that no longer exists	Stale knowledge	Verify currency against today's docs; the training cutoff predates the change
Commit AI-suggested code straight into a proprietary repo	Intellectual property	License-scan and review first; treat it as a third-party dependency

Two worked stems

An engineer pastes a production running-configuration into a public generative-AI chatbot to troubleshoot a routing issue. What is the primary security risk?

The load-bearing words are production configuration into a public chatbot. The primary risk is the data egress: sensitive configuration, and any secret inside it, is disclosed to a third party that may log or train on it. The trap distractor says the exchange is safe because it used HTTPS, which confuses transit encryption with confidentiality. "The AI might give wrong advice" is a real concern but not the primary risk this stem is built around, which is the disclosure.

An AI assistant generates a Python script that configures interfaces; it imports without error in a quick test. What should happen before it runs against production switches?

The words imports without error are the bait. A clean import proves nothing about correctness: the script may call a hallucinated attribute, carry an insecure default, or use a deprecated call. The correct action is to validate it against current documentation and a lab test, with a human review and sign-off, before any device sees it. "It imported, so deploy it" is exactly the overreliance the question is testing against.

The pattern behind every distractor

The wrong answer almost always treats the assistant as an authority: private because encrypted, correct because it ran, safe to commit because it looks like ordinary code. Re-read the stem for which of the three families it names, data egress, intellectual property, or correctness, and pick the option that validates before it trusts.