1. Executive Summary

Organisation: Example Corp（サンプル株式会社）

Prepared for: [TO FILL: IT / Information Security Department]

Security contact: security@example.com

Generated: 2026-08-16T15:03:20.847173+00:00 (Aigis v1.2.0)

What Claude Code is

Claude Code is Anthropic's command-line coding agent. It reads and edits

files, runs shell commands, fetches web content, and can call external

tools (including Model Context Protocol servers) on a developer's machine

to complete software-engineering tasks autonomously. Because it executes

real actions on a real workstation, an uncontrolled deployment is a

meaningful operational and security risk.

What Aigis adds

Aigis is a zero-dependency, open-source guardrail layer that sits between

the agent and the actions it wants to take. It provides three things an

IT/security department can rely on:

1. Deterministic pre-execution guardrails. A Claude Code *PreToolUse*

hook intercepts every tool call. Aigis scans the request, evaluates it

against your organisation's policy, and returns allow / review / deny

before the action runs. Decisions are rule-based and reproducible —

not a probabilistic model judging itself.

2. Tamper-evident audit logs. Every decision is recorded to an

append-only JSONL log. A signed variant (HMAC-SHA256 + hash chain)

makes after-the-fact deletion or modification detectable.

3. An organisation-owned policy. The policy is a human-readable file in

your repository, reviewed and version-controlled like any other code.

Aigis runs entirely locally and adds no new runtime dependencies. It does

not send your prompts or code anywhere; it governs what the agent is

allowed to do on your machine.

What this pack contains

• Control matrix — Aigis controls mapped to ISO/IEC 27001:2022 Annex A,

NIST AI RMF, OWASP LLM Top 10, and the METI/MIC AI Business Operator

Guidelines v1.2, plus an explicit "what Aigis does NOT cover" boundary.

• Policy snapshot — the exact policy currently in force, in plain

language and as literal YAML.

• Audit log evidence — where logs live, their schema, retention, the

tamper-evidence design, and the command to verify integrity.

• Incident runbook — what happens when Aigis blocks an action, how to

triage, escalate, and report false positives.

• Rollout plan — a three-phase pilot template with review gates.

Current live posture

• Policy profile: Aigis Default Policy (v1.0), 16

rules — 10 deny, 5 review, 1 allow.

Default decision when no rule matches: allow.

Read this before approving. The rule set is a deny-list: it enumerates

known-dangerous operations (recursive deletion, raw disk writes, credential and

SSH-key access, piping a download into a shell) and lets everything else

proceed — an agent that cannot run ls is not usable. So the default above is

**fail-open by design, not by oversight: an operation nobody wrote a rule for

will run.** If your review requires the opposite posture — deny unless

explicitly permitted — set default_decision: deny in aigis-policy.yaml and

add allow rules for the operations your team actually needs. That is a real

piece of work, and it is the honest price of a fail-closed configuration.

The policy name above comes from the policy file itself. If it was produced by

aigis profile build, the capability combination behind it decides the rules —

and the rules, not the name, are what section 3 sets out in full. Judge the

configuration by those.

• Hook status: installed and configured.
• Log status: no events recorded yet.
• Signed audit log: enabled.
• SIEM forwarding: not detected (forwarders are configured in code; see docs/forwarders.md).

2. Control Matrix

This table maps each control Aigis implements to the major security and AI-governance frameworks. ISO/IEC 27001 item numbers are listed as "supports evidence for" — Aigis is a control implementation, not a certification body, and does not guarantee compliance.

Two things to know before reading the table. First, the IDs in the *AI Business Operator GL* column (GL-*, SEC-*, APPI-*) are defined by Aigis, derived from the guideline text — they are not official clause numbers, so asking which guideline clause GL-POISON-01 refers to has no answer outside this repository. The requirement text behind each ID lives in aigis/compliance.py. Second, every mapping here is self-assessed: no third party has reviewed it, and the list contains no partial or uncovered entries — so read it as a statement of what we implement, not as a measured coverage figure.

