AI for IT work: scripts, troubleshooting and documentation, minus the risks

For a lone sysadmin or a small MSP, an AI assistant is like having a junior admin who has read every forum post ever written, types instantly, and occasionally invents a cmdlet with total confidence. Used well, it takes the drudgery out of scripting, log reading and documentation. Used carelessly, it’s a new way to leak credentials, break production or install malware.

This guide assumes you’ve read Using AI safely. Everything there applies double when the data is logs, configs and client environments.

Where it earns its keep

Scripting

AI is very good at producing a first draft of a PowerShell, Bash or Python script, explaining an unfamiliar script line by line, converting between languages, and adding error handling and logging to something you already wrote.

Ask for safe defaults up front. A prompt like this gets far better results than “write a script to clean up AD”:

Write a PowerShell script for Windows Server 2022 with the ActiveDirectory module.
Goal: report (do not change) user accounts that haven't signed in for 90+ days.
Output a CSV. Read-only. Comment every block. List any cmdlets or parameters
you're not certain exist so I can check them.

Then treat the result like code from a stranger on a forum:

• Look up every cmdlet, parameter, registry key and API call in the vendor’s documentation. Invented parameters and “almost right” property names are common.
• Keep reporting and changing in separate steps. Where the commands support it, run a dry run first (many PowerShell cmdlets support -WhatIf).
• Run it in a lab or against a test OU or a single test machine before production.
• Read the whole thing before running it. If you can’t explain a line, don’t run it.

Troubleshooting

Paste a scrubbed error message, event log excerpt or symptom description and ask for likely causes ranked by probability, plus a diagnostic step that would confirm or rule out each one. This is often faster than search when the error is vague. Then verify event IDs, error codes and fixes against the vendor’s knowledge base before acting. The AI’s explanation of a Microsoft error code is a hypothesis, not documentation.

Documentation

This may be the best use of all. Turn your messy notes into a runbook, a knowledge base article, an onboarding checklist, or a plain-English summary for a client or board. Feed it a scrubbed config and ask it to describe what the config does, then check that description against what you know. Documentation nobody had time to write is a big win for small shops and for audits.

Learning

Ask it to explain a protocol, compare two approaches, or quiz you before a certification exam. Confirm anything you’ll rely on against official docs.

The risks, specifically

Invented commands and settings

Models generate plausible text, and plausible-but-wrong commands are a real hazard: a parameter that doesn’t exist, a registry value from a different Windows version, a firewall CLI syntax from the wrong firmware. GitHub’s own guidance on reviewing AI-generated code says to watch for hallucinated APIs, ignored constraints and incorrect logic, and to make sure code builds and tests pass.

Fake packages

AI coding assistants sometimes recommend software packages that don’t exist. A peer-reviewed study presented at USENIX Security 2025 tested 16 code-generating models across 576,000 code samples and found an average of 19.7% of the packages they suggested didn’t exist (at least 5.2% for the commercial models tested and 21.7% for the open-source ones), producing over 205,000 unique made-up package names. Many of those names came back repeatedly when the same prompt was rerun, which means an attacker could register a frequently invented name and wait for someone to install it. Before you pip install or npm install anything an AI suggested, confirm the package exists, comes from the expected publisher, and is actively maintained, as GitHub’s review guidance also recommends.

Prompt injection

When an AI tool reads content you didn’t write, like an email, a web page, a support ticket or a document, that content can contain instructions aimed at the AI. OWASP lists prompt injection as the top risk for applications built on large language models, and distinguishes direct injection (typed by a user) from indirect injection (hidden in content the model processes). This matters most for tools that can take actions: an assistant that reads your inbox and can also send email or run commands can be tricked by a booby-trapped message.

Over-privileged agents

AI agents that can run commands, change tickets, or log into consoles are only as safe as the permissions you give them. OWASP calls this excessive agency and traces it to three causes: too much functionality, too many permissions, and too much autonomy. Its example is a tool that only needs to read data but was given a connection that can also delete it.

Data leakage

Logs and configs are full of things that shouldn’t leave your environment: usernames, hostnames, internal and public IPs, email addresses, license keys, and sometimes credentials. OWASP’s guidance on sensitive information disclosure includes educating users not to enter sensitive data and giving them a way to opt out of training.

Licensing and ownership

GitHub notes that code suggestions can sometimes match public code and that you’re responsible for reviewing what you use. For anything you’ll redistribute or deliver to a client, check licensing questions with whoever handles your contracts.

Guardrails for a small shop

1. Use a business account with training off by default and admin controls, never a personal free account, for anything client-related.
2. Scrub before you paste. Replace hostnames, IPs, usernames, domains and client names with placeholders. Never paste passwords, keys, tokens or connection strings.
3. Verify against vendor docs. Every command, parameter, event ID and setting.
4. Lab first, production second, with a backup and a rollback plan.
5. Least privilege for agents. Read-only credentials wherever possible, scoped to one system, with a human approving any change, send or delete.
6. Treat untrusted content as untrusted. Be careful letting an AI that can take actions read email, tickets or web pages.
7. Check every package before installing it.
8. Respect client and compliance rules. Many contracts and frameworks restrict where data can go. For CJIS environments, confirm with the CJIS Systems Agency before any AI tool touches systems that store or process criminal justice information.
9. Keep a record of AI-assisted changes in your normal change notes, so the next person knows where a script came from.

The rule that covers almost everything: AI can draft, explain and suggest. A human who understands the change approves it and runs it.

Sources

• OWASP Top 10 for LLM and GenAI Applications (2025 list)
• OWASP LLM01: Prompt Injection (direct and indirect injection, mitigations)
• OWASP LLM02: Sensitive Information Disclosure (user education, training opt-out)
• OWASP LLM06: Excessive Agency (excessive functionality, permissions and autonomy)
• Spracklen et al., “We Have a Package for You!” USENIX Security 2025 and full paper (PDF) (package hallucination rates)
• GitHub Docs: Review AI-generated code (check dependencies, hallucinated APIs, tests)
• GitHub Docs: Responsible use of Copilot inline suggestions (security review, matching public code)
• Microsoft Learn: about_CommonParameters (the -WhatIf risk-mitigation parameter)