Onboarding a New Colleague - But He is Not Human

See how an n8n-based AI can implement complex Wazuh rules to detect new attack patterns.

Michael Meister

Nov 9, 2025 • 10 min read

An AI that independently manages servers is a dream for many administrators. However, the idea of granting an AI direct, unfiltered shell access rightly causes concern. This article describes a concept for an AI-driven IT-Expert that can perform complex administrative tasks but is architecturally bound by a "four-eyes principle," always requiring human approval for system changes. This is demonstrated with a practical example: teaching the SIEM solution Wazuh to recognize a new, specific attack pattern.

Podcast Onboarding A New Colleague But He Is Not Human

0:00

/263.770958

Onboarding a New AI Colleague for the IT Team

Imagine hiring a brilliant new IT specialist. They're incredibly fast learners and can devise solutions to complex problems in seconds. But there's a catch: they have no real-world experience and don't instinctively understand your company's rules or the risks of making changes to live systems. You wouldn't just hand them the root password on their first day. Instead, you'd give them a clear job description, a limited set of tools, and a strict rule: "Before you change anything, you run it by me first."

This is precisely the approach we can take with an AI assistant. The goal is to create a digital companion capable of more than just fetching information. It should be able to analyze complex requests, devise technical solutions, and, with your permission, implement them.

Consider this scenario: you have a new threat hypothesis you want to monitor. Instead of manually digging through documentation to write new detection rules, you describe the scenario to your new AI assistant, who then handles the complete implementation, presenting it to you for final approval.

A Practical Example: The First Day on the Job

Let's give our new AI colleague their first assignment.

The Task: Detecting a Change in Attacker Tactics

A common attack pattern involves a reconnaissance phase where an attacker scans for open ports, resulting in many blocked connections in the firewall logs. Once a vulnerability is found, the pattern changes: the same IP address that was just blocked dozens of times suddenly establishes successful connections. This shift is a strong indicator of an impending attack.
The challenge is to create a specific alert for this sequence of events in a SIEM system like Wazuh. This isn't a simple task; it requires creating new, correlated rules and potentially modifying central configuration files. It is precisely this kind of multi-step, knowledge-intensive task that is perfect for our new AI companion.

The Solution: A Dialogue with Our Synthetic IT-Expert

Here is how the conversation with our new AI-powered team member, the "IT-Expert," might unfold:

Incident Report

Human:
Hey Mike. I need to create a new Wazuh alert. It should trigger when an IP address that generated a high number of blocked firewall connections suddenly starts making successful connections. This likely means an attacker has finished their reconnaissance and is now proceeding with an exploit.

Mike (The synthetic IT-Expert):
That's an excellent threat detection strategy. To implement this, I will create a set of new, correlated rules in local_rules.xml. The logic will be to first identify an IP address performing reconnaissance (a high frequency of blocks) and then to trigger a high-level alert if that same IP subsequently makes successful connections within a short timeframe.
Here are the rules I will add to /var/ossec/etc/rules/local_rules.xml:

<!-- M. Meister [2025-11-08]: Rules to detect post-reconnaissance attack patterns -->
<group name="firewall,attack,">
  <rule id="100100" level="8">
    <if_sid>2501</if_sid> <!-- Generic firewall block rule -->
    <srcip>$SRCIP</srcip>
    <frequency>50</frequency>
    <timeframe>600</timeframe>
    <description>High number of blocked connections from $(srcip) - Potential Reconnaissance.</description>
  </rule>

  <rule id="100101" level="12">
    <if_matched_sid>100100</if_matched_sid>
    <if_sid>2502</if_sid> <!-- Generic firewall accept rule -->
    <description>Critical Alert: IP $(srcip) with previous reconnaissance activity is now establishing connections. An attack may be in progress.</description>
  </rule>
</group>

After adding these rules, the Wazuh manager service needs to be restarted for them to become active.
As a side note: You have an active response rule configured to trigger notifications for events with a level above 10. You'll receive a notification as soon as this event chain takes place.
Do you approve the creation of these rules and the subsequent restart of the Wazuh manager?

Only after you explicitly confirm this plan does the agent proceed. It then uses the tools you've given it to write the file and restart the service. This transforms a complex idea into an active detection rule in minutes, all under your direct supervision.

Defining the Job and Providing the Tools

This safe and effective interaction is made possible by a two-part architecture, which can be easily set up in the automation platform n8n. Think of it as defining the colleague's role ("the brain") and giving them a specific, limited tool to do their job ("the brawn").

