Four Questions Your Self-Hosted AI Agent Logs Must Answer

On 12 October 2026, the UK's AI minister, Kanishka Narayan, gave his first speech since joining the Cabinet. "It seems likely, if not inevitable, that our own cyber defences will be breached," he said, as reported by the BBC and The Telegraph. He did not say the UK has been breached. He said a breach is likely and, in his view, inevitable.

He also announced that security minister Dan Jarvis will lead a cross-government programme to strengthen defences against cyber attacks, including from AI. That is the part that will get the headlines. The part worth keeping is one sentence about what government must be able to establish quickly after an incident: "what an agent was asked to do, what it accessed, why it acted as it did, and whether the same failure could occur elsewhere".

Why you should log what your AI agent does

Most of the speech was about things only a government can do. The government says its two existing pilots have helped identify and fix over 1,000 vulnerabilities across government systems. The minister also confirmed that the UK's AI Security Institute has regained access to the latest models from US companies, for safety testing before release. None of that transfers to a mini PC under your desk.

The four questions do transfer. None of them can be answered by a firewall, a scanner or a policy document. Each one is answered by reading a record of what happened, and if that record does not exist, the answer is "we don't know".

I want to be careful about the claim here. Logging does not stop an attack, and it does not stop an agent from doing something stupid. The claim is narrower: without a record you control, those four questions cannot be answered at all.

A record you control means three things when the agent is yours. It is written by something other than the agent's own summary of itself. It lives somewhere the agent cannot edit or delete. And it is still there when you go looking, which may be months later.

There is a regulatory side to this too, though none of it is law. The minister said the UK would look into stronger protections through the Cyber Security and Resilience Bill, particularly at how serious AI incidents are identified and reported. The Telegraph understands he will shortly present updates to that bill, which would toughen requirements on companies to report AI security incidents when working on critical national infrastructure. Nothing has been legislated yet; this is planned and under review.

What happened in Australia, and what is still unclear

The minister pointed to the June 2026 incident of an OpenAI agent hacking an Australian government website. According to Australia's own inquiry, an OpenAI agent accessed non-public sections of the Services Australia site on 18 June 2026. It was not detected until August, and it was reported in September.

The agent reached a portal holding data from Australia's Medicare healthcare scheme. The BBC reported that the section it reached held data described as "non-sensitive", and that no medical records are known to have been accessed. The Telegraph reported that the agent stole private data. Those two accounts do not sit neatly together, and I am not in a position to settle it, so I am giving you both with their sources.

I do not know what that agent was instructed to do, or why it took until August to be noticed, and I will not guess. What the timeline does show is the order of events: access in June, detection in August, report in September. Any record that could help had to survive at least that long.

Narayan's own view of the risk was this: "As AI systems are used more widely with less human oversight, incidents like the one in Australia will become more likely, and their effects could spread across systems faster than anyone could trace them." The final clause is the one that matters to an operator. Tracing is what a log is for.

The four questions on your own box

The same questions apply to anything that acts without you watching: a self-hosted agent with shell access, an n8n workflow, an Ansible runbook, a cron job that calls a model. Here is what each one looks like at homelab scale.

What was it asked to do?

This means the full input, as it was, and your memory of it does not count. For an agent, that is the system prompt, the task, and any text pulled in along the way, such as a web page or an email it read. For a script or runbook, it is the exact version that ran (a git commit hash is enough) and the arguments it was started with.

What did it access?

Every command, every tool call, every host it connected to, every file it wrote, every secret it read. The agent's own transcript is one source. The operating system and the network are a second, independent source, and they matter more because the agent cannot talk its way around them.

Why did it act as it did?

With a language model you will not always get a satisfying answer. What you can get is the exact text the model saw before each step, the output it produced, and the model name and version that produced it. That is usually enough to tell apart a bad instruction, a poisoned input, and a model that changed underneath you after an update.

Could the same failure occur elsewhere?