What Aigis does NOT cover

For an honest scope boundary, the following areas are out of scope for Aigis and must be handled by other controls (your existing security tooling and operational processes).

• Model training / fine-tuning safety — Aigis does not train or align models.
• Content moderation policy decisions — Aigis flags categories but does not define your acceptable-use policy.
• Network-layer DLP — egress filtering at the network boundary is your existing CASB/proxy's job.
• Endpoint security (EDR/antivirus) — Aigis governs the agent, not the host machine.
• Claude Code's own cloud-side processing — prompts sent to Anthropic are governed by Anthropic's terms, not by Aigis.
• Identity and access management — user authentication and SSO remain your IdP's responsibility.

3. Policy Snapshot

Policy currently in force: Aigis Default Policy (v1.0). Default decision when no rule matches: allow.

Rules (human-readable)

Policy file (literal YAML)

The following is the verbatim policy file under version control.

# Aigis Policy: Aigis Default Policy
# Generated by Aigis v0.3.0

name: "Aigis Default Policy"
version: "1.0"
default_decision: allow

rules:
  - id: dangerous_commands
    action: "shell:exec"
    target: "rm -rf *"
    decision: deny
    reason: "Recursive forced deletion is blocked"

  - id: dangerous_format
    action: "shell:exec"
    target: "*mkfs*"
    decision: deny
    reason: "Filesystem format commands are blocked"

  - id: dangerous_dd
    action: "shell:exec"
    target: "*dd if=*"
    decision: deny
    reason: "Raw disk operations are blocked"

  - id: sudo_commands
    action: "shell:exec"
    target: "sudo *"
    decision: review
    reason: "Privilege escalation requires review"

  - id: env_file_protection
    action: "file:write"
    target: ".env*"
    decision: deny
    reason: "Environment files are protected from modification"

  - id: secrets_dir_protection
    action: "file:*"
    target: "*secrets*"
    decision: review
    reason: "Access to secrets directories requires review"

  - id: ssh_key_protection
    action: "file:*"
    target: "*.ssh/*"
    decision: deny
    reason: "SSH key access is blocked"

  - id: credentials_protection
    action: "file:write"
    target: "*credentials*"
    decision: deny
    reason: "Credential files are protected"

  - id: pipe_to_shell
    action: "shell:exec"
    target: "*| bash*"
    decision: deny
    reason: "Piping remote content to shell is blocked"

  - id: pipe_to_sh
    action: "shell:exec"
    target: "*| sh*"
    decision: deny
    reason: "Piping remote content to shell is blocked"

  - id: git_force_push
    action: "shell:exec"
    target: "*--force*"
    decision: deny
    reason: "Force push is blocked"

  - id: git_push_review
    action: "shell:exec"
    target: "git push*"
    decision: review
    reason: "Git push requires review"

  - id: agent_spawn_review
    action: "agent:spawn"
    target: "*"
    decision: review
    reason: "Spawning sub-agents requires review"

  - id: llm_prompt_scan
    action: "llm:prompt"
    target: "*"
    decision: allow
    reason: "LLM prompts are scanned by Aigis's detection engine"

  - id: risk_threshold_critical
    action: "*"
    target: "*"
    decision: deny
    reason: "Critical-risk content detected by Aigis scan engine"
    conditions:
      risk_above: 80

  - id: risk_threshold_medium
    action: "*"
    target: "*"
    decision: review
    reason: "Suspicious content detected by Aigis scan engine"
    conditions:
      risk_above: 40

4. Audit Log Evidence

Where logs live

Aigis keeps audit logs in three tiers (all append-only JSONL, one event per line):

• Local logs: .aigis\logs (per-project, developer-visible)
• Global logs: ~/.aigis/global/ (cross-project, for audit / CISO)
• Alert archive: ~/.aigis/alerts/ (deny / review events, permanent)

Current state: local logs are not yet created,

with 0 events in the last 7 days and 0 in 30 days.

Event schema (JSONL fields)

