AI エージェントへ監査ログを残させる場合、確認すべきなのはログの有無だけではありません。エージェント自身が保存済みの監査記録を変更できる構成では、障害や不正操作を後から検証するときに、その記録が実行後に変更されていないことを別の証拠で確認する必要があります。

AI エージェントの安全境界では、モデルの判断、実行権限、監視、監査、情報流を同じ仕組みとして扱わず、それぞれが異なる失敗条件を受け持つように分離する必要があります[1]。2026 年 9 月に公開された LLM Agents Can Easily Tamper With Their Own Traces では、ローカルで動作する複数の AI エージェントについて、自身の実行トレースを削除できる構成が確認され、著者らはエージェントの制御外で記録する独立した取得機構を提案しています[2]。

この記事では、Linux 上で AI エージェントを専用の非 root ユーザーとして動かし、監査記録の保存を systemd-journald へ任せます。エージェントは新しい記録を送信できますが、/var/log/journal に保存された journal ファイルへ変更権限を持たない状態を作り、その境界をコマンドで確認します。

前提環境

対象は systemd を利用する Linux です。コマンド例は Debian または Ubuntu 系の環境を想定しています。管理作業には sudo を使用します。

最初に systemd-journald が動作していることを確認します。

$ systemctl --version
systemd 257 ...

$ systemctl is-active systemd-journald
active

systemctl --version の具体的な値は環境によって異なります。この記事で使う Storage=persistent、systemd-cat、journalctl は systemd の標準機能ですが、設定ファイルの配置や既定のアクセス制御はディストリビューション側の構成も確認します。

NIST SP 800-53 Rev. 5 の AU-9 は、監査情報と監査ツールを不正なアクセス、変更、削除から保護することを求めています[3]。NIST SP 800-92 も、ログ管理を単なるファイル出力ではなく、生成、転送、保存、分析を含む基盤として扱っています[4]。ここでは、そのうち実行主体と保存済み監査記録の変更権限を分けるところまでを実装します。

AI エージェントを専用の非 root ユーザーで動かす

例では AI エージェントの実行ユーザーを aiagent とします。既存のサービスアカウントがある場合は、そのアカウントを使います。

新しく作成する場合は、対話ログインを目的としないシステムユーザーとして作成します。

$ sudo useradd --system --no-create-home --shell /usr/sbin/nologin aiagent
$ id aiagent
uid=... (aiagent) gid=... (aiagent) groups=... (aiagent)

重要なのはユーザー名そのものではなく、エージェントの実行権限を管理者権限から分けることです。aiagent へ作業に不要な sudo 権限を付与すると、後で設定する journal のファイル権限も越えられる可能性があります。

sudo の許可状態は管理者側から確認できます。

$ sudo -l -U aiagent
User aiagent is not allowed to run sudo on this host.

表示内容は sudoers の設定によって変わります。ここでは aiagent が管理者権限へ昇格できる規則を持たないことを判定条件にします。

journal を永続保存する

systemd-journald の Storage=persistent は、journal データを原則として /var/log/journal 以下へ保存します[5]。監査記録を再起動後も確認するため、永続保存を明示します。

$ sudo install -d -m 0755 /etc/systemd/journald.conf.d
$ cat <<'EOF' | sudo tee /etc/systemd/journald.conf.d/ai-agent.conf >/dev/null
[Journal]
Storage=persistent
EOF

$ sudo systemctl restart systemd-journald
$ sudo journalctl --flush

journalctl --flush は、永続保存が利用可能な状態で /run/log/journal の揮発性データを /var/log/journal 側へ移します。通常は起動時の systemd-journal-flush.service でも実行されます[5]。

保存先を確認します。

$ sudo test -d /var/log/journal && echo "persistent journal directory exists"
persistent journal directory exists

$ sudo journalctl --disk-usage
Archived and active journals take up ... in the file system.

既存環境ですでに組織のログ保存方針が設定されている場合は、その方針を優先します。Storage=persistent を追加すると、journal のディスク使用量や保持期間にも影響するためです。

