Local AI Security Desk: A Private Way to Read Security Logs

Here is a simple way to run a privacy-first WordPress security check without sending real logs to a cloud service. You start with your own copy, not a live file. Then you read, filter, and validate before you act.

The pages, logs, and examples in this post are local to this workflow. The downloadable logs are dummy training data only. They are not real customer logs, not production data, and not a ticketed incident file.

How the local incident loop works

1. Collect a read-only copy. Pull the relevant logs into a new folder and set them to read-only. That means your review tool cannot edit production files by mistake.
2. Normalize the raw text. Turn timestamps into one format, strip or hash any user IDs, and replace obvious secrets with placeholders. This keeps the review steps consistent.
3. Run a local model triage first. Feed the sanitized text into a local LLM prompt with strict rules: find suspicious patterns, rank by likely impact, and ignore normal background noise unless impact is clear.
4. Run deterministic checks. Confirm the model’s claims with fixed scripts: count event types, map event time windows, and verify file-change paths against known safe/unsafe rules.
5. Human verifier step. A human reads the evidence and verifies at least one fact for each finding. This is the guardrail that stops automation from guessing.
6. Publish an evidence-backed summary. Write the result as facts + line references + what to do next. No action without evidence.

Why this workflow stays safe

Because all evidence starts on your box, not a third-party server. The model only helps you spot patterns faster. You still keep the decision. You do not let software patch or delete anything automatically.

The local AI setup: Qwen on the Mac mini

Qwen runs locally through Ollama. Think of it as the local reader for this loop, not the security control and not the final verifier. I use Qwen3 8B as a conservative example model so the setup stays practical on a single Mac mini.

Pull it and start it from your terminal:

ollama pull qwen3:8b

ollama run qwen3:8b

# Example analyst prompt pasted into the interactive session
Find suspicious events in this sanitized log segment.
For each event include:
- exact timestamp
- confidence level
- short reason
- exact evidence text line references
Do not recommend any action unless every finding is directly tied to a matching log line.

Before feeding any log, confirm Ollama is listening only on the Mac. Run this check from your terminal:

lsof -nP -iTCP:11434 -sTCP:LISTEN

Good output should show 127.0.0.1 or ::1 only. If it shows 0.0.0.0, stop and fix exposure before loading logs.

Model-size choice depends on RAM and your Mac mini profile. A smaller model is fine for this demo. Larger models can add quality in some prompts, but they are not required for a first pass.

In this workflow, Qwen is a fast first reader. It receives a sanitized, read-only copy. It does not get a WordPress login, shell tools, or live-file write access.

Keep the loop simple and boring. Pull a copy of logs that is already scrubbed for secrets. Keep it local, then run Ollama as read-only assistant only. You are not asking this model to patch systems, open shells, or approve fixes.

When the model returns a list, I treat it like a first-pass shortlist. Every finding needs a second deterministic check. That means count windows, verify file paths, and trace each suspicious line to a real timestamp before any action.

I use the same routine for each incident candidate:

• Read-only evidence only.
• Model pass for candidate signals.
• Human evidence confirmation.
• Decision with a separate check that can be audited later.

That keeps the model fast and keeps you in charge. The model is helping your eyes move faster, not replacing your judgment.

Official references: Qwen3 repository and Ollama Qwen3 page.

Example 1: Login brute force in one file

Signal: Many failed XML-RPC logins from one source over a short window can mean a scripted attack.

What to do:

• Count failed attempts per hour.
• Check if usernames are the same set and if they spike around one time window.
• Compare against any known IP-reputation list you already use.

Possible safe next action: reduce XML-RPC exposure, enforce stronger auth limits, and verify rate-limit rules are in place.

Example 2: plugin probe + suspicious file-write signal

Signal: A request pattern that probes plugin paths and follows with file-write activity deserves attention.

What to do:

• Cross-match request paths with plugin directories in your allowlist.
• Flag file writes under upload or plugin directories when they contain executable extensions.
• Check file integrity hashes and modification times before deciding next steps.

Safe action: quarantine affected artifact copies, do not delete production files yet, and request a second deterministic check with backups available.

Example 3: false positive and deployment noise

Signal: A deploy or backup job can look scary if you only count “changes” and “uploads.” This can create noise.

What to do:

• Find matching events from your CI/CD window.
• Verify file ownership and deployment tags match your normal release pattern.
• Lower priority only after no attacker-like timing appears around the same window.

Safe action: keep this as “investigation complete, low confidence,” then document why it was normal activity.

Download dummy logs (training-only)

Both files are fabricated demo logs for practice:

• Download sample auth log
• Download sample file-change log

What good output looks like

Good output is short and checkable. You should be able to trace each claim to a log line.

Signal summary:
- High-confidence: 7 auth failures from one IP: 203.0.113.44 between 2026-07-26T09:02:20Z and 2026-07-26T09:02:35Z, all with auth_result=failed.
- Medium-confidence: 1 suspicious_file_write + 1 integrity status=new_file pair for wp-content/plugins/sample-upload/sample-shell.php at 2026-07-26T10:11:08Z and 2026-07-26T10:11:09Z.
- Low-confidence: 3 deployment INFO entries from staging IP 203.0.113.90 at 10:11:45Z, 10:11:46Z, and 10:11:47Z.

Recommended next action:
1) Pause non-essential plugin/theme edits until the suspicious artifact is reviewed.
2) Confirm both auth and file-change events against immutable backups.
3) Run a second local pass with stricter thresholds before any public statement.

Limits

• This workflow is for local analysis. It is not the same as a full managed SOC service.
• Logs can be mislabeled. Humans must close the loop before remediation.
• Local models can help spot patterns fast, but they can miss context unless you enforce fixed checks.
• This is a training-friendly, dummy-data setup for explanation and onboarding, not production forensics output.

If you want to get this review loop set up on your site, use /contact/.
If you want a guided check with a fixed rubric, use /agent-security-check/.