Centralized logging for agent activity: self-hosted options

AI agents now run builds, edit code, call APIs, and handle credentials on developer machines. When one of them misbehaves — through a prompt injection, a bad tool, or a simple bug — the record of what it did is the only way to reconstruct the incident. Yet shipping agent logs to a hosted logging SaaS is itself a risk: agent logs contain prompts, file paths, and occasionally secrets, and sending them to a third party expands the exposure you were trying to monitor. Self-hosted logging keeps the records under your control. This article covers what to capture, how to move it, and which self-hosted stacks fit agent workloads.

Decide what to capture first

Before choosing software, define the events. For agent activity, the useful set is: tool invocations with their arguments, files read or written, network destinations contacted, credential resolutions, authentication events, and their outcomes. Log the event and its identifiers — never the secret values themselves. A log that records the API key it resolved is a new leak surface, not an audit trail. Use a structured format with a timestamp, an actor identifier (human or agent), an action name, a target, and an outcome; JSON Lines is the practical default because it is append-friendly and parseable by every tool below.

Start where the logs already land

On Linux, journald is the natural first stop: services, cron jobs, and agent helpers can write structured entries there with zero extra infrastructure. It is not a good long-term store on its own — no cross-host search, rotation is local — but it is a solid origin for the pipeline. Many agent tools also emit their own JSONL files; treat those as another origin. The job of the pipeline is to collect from these origins into one searchable place.

Pick a self-hosted stack

Three families cover most needs:

• Loki, with Promtail or Vector as the collector: label-based, cheap to run, designed for logs rather than general search. A good default for agent activity.
• OpenSearch: full-text search and dashboards, closer to a traditional SIEM, heavier on memory and operations.
• VictoriaLogs: a lighter log-focused store with SQL-like querying, a middle ground between the two.

Ship with Vector or Promtail so agents never write to the central store directly; the collector buffers locally when the store is down, which keeps the pipeline resilient. Secure the transport with TLS and authenticate the collectors — the log pipeline is itself a sensitive system, because it holds the record of everything else.

Keep the audit trail separate and append-only

Operational logs and the security audit trail are different things with different requirements. The audit trail should be append-only, protected with restrictive permissions, and rotated safely: a writer that reopens its log on SIGHUP works cleanly with logrotate, and a log that an attacker can edit is not evidence. If your agent tooling emits such a trail, wire it into the pipeline as a first-class source. The trustless CLI (https://github.com/ikkun1222/trustless) writes an append-only JSONL audit log of credential injection, proxy denials, and token refresh events — never the token values — and can write to journald instead; forwarding that stream into a self-hosted Loki or OpenSearch instance gives you a central, searchable record of which agent touched which credential, with the details documented at https://trustless-security.com/docs/.

Run it like production

Centralized logging only pays off if it is available when you need it. Monitor the collectors, set retention explicitly, and test the recovery path: a simulated incident should be reconstructible from the central store alone. The stack is infrastructure, and infrastructure needs maintenance.

What would your current setup show you if an agent exfiltrated a file today — and would the logs themselves still be free of secrets?