Each event is recorded as an aigis.activity.ActivityEvent with these fields:

• action
• target
• agent_type
• user_id
• session_id
• event_type
• cwd
• project_name
• details
• risk_score
• risk_level
• matched_rules
• remediation_hints
• owasp_refs
• policy_decision
• policy_rule_id
• timestamp
• event_id
• autonomy_level
• delegation_chain
• estimated_cost
• memory_scope
• suggested_fix
• fix_applied

Retention / rotation

• Full logs are retained for 60 days by default, then auto-rotated

(compressed or deleted).

• Alert logs (~/.aigis/alerts/) are kept permanently and never deleted.
• Run rotation/compression with: aigis maintenance

Tamper-evidence design

The signed audit log (aigis.audit.SignedAuditLog) does two things per entry:

1. HMAC-SHA256 signature — every field of the entry is canonicalised to

JSON and signed with a secret key. The signature depends on the entry's

content, so changing a single byte fails signature verification.

2. Hash chain — each entry stores the SHA-256 hash of the previous entry

(prev_hash), so deleting, reordering, or inserting entries is detectable.

Integrity is checked with four tests: signature, chain, sequence, and

timestamp ordering.

Verify command:

aigis audit verify

Use --log PATH to point at a specific log file and --json for a

machine-readable result. Use aigis audit status for a quick health check.

Current state: signed audit log is

enabled.

Key management — read this before relying on tamper-evidence

The HMAC key is resolved in this order (see aigis/audit/signed_log.py):

1. An explicit secret_key supplied by the caller.

2. An existing key file at .aigis/audit_key.

3. Otherwise a fresh key is generated (secrets.token_hex(32)) and written there.

What this means for a reviewer. In the default configuration the signing key

sits on the same machine as the agent and the logs, owned by the same user. The

signature therefore detects tampering by anything *other than* the log's own

author — a later process, another user, file corruption. It does not detect

the author editing an entry and re-signing it, because they hold the key.

If your threat model includes the developer whose activity is being recorded —

which is usually the reason an audit trail exists at all — combine the signed log

with at least one of the following:

• SIEM forwarding (next section). Events mirrored to Splunk, Sentinel, Elastic,

or Datadog land outside the developer's reach. This is the strongest option

available today, and it requires no change to Aigis.

• An externally-held key. Pass secret_key from a secret manager the developer

cannot read, so local forgery is not possible.

• Off-box export of ~/.aigis/alerts/ to storage the developer cannot write to.

One platform note: the key file is set to 0600 on POSIX, but Windows does not

enforce POSIX permissions — set NTFS ACLs explicitly there.

SIEM forwarding

Events can optionally be forwarded to an external SIEM (Elastic Common Schema,

over HTTP). Forwarding is non-blocking and never delays an agent tool call. A

PII redactor can run before any event leaves the process. See

docs/forwarders.md. Current state: not detected (forwarders are configured in code; see docs/forwarders.md).

5. Incident Runbook

What happens when Aigis blocks an action

A Claude Code *PreToolUse* hook runs on every tool call. When Aigis denies

a request, the hook exits with code 2 and Claude Code aborts that tool

execution. The reason (the matched policy rule ID, and the risk score where

relevant) is printed to standard error and simultaneously written to the

audit log.

The hook is fail-closed: if it cannot reach a decision — unparseable

input, Aigis not installed, an exception during scanning — it blocks on the

safe side.

Severity levels

Triage steps

1. List recent alerts: aigis logs --alerts

2. Inspect the event details (action, target, matched rule, risk score).

3. Verify audit-log integrity: aigis audit verify

4. If a legitimate action was blocked, follow "Reporting false positives" below.

5. If this looks like an attack, report it using the escalation template.

Escalation template

Subject: [Aigis] {severity} — detected {rule_id}

When: {ISO-8601 timestamp}
Project / host: {project name / hostname}
User: {user_id}
Action: {action} Target: {target}
Risk score: {score}  Decision: {decision}
Matched rule: {rule_id}
Audit-log verification: {result of `aigis audit verify`}

