Automating security work with AI: scripting, low-code and no-code tools, documents and tickets

Why this matters

A security team spends much of its week on work that is necessary but is not judgement: a script to pull accounts from one system and reformat them for another, a flow that connects the phishing mailbox to the ticket queue, an incident report assembled from chat logs and console history, a long supplier assurance pack reduced to its exceptions, twenty tickets updated with the same status. AI is good at exactly this, and used well it gives analysts back the time for decisions only they can make.

It also brings new ways to fail. Generated code can be subtly wrong or insecure, and it runs with the analyst's privileges. A no-code flow built in an afternoon can end up holding production credentials with no owner. A synthesised report can drop the one finding that mattered or include one that never existed. A ticket closed automatically on a model's classification can be the incident nobody investigated.

This lesson covers scripting with AI help, low-code and no-code automation, document synthesis and summarisation, and incident response ticket management, and finishes on where automation must stop. Lesson 26 carries the theme into AI agents, approvals and change management, and lesson 27 into CI/CD.

Scenario questions here usually describe an automation that works and ask what is missing. The missing piece is usually review, ownership, traceability or a point where a person decides.

The lesson

Scripting with AI help, and reviewing generated code before it runs

Typical uses are small and frequent: a PowerShell script listing accounts whose passwords never expire, a Python parser for a log export, a detection query in the SIEM's query language, a regular expression for an indicator format. The speed gain is real, especially for people who script occasionally, and those are exactly the people least equipped to spot what is wrong with the output.

The risks are specific:

• Plausible but wrong. The script runs and produces output, but a filter misses a case or a query covers the wrong time window. Security scripts often answer a question such as "which hosts are affected?", so a wrong answer looks like reassurance.
• Destructive at scale. A clean-up script that disables, deletes or modifies objects, written from a loose description, does a great deal of damage with an administrator's rights.
• Insecure patterns. Hard-coded credentials, disabled certificate checks, unsanitised input passed to a shell, permissions broader than needed.
• Invented dependencies. A suggested package that does not exist, or that exists only because someone registered a name models tend to hallucinate, which turns a typo-like mistake into a supply chain compromise.
• Leakage in the prompt. Pasting real logs, hostnames, keys or customer records into an unapproved assistant to get help writing the parser.

Review before anything runs:

• Read it and be able to explain every line. If you cannot, it does not run.
• Check every import against the approved package repository.
• Test against a known answer on a non-production system or a copy of the data. For anything that changes state, run a dry-run or read-only mode first and compare its list of intended changes with what you expected.
• Run it with least privilege, under an account scoped to the task rather than your daily administrator account.
• Scan it like other code: linting, static analysis and secret scanning, as lesson 27 describes for the pipeline.
• Keep it. A script that will be reused goes into version control with a note of what it is for, who reviewed it and that it was AI-assisted.
• Use approved assistants only, and minimise or redact data before it goes into a prompt (lesson 14).

Low-code and no-code automation, and who owns it once it is running

Low-code platforms build automation visually but let the builder drop into code for custom steps; many SOAR playbook editors work this way. No-code tools are configured entirely through a visual canvas, forms or, increasingly, a natural-language description that an AI assistant turns into a workflow: "when a message arrives in the phishing mailbox, extract the links, check them against threat intelligence, open a ticket and thank the reporter".

The benefit is that analysts automate without waiting for an engineering team. The risk is that this is citizen development, with the same governance gaps as any shadow IT (lesson 31 covers shadow AI):

• Connectors hold credentials. Each connection to mail, ticketing, EDR or a cloud account is authenticated, often with the builder's own account or a broad token. The flow inherits that access, and so does anyone able to edit the flow.
• Logic is invisible to normal review. A canvas is not in version control, not peer-reviewed and not seen by code scanning.
• Data moves outside controls. A connector can send data to an external service, including an AI service, without passing data loss prevention.
• Untrusted input drives actions. A flow that reads inbound email treats an attacker's email as input. If an AI step interprets that content, the flow is exposed to indirect prompt injection (lesson 17).
• Ownership decays. The builder changes role, the flow keeps running on their credentials, and when it fails nobody knows what it did.

Who owns it once it is running is a governance question with a concrete answer:

• An inventory of flows, each with a named owner and deputy, a purpose, its connectors and the data it touches.
• Service identities, not personal accounts, each scoped to the flow's task and reviewed like any privileged credential.
• Separate environments, so that anything touching production systems or sensitive data is promoted from development through review.
• Exported definitions in version control where the platform allows it, so changes can be compared and reverted.
• Run logs of every trigger and action, sent to central logging.
• Connector policy, defining which connectors may be combined, so a flow cannot join the HR system to a personal file-sharing account.
• Lifecycle triggers: when an owner leaves, their flows are suspended until someone else takes them on.

Document synthesis and summarisation for reports and evidence packs