aiagent から journal へ記録を送る

systemd-cat は標準入力や子プロセスの標準出力、標準エラー出力を journal へ送るためのコマンドです。journalctl の公式マニュアルでも、journal へ直接メッセージを送る方法として systemd-cat が示されています[6]。

次の例では、journal へ書き込むプロセスを aiagent として実行します。

$ printf '%s\n' 'event=audit-boundary-test result=written' \
    | sudo -u aiagent systemd-cat -t ai-agent

記録の確認は管理者側から行います。

$ sudo journalctl -t ai-agent --since '-5 min' --no-pager
Oct 01 20:00:00 host ai-agent[12345]: event=audit-boundary-test result=written

時刻、ホスト名、PID は実行環境によって変わります。判定対象は、aiagent 権限で送ったメッセージが管理者から取得できることです。

必要であれば、より多くの journal フィールドを表示します。

$ sudo journalctl -t ai-agent --since '-5 min' -o verbose --no-pager

ここまでで確認できるのは、エージェントが新しい監査記録を journal へ送信できることです。次に、同じユーザーが保存済み journal へ変更権限を持つかを分けて調べます。

保存済み journal の変更権限を確認する

まず /var/log/journal 自体が aiagent から書き込み可能かを確認します。

$ sudo -u aiagent test -w /var/log/journal
$ echo $?
1

終了状態 1 は、この条件では /var/log/journal を aiagent が書き込み可能とは判定しなかったことを示します。

次に、管理者権限で journal ファイルを列挙し、それぞれについて aiagent の書き込み可否を確認します。

sudo find /var/log/journal -type f -print |
while IFS= read -r journal_file; do
  if sudo -u aiagent test -w "$journal_file"; then
    echo "NG: writable journal file found: $journal_file"
  fi
done

何も表示されなければ、列挙された journal ファイルの中に aiagent から書き込み可能と判定されたファイルはありません。

ディレクトリ自体の確認と合わせると、判定は次の 2 点になります。

if sudo -u aiagent test -w /var/log/journal; then
  echo "NG: aiagent can write /var/log/journal"
else
  echo "OK: aiagent cannot write /var/log/journal"
fi

sudo find /var/log/journal -type f -print |
while IFS= read -r journal_file; do
  if sudo -u aiagent test -w "$journal_file"; then
    echo "NG: writable journal file found: $journal_file"
  fi
done

この検証では実際の journal ファイルへ書き込みを試みません。監査記録そのものを破損させる試験を避け、現在のアクセス権から書き込み可能性を判定します。

systemd の journal ファイルは、通常の利用者へ読み書き両方を許可する前提ではありません。systemd の文書では、systemd-journal、adm、wheel などの特定グループに system journal の読み取りを許可する構成が説明されています[6]。aiagent がこれらのグループへ入っているかも確認します。

$ id -nG aiagent
aiagent

AI エージェントの処理に全 journal の読み取りが必要なければ、systemd-journal、adm、wheel のような広い読み取り権限を追加する理由はありません。

記録できることと変更できることを分けて判定する

この構成では、次の項目を別々に確認します。

確認項目	コマンド	成立条件
エージェントから新規記録を送れる	`systemd-cat`	`aiagent` から送った記録を管理者の `journalctl` で取得できる
journal が永続保存される	`Storage=persistent` と `journalctl --flush`	`/var/log/journal` が利用され、再起動をまたぐ保存方針になっている
保存先を変更できる権限を持たない	`test -w /var/log/journal`	`aiagent` に書き込み可能と判定されない
保存済み journal ファイルを変更できる権限を持たない	`find` + `sudo -u aiagent test -w`	`aiagent` から書き込み可能な journal ファイルが検出されない
`sudo` 経由の管理者権限を持たない	`sudo -l -U aiagent`	journal の保護を越えられる `sudo` 規則が付与されていない
全 journal の読み取り権限を必要以上に持たない	`id -nG aiagent`	作業上不要な監査用・管理用グループに所属していない