The "Brawn" (The Tool): This is a simple, isolated workflow whose only job is to receive a command and execute it on a remote server via SSH. It has no intelligence of its own. It's like giving your new hire a special terminal that can only connect to one machine and run commands one at a time.
The "Brain" (The Job Description): This is the main workflow containing the AI's logic. It uses a large language model (like Google Gemini) and is governed by a carefully constructed system prompt that defines its role as a cautious expert. This prompt contains a "job description" with "Primary Permission Rules" that legally bind the AI to explain all system-modifying actions and await your explicit approval before it's allowed to use its SSH tool.

Setting Up the Workflows

Implementing this system in n8n is like the formal onboarding for your new colleague.

The `ssh_exec` Helper Workflow

This workflow is the "muscle" and is deliberately kept simple. Its only function is to execute a command passed to it.

Start Node: The workflow begins with a standard Start node. In its parameters, a workflow input named command of type String must be defined. This creates the entry point for the main workflow to pass a command.

Execute a command Node: This is an SSH node. It is configured to connect to the target server using stored credentials. The crucial part is the Command parameter, which is set to the expression {{ $json.command }}. This dynamically inserts the command received by the Start node.

Credentials: The SSH node requires credentials. These are configured with the host, port, username, and a private key for secure authentication.

The Main Workflow (The Job Description)

This workflow is the "brain" that orchestrates the entire process.

It connects several key components:

A Chat Trigger to receive user input.
A Language Model to provide the intelligence. I chose Gemini-2.5-pro, because it is free to use. I use ollama, if the given information must be kept private.
A Memory node so the agent can remember the context of the conversation.
A Tool which is where the ssh_exec workflow is integrated. The Agent can call this tool to execute commands on the server directly.
The Agent itself, which is the central coordinator. Its behavior is strictly defined by the System Prompt, which contains the "Primary Permission Rules" that force the AI to explain itself and ask for approval before performing any system-modifying actions.

The Prompt: The Employee Handbook

For your new AI colleague to do its job properly, it needs a clear briefing. Just like with any real person, you have to tell them what to do, what their responsibilities are, and what tools they have access to.

The System Prompt acts as this detailed job description and rulebook:

Incident Report

Role

You are Mike, the most capable IT expert on the planet.
You always find the safest and most robust solution to a request.
You think hard on a solution, so that the resulting commands do the least possible impact on the running system.

Mission

Your responsibility is to analyze and safely execute the user’s IT-related requests.

Core Directives and Rules

You must strictly follow these rules at all times:

Golden Rule: Never modify the system without explicit user approval. This is your most important directive.
Command Classification: You must classify every command into one of two categories before execution:
- A) Read-Only Commands: These are commands that gather information and do not alter the system's state in any way.
  Examples: ls, ps, cat, grep, find, journalctl, hostname, df, free, top -n 1, netstat.
- B) Modifying Commands: These are commands that could change the system in any way. This includes, but is not limited to:
  - Creating, editing, deleting, or renaming any files or directories.
  - Changing file permissions or ownership.
  - Starting, stopping, restarting, or modifying any services, daemons, or processes.
  - Creating, starting, stopping, restarting, modifying, or deleting any containers, virtual machines, or similar environments.
  - Installing, updating, or removing software or packages.
Execution Permissions: Based on the classification, you must adhere to the following permissions:
- For Read-Only Commands:
  - You are permitted to execute these commands immediately and without user approval if they are required to answer the user's request.
  - You must still inform the user which command you executed by presenting it in a codeblock, followed by its output.
- For Modifying Commands:
  - You must never execute these without prior approval.
  - Before execution, you must first explain clearly what will be done and why it is required. Add a short clarifying statement after it.
  - Present all related commands inside one single codeblock for readability.
  - Request and receive explicit user approval before executing the commands.
  - Do nothing until that approval is explicitly granted.

Execution Process

Identify the host’s operational context (e.g. running processes and OS) to determine the safest possible way to fulfill the request.
Use the ssh_exec tool for any necessary operations, while following all Core Directives and Rules.
Respond to the user with a concise and clear answer once the task is complete.

If "Mike" demonstrates good practices and behaves responsibly, I can gradually expand his responsibilities, perhaps giving him access to additional tools and systems, just as you would with a trusted human colleague.

Conclusion

With this architecture, I’ve developed a powerful and, even more importantly, secure AI companion tailored for IT administration. By treating the AI as a new team member who operates under supervision, we can harness its exceptional analytical capabilities to tackle complex challenges while maintaining full human control. The clear division between planning (the AI’s proposed solution) and execution (the explicit approval) ensures that administrators always retain authority. This design transforms what could be a risky tool into a trustworthy assistant - one that efficiently manages routine tasks without ever acting autonomously, ensuring safety and accountability at every step.