First responder: [TO FILL: first responder name]
Escalate to: security@example.com

Reporting false positives

1. Capture the exact blocked input/action (aigis logs --alerts --json).

2. Reproduce by re-scanning the input: aigis scan "<input>"

3. If it is genuinely legitimate, adjust the policy (see below).

4. Record the adjustment in the commit message for the review trail.

Updating the policy

• Inspect the current policy: aigis policy show
• Edit aigis-policy.yaml to add or adjust rules.
• Validate: aigis policy check
• Version-control the change and apply it with sign-off from

[TO FILL: approver / role].

6. Rollout Plan

We recommend introducing Aigis in three phases to limit risk while validating

it in real use. Each phase ends with a review gate that decides whether to

proceed to the next.

Phase 1: Pilot (2 weeks)

Scope: [TO FILL: pilot team / project]

• ☐ Confirm the pilot team and scope
• ☐ Install the hook with aigis init --agent claude-code
• ☐ Verify the install with aigis doctor
• ☐ Run the default policy for two weeks; collect blocks, reviews, and false positives
• ☐ Review status via aigis logs --alerts and the weekly report
• ☐ Tune the policy in response to false positives

Review gate 1: Is the false-positive rate acceptable? Were there any

serious block events? Approver: [TO FILL: phase-1 approver]

Phase 2: Expand

• ☐ Finalise the pilot-tuned policy as the department standard
• ☐ Expand to [TO FILL: next teams / departments]
• ☐ Enable the signed audit log
• ☐ Configure SIEM forwarding if required (docs/forwarders.md)
• ☐ Fold the incident runbook into operations

Review gate 2: Is audit-log integrity verifiable (aigis audit verify)?

Is the operational load reasonable? Approver:

[TO FILL: phase-2 approver]

Phase 3: Organisation default

• ☐ Make Aigis the standard for all Claude Code use
• ☐ Establish the approval flow for policy changes
• ☐ Schedule periodic policy reviews (e.g. quarterly)
• ☐ Build pack regeneration into audit / compliance reporting

Review gate 3: Is the governance process sustainable?

Approver: [TO FILL: phase-3 approver]

_Regenerate this pack whenever the policy changes (it can run in CI), so the

documents you submit to IT always reflect the live posture._

1. エグゼクティブサマリ

組織: Example Corp（サンプル株式会社）

提出先: 【要記入: 情報システム部門】

セキュリティ窓口: security@example.com

生成日時: 2026-08-16T15:03:20.847173+00:00（Aigis v1.2.0）

Claude Codeとは

Claude CodeはAnthropic社が提供するコマンドライン型のコーディングエージェントです。

ファイルの読み書き、シェルコマンドの実行、Webコンテンツの取得を行い、外部ツール

（Model Context Protocolサーバーを含む）を呼び出して、ソフトウェア開発タスクを

自律的に遂行します。開発者の実機上で実際の操作を実行するため、統制のない導入は

運用・セキュリティ上の重大なリスクとなり得ます。

Aigisが付加するもの

Aigisは、エージェントと、それが実行しようとする操作との間に位置する、ゼロ依存の

オープンソース・ガードレール層です。情報システム部門が拠り所とできる、次の3点を

提供します。

1. 決定論的な実行前ガードレール。 Claude Codeの *PreToolUse* フックが、すべての

ツール呼び出しを捕捉します。Aigisはリクエストを検査し、貴社のポリシーに照らして

評価し、操作が実行される前に「許可／レビュー／拒否」を返します。判定はルール

ベースで再現可能であり、モデルが自分自身を確率的に判定するものではありません。

2. 改ざん検知が可能な監査ログ。 すべての判定は追記専用のJSONLログに記録されます。

署名付き版（HMAC-SHA256＋ハッシュチェーン）により、事後の削除・改ざんを検知できます。

3. 組織が保有するポリシー。 ポリシーはリポジトリ内の可読なファイルであり、他の