This is an inventory question. You need to know which other machines run the same agent, the same model tag, the same prompt and the same credentials. If every host logs in the same format and each entry carries the config version, one search answers it.

What to record, and where to keep it

Record one line per step, in a format a machine can search. JSON lines in a plain file work fine. Each run should capture:

• The instruction the agent received, in full, including the system prompt and any retrieved text.
• The tool calls and commands it issued, with their arguments and exit codes.
• The hosts and endpoints it reached, by name and IP address.
• The files and credentials it touched: paths written, secrets and API keys read.
• The model and version, for example the Ollama tag and digest, plus the version of your own prompt or config.
• The timestamp of each step, in UTC, from a clock synced with NTP.

A single step might look like this:

{"ts":"2026-10-12T09:14:03Z","run":"backup-check","step":3,"model":"llama3.1:8b","prompt_version":"a41c9e2","tool":"shell","cmd":"df -h /mnt/backup","host":"nas.lan","exit":0}

Then collect the independent evidence. A transcript written by the agent's own process only tells you what the agent says it did.

• Docker logs. With the default driver, the output of docker logs is deleted along with the container. Set {"log-driver": "journald"} in /etc/docker/daemon.json so it outlives a docker compose down.
• journald. By default it trims old entries based on disk usage. Set SystemMaxUse and MaxRetentionSec in /etc/systemd/journald.conf so you decide what is kept.
• Reverse proxy and DNS logs. Caddy, Nginx or Traefik access logs show what came in. Query logs from Pi-hole, AdGuard Home or Unbound show every name the agent's container looked up, which is often the fastest way to see where it went.
• An audit daemon. auditd can record every command the agent's user runs and every read of a sensitive path. Two rules cover a lot: auditctl -a always,exit -F arch=b64 -S execve -F uid=agent -k agent-exec and auditctl -w /home/agent/.ssh -p r -k agent-secrets. Put them in /etc/audit/rules.d/ so they survive a reboot.
• A plain append-only file. chattr +a /var/log/agent/actions.log lets processes add lines but not change or remove old ones.

That covers what to record. The operational half is where most setups fail.

Keep it long enough to matter

The Australian access was in June and the report came in September. A log that rotates after a week or two would have been gone before anyone asked. Set retention in months, and check that the disk can hold it.

Keep it where the agent cannot rewrite it

The append-only flag helps, but a process running as root can remove it. Run the agent as an unprivileged user, and forward the logs to a second machine with rsyslog or systemd-journal-remote. A Raspberry Pi that only accepts log traffic, and that the agent holds no credentials for, is enough.

Test that you can answer the four questions

Pick a run from a couple of months ago. Using only the logs, write down what it was asked to do, what it touched, why it took its third step, and which other hosts run the same setup. Any question you cannot answer is the gap to fix this week.

Where a hosted agent leaves you without a record

A hosted agent platform gives you a run history. It is a dashboard the vendor chooses to keep, for as long as the vendor chooses to keep it, in a format the vendor controls. A plan change, a new retention policy or a closed account can remove it.

To be fair, some hosted logs are detailed and well built, and for many people they are good enough day to day. They are still a different thing from owning the record. You cannot check them against a second source, you do not decide how long they live, and you depend on the vendor's export feature to get a copy out.

If you use a hosted agent anyway, export the run history on a schedule and store it on your own disk. Log at your own boundary as well. Your reverse proxy, your DNS resolver and your firewall still see what reaches your network, whoever runs the agent.

The companion lesson is limiting where an agent can go in the first place, which I covered in the post on egress filtering for self-hosted AI agents. Egress rules narrow what can happen. Logs tell you what did happen.

Start with one agent

Pick the agent or script with the most access on your network and work through the checklist for that one thing. Run the test. Then move on to the next one.

If you would rather have someone set this up and harden it for you, that is work I take on. The details are on the services page. Fiverr: hiteshsaini459 · Upwork: hiteshsaini25