Synthesis produces a new document from several sources: an incident report from the timeline, tickets and chat; an audit evidence pack from control test outputs and screenshots; a policy draft mapped against a standard. Summarisation condenses one source: a supplier's assurance report reduced to its exceptions, a threat intelligence report turned into an executive briefing. Lesson 22 covered checking a single summary against its source. Here the concern is documents that other people will rely on as records.

Where the help is real: first drafts in a consistent structure, the same facts rewritten for technical and executive readers, and extracting the relevant items from long material.

The failure modes that matter for formal documents:

• Omission. The qualified opinion, the excluded system or the control exception disappears. In an assurance report the exception is the point.
• Fabrication. An invented control identifier, date or finding, or a citation to a passage that says something else.
• Flattened confidence. "Possibly" and "not yet confirmed" become plain statements, which matters greatly in a breach report.
• Crossed sources. In synthesis, an event attributed to the wrong host, or one system's evidence filed under another control.
• Hostile content. A document being summarised can contain instructions aimed at the model, so supplier-supplied material is untrusted input.
• Classification. Incident detail, personal data and legally privileged material go only to a tool approved for that classification.

The controls:

• Templates with required sections, so an omission shows as an empty section rather than vanishing. A prompt template that fixes the structure also makes outputs comparable.
• Citations to source, with each claim linked to the evidence item it rests on, and a reviewer who follows a sample of them.
• Review proportional to consequence. Anything going to a regulator, auditor, customer, court or board is checked against its sources by an accountable person, who signs it.
• The source stays authoritative. An evidence pack links to preserved original evidence, and the narrative never replaces it.
• Labelling. AI-assisted documents say so, which tells a reader what kind of review they deserve.

Incident response ticket management with AI

Tickets are the operational record of incident response. AI can help at each stage of a ticket's life:

• Intake. Turning a free-text report or an alert into a structured ticket with the fields filled, indicators extracted and asset and owner details attached.
• Deduplication and correlation. Recognising that forty user reports of the same lure are one incident, and linking them.
• Classification and routing. Suggesting category and severity and sending the ticket to the right queue.
• Hygiene. Chasing tickets breaching their service level, flagging missing fields, drafting status updates and shift handovers.
• Closure and review. Drafting closure notes and the post-incident summary, and producing the metrics the programme reports.

The risks:

• Silent misclassification. A ticket marked low severity is worked late, and a false negative looks exactly like a quiet day.
• Automatic closure of tickets judged to be false positives, so a real incident is never seen by a person.
• Attacker-written content. Ticket text includes email bodies, log lines and file names that the intruder controls, and these can steer a model's classification or summary.
• Access widening. A summary posted to a shared channel can show sensitive ticket detail to people who could not open the ticket.
• Record integrity. Tickets may become evidence, so every automated change must be attributable.

The controls:

• Suggest, then confirm. The model proposes severity; an analyst confirms anything above a threshold, and lowering severity always needs a person.
• Narrow auto-closure. Only for tightly defined, tested categories, with a regular sample of auto-closed tickets reviewed by a person.
• Measure agreement. Compare the model's classification with the analyst's final one, and treat a falling agreement rate as drift.
• A dedicated automation identity with limited rights, able to comment, enrich and suggest but not to close high-severity tickets.
• Logged inputs, outputs and model version for every automated change (lesson 15).

Where automation must stop and a person must decide

The working rule: automate gathering, drafting and repetition, and keep decisions with a person when any of the following holds.

• The action is irreversible or wide. Deleting data, disabling accounts in bulk, isolating production systems.
• Accountability is personal. Deciding whether a breach is notifiable, submitting to a regulator, signing an attestation, starting disciplinary action, declaring an incident closed. A model cannot be accountable, and an organisation that lets one decide still owns the outcome.
• The case is new. The input falls outside what the automation was tested on, or the model reports low confidence.
• The input could be hostile and the action helps an attacker. Lowering a severity, allowlisting a sender, closing a ticket and granting an exception are all outcomes an attacker would like to cause.
• It speaks for the organisation externally, to customers, regulators or the press.

The person must be making a real decision. An approval screen that shows only "approve?" invites rubber-stamping; one that shows the evidence, the proposed action and what the model was unsure about supports judgement. Watch approval rates, because a rate that drifts towards one hundred per cent means the check has stopped working. Lesson 26 turns these criteria into levels of autonomy for agents and applies them to change approvals.

A short scenario

A SOC builds a no-code flow that reads the phishing mailbox, asks a model to classify each report and closes any the model calls a "marketing email". A targeted message containing text addressed to the model is classified as marketing and closed, and the attacker's link stays live. The gaps are an automated closure on attacker-controlled input, no sampling of closed tickets, and a flow running on its builder's account. The fixes follow the sections above: the model suggests and a person confirms, auto-closure is restricted and sampled, and the flow gets an owner and a scoped service identity.