コードと同様にレビューおよびバージョン管理が可能です。

Aigisは完全にローカルで動作し、新たな実行時依存関係を追加しません。プロンプトや

コードを外部に送信することはなく、エージェントが貴社の端末上で行える操作を統制します。

本パックの内容

• コントロールマトリクス — Aigisのコントロールを、ISO/IEC 27001:2022 附属書A、

NIST AI RMF、OWASP LLM Top 10、および経済産業省・総務省「AI事業者ガイドライン

v1.2」へマッピングしたもの。あわせて「Aigisが対象としない範囲」を明示します。

• ポリシースナップショット — 現在適用中のポリシーを、平易な説明と実際のYAMLで提示します。
• 監査ログの証跡 — ログの保存場所、スキーマ、保持期間、改ざん検知の設計、整合性

検証コマンドを記載します。

• インシデント対応手順 — Aigisが操作をブロックした際の流れ、トリアージ、エスカ

レーション、誤検知の報告方法を記載します。

• 展開計画 — レビューゲートを備えた3段階のパイロット導入テンプレートです。

現状の稼働状況

• ポリシープロファイル: Aigis Default Policy（v1.0）、ルール16件

— 拒否10件、レビュー5件、許可1件。

どのルールにも一致しない場合の既定判定: allow。

承認判断の前にお読みください。 本ルールセットは拒否リスト方式です。既知の

危険な操作（再帰的削除、ローディスク書き込み、認証情報やSSH鍵へのアクセス、

ダウンロード内容のシェルへのパイプ等）を列挙して止め、それ以外は通します。ls すら

実行できないエージェントは実用に耐えないためです。したがって上記の既定判定は

**設計上の fail-open であり、見落としではありません。つまり、誰もルールを書いていない

操作は実行されます。** 「明示的に許可されたもの以外は拒否する」姿勢が貴社の審査要件で

ある場合は、aigis-policy.yaml で default_decision: deny を設定し、業務に必要な

操作を許可ルールとして列挙する必要があります。これは相応の作業量を伴いますが、

fail-closed 構成の正直な対価です。

上記のポリシー名はポリシーファイル自体に由来します。aigis profile build で

生成した場合、その背後にある capability の組み合わせがルールを決定しており、

実際のルールは第3章に全文が掲載されています。名前ではなく、そのルールで

構成をご判断ください。

• フックの状態: 導入・設定済み。
• ログの状態: まだイベントは記録されていません。
• 署名付き監査ログ: 有効。
• SIEM転送: not detected (forwarders are configured in code; see docs/forwarders.md)。

2. コントロールマトリクス

本表は、Aigisが実装する各コントロールを、主要なセキュリティ・AIガバナンスフレームワークへ対応付けたものです。ISO/IEC 27001の項番は「証跡を補強するもの（supports evidence for）」として記載しており、Aigisが認証や準拠を保証するものではありません。

表を読む前に知っておいていただきたい点が2つあります。 1つ目は、「AI事業者GL v1.2」列のID（GL-* / SEC-* / APPI-*）はAigisが独自に定義したもので、ガイドライン本文から要件を抽出して番号を振ったものです。ガイドラインの公式項番ではないため、GL-POISON-01 がガイドラインのどの条項に当たるかという問いには、本リポジトリの外では答えがありません。各IDの要件文は aigis/compliance.py に記載しています。2つ目は、本表の対応付けはすべて自己評価であり、第三者のレビューを受けていないことです。部分対応・未対応の項目が1件も存在しないため、測定されたカバレッジ率ではなく、「何を実装しているかの表明」として読んでください。

Aigisが対象としない範囲

正直な範囲設定のため、Aigisが対象としない領域を明示します。これらは別の管理策（既存のセキュリティ製品・運用体制）で対応する必要があります。