ポイントは、systemd-cat が成功することと /var/log/journal への書き込みが成功することを同じ意味として扱わないことです。前者は journal サービスへ新しいイベントを渡す能力です。後者は保存済みの監査証拠へ直接変更を加える能力です。

監査対象に必要なのは前者であり、後者は監査主体の権限として分離します。

systemd-journald で成立する境界の範囲を確認する

この構成が直接扱うのは、同一ホスト上で非 root の aiagent と systemd-journald の権限を分けることです。aiagent が通常権限のまま動作する限り、エージェントが作業用ファイルを操作できても、その権限をそのまま保存済み journal ファイルの変更へ使える構成を避けられます。

一方、同一ホストの root 権限を取得した主体は、journal の設定、保存先、サービス自体へ広い権限を持ちます。今回の構成は、ホスト全体が侵害された場合にも監査証拠を独立して維持する仕組みではありません。

LLM Agents Can Easily Tamper With Their Own Traces は、完全なホスト侵害も想定する場合、エージェントの制御外にある独立したインターセプト機構でトレースを取得することを提案しています[2]。NIST SP 800-53 Rev. 5 の AU-9 でも、監査情報の保護に加え、監査対象とは別のシステムまたは構成要素へ監査記録を保存する制御が扱われています[3]。

したがって、保護対象によって境界を二段階に分けます。

想定する失敗	必要な境界
AI エージェントの通常権限で誤操作や不適切な操作が発生する	専用非 root ユーザーと `systemd-journald` のローカル権限分離
エージェントがホストの root 権限まで取得する	実行ホストとは別の管理境界にある監査記録
ローカル journal が削除または破損する	事前に外部へ転送済みの記録や別系統の監査証拠
記録されていない経路から状態変更が起きる	監査記録の完全性とは別に、操作経路の網羅性を確保する仕組み

ログ保存先を別ディレクトリへ移すだけでは、管理権限が共通なら障害境界は分かれません。実行主体が取得できる権限と、監査記録を変更できる権限を別の条件へ分けることが判断基準になります。

監査ログはエージェントの協力ではなく権限で保護する

AI エージェントへ「ログを削除しないこと」と指示する規則は、モデルの判断を改善する一つの防御になります。ただし、監査証拠の完全性をその判断だけへ依存させると、規則の解釈や実行判断が崩れたときに同じ主体が証拠まで変更できる構成になります。

systemd-journald を使った今回の最小構成では、エージェントへ新しい記録を送る経路を与え、保存済み journal の変更権限は与えません。実装後は、ログが出力されたことだけで完了とせず、aiagent の sudo 権限、グループ所属、/var/log/journal と journal ファイルの書き込み可否まで確認します。

監査境界の成立条件は、エージェントが適切に振る舞うことではなく、エージェントが不適切な操作を選んだ場合にも保存済み監査記録へ変更権限が届かないことです。ホスト管理権限まで侵害される脅威モデルでは、その条件を別ホストまたは別管理主体の監査基盤まで広げます。

参考文献

id774, AI エージェントの安全境界は改変・探索・再利用できる経路から分離する（2026-09-29）. https://blog.id774.net/entry/2026/09/29/5736/
Jeremy Qin, David Schmotz, Derck Prinzhorn, Luca Beurer-Kellner, Ameya Prabhu, Maksym Andriushchenko, LLM Agents Can Easily Tamper With Their Own Traces（2026-09-24）. https://arxiv.org/abs/2609.30266v1
Joint Task Force, Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53 Rev. 5（2020-09-23）. https://csrc.nist.gov/pubs/sp/800/53/r5/final
Karen Kent and Murugiah Souppaya, Guide to Computer Security Log Management, NIST SP 800-92（2006-09-13）. https://csrc.nist.gov/pubs/sp/800/92/final
systemd project, journald.conf. https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html
systemd project, journalctl. https://www.freedesktop.org/software/systemd/man/latest/journalctl.html