• モデルの学習・ファインチューニングの安全性 — Aigisはモデルの学習やアライメントを行いません。
• コンテンツモデレーションのポリシー判断 — Aigisはカテゴリを検知しますが、貴社の利用規約（許容利用方針）の定義は行いません。
• ネットワーク層のDLP — ネットワーク境界での外向き通信フィルタリングは、既存のCASB／プロキシの役割です。
• エンドポイントセキュリティ（EDR／アンチウイルス） — Aigisはエージェントを統制しますが、ホスト端末自体は対象外です。
• Claude Code自体のクラウド側処理 — Anthropicへ送信されるプロンプトはAnthropicの規約に従うものであり、Aigisの統制対象外です。
• ID・アクセス管理 — ユーザー認証やSSOは引き続き貴社のIdP（ID基盤）の責任範囲です。

3. ポリシースナップショット

現在適用中のポリシー: Aigis Default Policy（v1.0）。どのルールにも一致しない場合の既定判定は allow です。

ルール一覧（可読形式）

ポリシーファイル（実体・YAML）

以下は、リポジトリで管理されている実際のポリシーファイルの全文です。

# Aigis Policy: Aigis Default Policy
# Generated by Aigis v0.3.0

name: "Aigis Default Policy"
version: "1.0"
default_decision: allow

rules:
  - id: dangerous_commands
    action: "shell:exec"
    target: "rm -rf *"
    decision: deny
    reason: "Recursive forced deletion is blocked"

  - id: dangerous_format
    action: "shell:exec"
    target: "*mkfs*"
    decision: deny
    reason: "Filesystem format commands are blocked"

  - id: dangerous_dd
    action: "shell:exec"
    target: "*dd if=*"
    decision: deny
    reason: "Raw disk operations are blocked"

  - id: sudo_commands
    action: "shell:exec"
    target: "sudo *"
    decision: review
    reason: "Privilege escalation requires review"

  - id: env_file_protection
    action: "file:write"
    target: ".env*"
    decision: deny
    reason: "Environment files are protected from modification"

  - id: secrets_dir_protection
    action: "file:*"
    target: "*secrets*"
    decision: review
    reason: "Access to secrets directories requires review"

  - id: ssh_key_protection
    action: "file:*"
    target: "*.ssh/*"
    decision: deny
    reason: "SSH key access is blocked"

  - id: credentials_protection
    action: "file:write"
    target: "*credentials*"
    decision: deny
    reason: "Credential files are protected"

  - id: pipe_to_shell
    action: "shell:exec"
    target: "*| bash*"
    decision: deny
    reason: "Piping remote content to shell is blocked"

  - id: pipe_to_sh
    action: "shell:exec"
    target: "*| sh*"
    decision: deny
    reason: "Piping remote content to shell is blocked"

  - id: git_force_push
    action: "shell:exec"
    target: "*--force*"
    decision: deny
    reason: "Force push is blocked"

  - id: git_push_review
    action: "shell:exec"
    target: "git push*"
    decision: review
    reason: "Git push requires review"

  - id: agent_spawn_review
    action: "agent:spawn"
    target: "*"
    decision: review
    reason: "Spawning sub-agents requires review"

  - id: llm_prompt_scan
    action: "llm:prompt"
    target: "*"
    decision: allow
    reason: "LLM prompts are scanned by Aigis's detection engine"

  - id: risk_threshold_critical
    action: "*"
    target: "*"
    decision: deny
    reason: "Critical-risk content detected by Aigis scan engine"
    conditions:
      risk_above: 80

  - id: risk_threshold_medium
    action: "*"
    target: "*"
    decision: review
    reason: "Suspicious content detected by Aigis scan engine"
    conditions:
      risk_above: 40

4. 監査ログの証跡

ログの保存場所

Aigisは監査ログを3階層で保持します（いずれも追記専用のJSONL形式、1行1イベント）。

• ローカルログ: .aigis\logs（プロジェクト単位、開発者が確認可能）
• グローバルログ: ~/.aigis/global/（全プロジェクト横断、監査・CISO向け）
• アラート保管: ~/.aigis/alerts/（拒否・レビューイベントを恒久保存）

現状: ローカルログは未生成、

直近7日間で0件、30日間で0件を記録しています。

イベントスキーマ（JSONLフィールド）

各イベントは aigis.activity.ActivityEvent として記録され、以下のフィールドを持ちます。

• action
• target
• agent_type
• user_id
• session_id
• event_type
• cwd
• project_name
• details
• risk_score
• risk_level
• matched_rules
• remediation_hints
• owasp_refs
• policy_decision
• policy_rule_id
• timestamp
• event_id
• autonomy_level
• delegation_chain
• estimated_cost
• memory_scope
• suggested_fix
• fix_applied

保持・ローテーション

• 完全ログは既定で60日間保持し、それ以降は自動でローテーション（圧縮または削除）されます。
• アラートログ（~/.aigis/alerts/）は恒久保存され、削除されません。
• ローテーション・圧縮は次のコマンドで実行します: aigis maintenance

改ざん検知の設計

署名付き監査ログ（aigis.audit.SignedAuditLog）は、各エントリに対して次を行います。

1. HMAC-SHA256署名 — 各エントリの全フィールドを正準JSON化し、秘密鍵で署名します。

署名はそのエントリの内容に依存するため、1バイトでも改変すれば署名検証に失敗します。

2. ハッシュチェーン — 各エントリは直前エントリのSHA-256ハッシュ（prev_hash）を保持

します。これにより、エントリの削除・並べ替え・挿入が検知可能になります。

整合性は次の4チェックで検証されます: 署名・チェーン・連番・タイムスタンプ順序。

検証コマンド:

aigis audit verify

--log PATH でログファイルを指定でき、--json で機械可読な結果を出力します。

状態確認には aigis audit status を使用します。

現状: 署名付き監査ログは有効です。

鍵の管理 — 改ざん検知を信頼する前に確認すること

HMAC鍵は次の順序で解決されます（aigis/audit/signed_log.py）。

1. 呼び出し側が明示的に渡した secret_key

2. 既存の鍵ファイル .aigis/audit_key

3. いずれも無ければ新規生成（secrets.token_hex(32)）して同ファイルに保存

審査する側が知っておくべきこと。 既定構成では、署名鍵はエージェントとログと

同じマシン上に、同じユーザー権限で置かれます。したがって署名が検知できるのは

「ログを書いた本人以外」による改変です — 後続プロセス、別ユーザー、ファイル破損。

本人がエントリを書き換えて再署名した場合は検知できません。 鍵を本人が持って

いるからです。

記録対象である開発者本人を脅威モデルに含める場合 — 監査ログを置く理由は通常

そこにあります — 署名ログを次のいずれかと組み合わせてください。

• SIEM転送（次節）。Splunk / Sentinel / Elastic / Datadog に複製されたイベントは

開発者の手が届かない場所に残ります。現時点で最も強い選択肢で、Aigis側の変更は

不要です。

• 外部で保持する鍵。 開発者が読めないシークレットマネージャから secret_key を

渡せば、ローカルでの偽造ができなくなります。

• ~/.aigis/alerts/ の外部エクスポート。 開発者が書き込めない保管先へ定期的に出す。

プラットフォーム注記: 鍵ファイルはPOSIXでは 0600 を設定しますが、Windowsは

POSIX権限を強制しません。Windows環境ではNTFS ACLを明示的に設定してください。

SIEM転送

イベントは任意で外部SIEMへ転送できます（Elastic Common Schema形式、HTTP）。転送は

非ブロッキングで、エージェントのツール呼び出しを遅延させません。送信前に個人情報の

墨消し（Redactor）を実行できます。詳細は docs/forwarders.md を参照してください。

現状: not detected (forwarders are configured in code; see docs/forwarders.md)。

5. インシデント対応手順

Aigisが操作をブロックしたとき

Claude Codeの *PreToolUse* フックがツール呼び出しごとに動作します。Aigisがリクエストを

拒否（deny）した場合、フックは終了コード 2 を返し、Claude Codeはそのツール実行を

中止します。理由（一致したポリシールールID、必要に応じてリスクスコア）が標準エラー出力に

表示され、同時に監査ログへ記録されます。

フックはフェイルクローズ（fail-closed）設計です。入力の解析失敗、Aigis未導入、スキャン

時の例外など、判定できない事象が発生した場合は、安全側に倒してブロックします。

重大度レベル

トリアージ手順

1. 直近のアラートを確認します: aigis logs --alerts

2. 該当イベントの詳細（アクション・対象・一致ルール・リスクスコア）を確認します。

3. 監査ログの整合性を検証します: aigis audit verify

4. 正当な操作が誤ってブロックされた場合は、下記「誤検知の報告」に従います。

5. 攻撃の可能性がある場合は、下記エスカレーションテンプレートで報告します。

エスカレーションテンプレート

件名: [Aigis] {重大度} — {ルールID} を検知

発生日時: {ISO-8601タイムスタンプ}
プロジェクト / 端末: {プロジェクト名 / ホスト名}
利用者: {ユーザーID}
アクション: {action} 対象: {target}
リスクスコア: {score}  判定: {decision}
一致ルール: {rule_id}
監査ログ検証結果: {aigis audit verify の結果}

一次対応: 【要記入: 一次対応者名】
エスカレーション先: security@example.com

誤検知（False Positive）の報告

1. ブロックされた具体的な入力／操作を記録します（aigis logs --alerts --json）。

2. 当該入力を再スキャンして再現します: aigis scan "<入力>"

3. 正当な操作であると確認できた場合は、ポリシーを調整します（下記参照）。

4. 調整内容は、レビュー記録のためコミットメッセージに残します。

ポリシーの更新

• 現在のポリシーを確認: aigis policy show
• aigis-policy.yaml を編集してルールを追加・調整します。
• 妥当性を確認: aigis policy check
• 変更はバージョン管理し、【要記入: 承認者・役割】 の承認を経て反映します。

6. 展開計画

Aigisの導入は、リスクを抑えつつ実運用での妥当性を確認するため、3段階で進めることを

推奨します。各フェーズの終わりにレビューゲートを設け、次フェーズへの移行可否を判断します。

フェーズ1: パイロット（2週間）

対象: 【要記入: パイロットチーム・プロジェクト】

• ☐ パイロット対象チームと範囲を確定する
• ☐ aigis init --agent claude-code でフックを導入する
• ☐ aigis doctor で導入状態を確認する
• ☐ 既定ポリシーで2週間運用し、ブロック・レビュー・誤検知を収集する
• ☐ aigis logs --alerts と週次レポートで状況を確認する
• ☐ 誤検知に応じてポリシーを調整する

レビューゲート1: 誤検知率は許容範囲か。重大なブロック事象はなかったか。

承認者: 【要記入: フェーズ1承認者】

フェーズ2: 拡大

• ☐ パイロットで調整したポリシーを部門全体の標準として確定する
• ☐ 対象を 【要記入: 次の対象チーム・部門】 へ拡大する
• ☐ 署名付き監査ログを有効化する
• ☐ 必要に応じてSIEM転送を構成する（docs/forwarders.md）
• ☐ インシデント対応手順を運用に組み込む

レビューゲート2: 監査ログの整合性は検証可能か（aigis audit verify）。

運用負荷は妥当か。承認者: 【要記入: フェーズ2承認者】

フェーズ3: 全社標準

• ☐ Aigisを全社のClaude Code利用の標準とする
• ☐ ポリシー変更の承認フローを確立する
• ☐ 定期的なポリシーレビュー（四半期ごと等）を計画する
• ☐ 監査・コンプライアンス報告に本パックの再生成を組み込む

レビューゲート3: ガバナンス体制は継続的に運用可能か。

承認者: 【要記入: フェーズ3承認者】

_本パックはポリシー変更時に再生成することを推奨します（CIに組み込み可能）。

最新の稼働状況を反映した文書を、常に情報システム部門へ提出できます。_