บันทึกการตรวจสอบ AI Agent: เส้นทางที่ไม่เปลี่ยนแปลง การปฏิบัติตาม และนิติวิทยาศาสตร์

บันทึกการตรวจสอบ AI Agent คือการบันทึกแบบ append-only ที่ไม่เปลี่ยนแปลงของทุกการกระทำที่ agent ดำเนินการ โดยเขียนก่อนที่การดำเนินการจะเสร็จสิ้น ระบุตัวตนด้วยการเข้ารหัสลับให้กับ agent และ timestamp ที่เฉพาะเจาะจง และแตกต่างจากข้อมูล observability ตรงที่มันพิสูจน์ต่อผู้ตรวจสอบหรือหน่วยงานกำกับดูแลว่าเกิดอะไรขึ้น แทนที่จะแสดงสุขภาพระบบปัจจุบัน มาตรฐานการปฏิบัติตามสามฉบับกำหนดให้มีสิ่งนี้: SOC 2 Type II CC7.2 (เก็บรักษาขั้นต่ำ 1 ปี), GDPR มาตรา 30 (บันทึกกิจกรรมการประมวลผล) และ OWASP LLM06:2025 (เส้นทางการตรวจสอบที่ไม่เปลี่ยนแปลงเป็นหนึ่งในสี่การบรรเทาผลที่จำเป็น)

บันทึกการตรวจสอบ AI Agent คือการบันทึกแบบ append-only ที่ไม่เปลี่ยนแปลงของทุกการกระทำของ agent: ทุกการเรียกใช้เครื่องมือ ทุกการเปลี่ยนสถานะ ทุกการเข้าถึงข้อมูลรับรอง โดยเขียนก่อนที่การดำเนินการจะเสร็จสิ้น ระบุตัวตนให้กับ agent_id และ timestamp เฉพาะ และได้รับการปกป้องจากการแก้ไขโดย agent หรือกระบวนการปลายน้ำใด ๆ เพื่อให้ผู้ตรวจสอบการปฏิบัติตาม นักสืบความปลอดภัย และหน่วยงานกำกับดูแลสามารถตรวจสอบได้อย่างอิสระว่า agent ทำอะไร เมื่อไหร่ และด้วยพารามิเตอร์ใด โดยไม่ต้องพึ่งพารายงานของ agent เอง

บันทึกการตรวจสอบเทียบกับ Observability: มาตรฐานหลักฐานสองประเภทที่แตกต่างกัน

สิ่งที่ข้อมูล Observability พิสูจน์ไม่ได้

Observability ตอบคำถาม "ระบบกำลังทำงานอยู่ตอนนี้ไหม?" ส่วนบันทึกการตรวจสอบตอบคำถาม "agent X ทำอะไรในวันที่ 15 มีนาคม เวลา 14:32 น. ด้วยพารามิเตอร์ใด และผลลัพธ์คืออะไร?" นี่คือมาตรฐานหลักฐานที่แตกต่างกันซึ่งมีข้อกำหนดด้านการจัดเก็บ ระยะเวลาการเก็บรักษา และสถานะทางกฎหมายที่แตกต่างกัน

ข้อมูล Observability มักถูกสุ่มตัวอย่าง (ไม่ใช่ทุก event) รวมกลุ่ม (events แต่ละรายการถูกสรุปเป็น metrics) และเก็บรักษาในระยะสั้น (30-90 วันเป็นมาตรฐานสำหรับ metrics และ traces) มันสามารถบอกคุณได้ว่า p99 latency สัปดาห์ที่แล้ววันอังคารคือ 2.3 วินาที แต่ไม่สามารถบอกได้ว่า agent researcher-01 เรียกใช้ http_request ด้วย url=https://api.external.com/export?user_id=4821 เมื่อ 14:32:07 UTC

บันทึกการตรวจสอบต้องเป็น events แต่ละรายการ (ไม่ใช่การรวมกลุ่ม) ครบถ้วน (ทุกการเรียกใช้รวมถึงที่ล้มเหลวและถูกปฏิเสธ) และเก็บรักษาในระยะยาว (SOC 2 กำหนดขั้นต่ำ 1 ปี; บันทึก GDPR มักเก็บตลอดระยะเวลาสัญญาบวกระยะเวลาการจำกัดที่บังคับใช้)

ความล้มเหลวในการตรวจสอบที่พบบ่อยที่สุดในการใช้งาน agent ในโปรดักชัน: ทีมนำเสนอ dashboards observability (Datadog, Grafana) ต่อผู้ตรวจสอบ SOC 2 เป็นหลักฐานการปฏิบัติตาม CC7.2 ผู้ตรวจสอบปฏิเสธเพราะ dashboards observability ไม่สามารถแสดงบันทึก events แต่ละรายการ ไม่สามารถพิสูจน์ความครบถ้วน และไม่สามารถพิสูจน์ความไม่เปลี่ยนแปลงได้ SOC 2 CC7.2 กำหนดให้มีบันทึก events แต่ละรายการที่ agent ไม่สามารถแก้ไขได้

คุณสมบัติสี่ประการของการบันทึกระดับการตรวจสอบ

ก่อนการดำเนินการ: รายการบันทึกถูกเขียนก่อนที่การกระทำจะเสร็จสิ้น timestamp อยู่ก่อนผลลัพธ์ นี่มีความสำคัญด้านนิติวิทยาศาสตร์: agent ที่สามารถเขียนรายการบันทึกหลังเกิดเหตุสามารถเขียนรายการเท็จหรือละเว้นรายการของการกระทำที่ต้องการซ่อนได้ การบันทึกก่อนการดำเนินการหมายความว่ารายการมีอยู่ไม่ว่าการกระทำจะสำเร็จ ล้มเหลว หรือถูกขัดจังหวะ

ความไม่เปลี่ยนแปลง: บันทึกไม่สามารถแก้ไขหรือลบได้โดย agent ผู้ดำเนินการ หรือกระบวนการอัตโนมัติใด ๆ WORM storage (เขียนครั้งเดียว อ่านได้หลายครั้ง) หรือ cryptographic hash chains ให้ความไม่เปลี่ยนแปลงที่ระดับ infrastructure ความไม่เปลี่ยนแปลงที่ระดับแอปพลิเคชัน ("agent ได้รับคำสั่งไม่ให้ลบบันทึก") ไม่เพียงพอสำหรับวัตถุประสงค์การปฏิบัติตาม; ผู้ตรวจสอบต้องการความไม่เปลี่ยนแปลงที่ระดับ infrastructure

ความครบถ้วน: ต้องบันทึกทุกการเรียกใช้รวมถึงที่ล้มเหลว ถูกปฏิเสธ ถูกจำกัดอัตราการใช้งาน และส่งคืนข้อผิดพลาด บันทึกที่บันทึกเฉพาะการกระทำที่สำเร็จไม่ครบถ้วนสำหรับวัตถุประสงค์ด้านนิติวิทยาศาสตร์; คำถามนิติวิทยาศาสตร์หลังเหตุการณ์มักคือ "agent พยายามทำอะไรและล้มเหลว?" บันทึกการเรียกใช้ที่ถูกปฏิเสธคือหลักฐานหลักของความพยายาม prompt injection

การระบุตัวตน: agent_id, session_id, tool_call_id และ timestamp ของคำขอต้องผูกด้วยการเข้ารหัสลับในเวลาที่เขียน ไม่ใช่ metadata ที่เปลี่ยนแปลงได้ซึ่งสามารถแก้ไขได้ในภายหลัง การระบุตัวตนแบบย้อนหลังไม่ตอบสนองข้อกำหนดของ GDPR มาตรา 30 เพื่อระบุตัวผู้ควบคุมและผู้ประมวลผลที่รับผิดชอบต่อกิจกรรมการประมวลผลแต่ละรายการ

ข้อกำหนดการปฏิบัติตาม: SOC 2, GDPR และ OWASP LLM06

SOC 2 Type II CC7.2: เก็บรักษาขั้นต่ำ 1 ปี

SOC 2 Type II Common Criteria 7.2 (การตรวจสอบระบบ) กำหนดให้บันทึกกิจกรรมระบบและมีบันทึกพร้อมสำหรับการตรวจสอบตลอดระยะเวลาการตรวจสอบ สำหรับระบบ AI Agent:

จำเป็นต้องมีบันทึก events แต่ละรายการ: การเรียกใช้เครื่องมือแต่ละครั้งต้องเป็นรายการบันทึกแยกที่มี agent_id, timestamp, ชื่อเครื่องมือ, พารามิเตอร์ทั้งหมด และผลลัพธ์ metrics รวมกลุ่ม (100 การเรียกใช้เครื่องมือในชั่วโมงที่ผ่านมา) ไม่เป็นไปตาม CC7.2; จำเป็นต้องมีบันทึก events แต่ละรายการเพื่อให้ผู้ตรวจสอบตรวจสอบ events เฉพาะเจาะจงได้

เก็บรักษาขั้นต่ำ 1 ปี: ระยะเวลาการตรวจสอบ SOC 2 Type II มักอยู่ที่ 6 หรือ 12 เดือน บันทึกต้องครอบคลุมระยะเวลาการตรวจสอบทั้งหมด แนวทางปฏิบัติที่ดีที่สุดคือเก็บรักษา 1 ปีบวก buffer (13-14 เดือน)

Agent ไม่สามารถแก้ไขบันทึกของตัวเองได้: ผู้ตรวจสอบ SOC 2 ตรวจสอบโดยเฉพาะว่าหน่วยงานที่รับการตรวจสอบไม่สามารถแก้ไขบันทึกการตรวจสอบของตัวเองได้ Agent ที่สามารถเรียกใช้ API ลบบันทึกจะล้มเหลวในการควบคุมนี้ เส้นทางการตรวจสอบ Zone 2 ของ OpenLegion ถูกเขียนโดย infrastructure ของ mesh ไม่ใช่โค้ด agent; agent ไม่สามารถเข้าถึงเส้นทางการเขียนบันทึกได้

จำเป็นต้องมีหลักฐานการตรวจสอบเป็นระยะ: CC7.2 ยังกำหนดให้มีหลักฐานว่าบันทึกได้รับการตรวจสอบแล้ว: ชั้นการตรวจจับความผิดปกติอัตโนมัติบวกการตรวจสอบด้วยมนุษย์เป็นระยะที่บันทึกไว้ในบันทึกการตรวจสอบ

GDPR มาตรา 30: การกระทำของ Agent บนข้อมูลส่วนบุคคล

GDPR มาตรา 30 กำหนดให้ผู้ควบคุมข้อมูลและผู้ประมวลผลรักษาบันทึกกิจกรรมการประมวลผล สำหรับระบบ AI Agent ทุกการดำเนินการของ agent ที่สัมผัสข้อมูลส่วนบุคคลเป็นกิจกรรมการประมวลผลที่ต้องมีการบันทึก

สิ่งที่ต้องบันทึกสำหรับการปฏิบัติตาม GDPR มาตรา 30:

Agent_id และการระบุตัวผู้ควบคุม: ใครรับผิดชอบกิจกรรมการประมวลผลนี้?
วัตถุประสงค์ของการประมวลผล: ทำไม agent ถึงเข้าถึงข้อมูลส่วนบุคคลนี้?
ประเภทของข้อมูลส่วนบุคคล: agent เข้าถึงข้อมูลประเภทใด?
ผู้รับ: ระบบหรือ agent ภายนอกใดได้รับข้อมูล?
ฐานทางกฎหมาย: ฐานทางกฎหมาย GDPR ใดที่บังคับใช้?
ระยะเวลาการเก็บรักษาหรือเกณฑ์: เมื่อใดที่ข้อมูลจะถูกลบ?

บันทึกต้องพร้อมให้แก่หน่วยงานกำกับดูแลตามคำขอ ค่าปรับสำหรับการไม่ปฏิบัติตามมาตรา 30 อาจสูงถึง 10 ล้านยูโร หรือ 2% ของรายได้ต่อปีทั่วโลก แล้วแต่ว่าจำนวนใดจะสูงกว่า

ช่องว่างด้านการปฏิบัติตามที่พบบ่อยที่สุด: บันทึกการตรวจสอบ agent บันทึกชื่อเครื่องมือและพารามิเตอร์ดิบ แต่ไม่ระบุว่าพารามิเตอร์ใดมีข้อมูลส่วนบุคคล บันทึกมาตรา 30 ต้องการการระบุดังกล่าวพร้อมวัตถุประสงค์และฐานทางกฎหมาย

OWASP LLM06:2025: เส้นทางการตรวจสอบที่ไม่เปลี่ยนแปลงที่จำเป็น

OWASP LLM06:2025 (Excessive Agency) ระบุเส้นทางการตรวจสอบที่ไม่เปลี่ยนแปลงเป็นหนึ่งในสี่การบรรเทาผลที่จำเป็นสำหรับ autonomous agents:

การเรียกใช้เครื่องมือทั้งหมดรวมถึงที่ถูกปฏิเสธ: การเรียกใช้ที่ถูกปฏิเสธโดย allowlist ของเครื่องมือ HITL gates หรือ open circuit breakers ต้องปรากฏในเส้นทางการตรวจสอบ การเรียกใช้ที่ถูกปฏิเสธคือหลักฐานหลักของความพยายาม prompt injection และประสิทธิผลของการควบคุมความปลอดภัย

เขียนก่อนที่การดำเนินการจะเสร็จสิ้น: ก่อนการดำเนินการ การบันทึกหลังการดำเนินการอนุญาตให้ agent ข้ามการบันทึกการกระทำที่ดำเนินการแล้วสิ้นสุดก่อนที่จะเขียนบันทึก

บันทึก arguments ทั้งหมด: รายการการตรวจสอบต้องมี arguments การเรียกใช้เครื่องมือทั้งหมด ไม่ใช่แค่ชื่อเครื่องมือ นี่คือฟิลด์ที่ทีมนิติวิทยาศาสตร์ความปลอดภัยใช้ตอบคำถาม "agent เรียกใช้ URL ใด?" และ "ข้อมูลใดถูกส่งต่อไปยัง API ภายนอก?"

ความไม่เปลี่ยนแปลง: agent ไม่ควรสามารถลบหรือแก้ไขบันทึกของตัวเองได้ นี่คือการควบคุมที่ทำให้เส้นทางการตรวจสอบมีประโยชน์สำหรับการสืบสวนนิติวิทยาศาสตร์; หาก agent สามารถแก้ไขเส้นทางได้ การสืบสวนหลังเหตุการณ์ไม่สามารถพึ่งพาได้

เส้นทางการตรวจสอบเป็นการควบคุมการตรวจจับ ไม่ใช่การป้องกัน มันไม่ป้องกันการกระทำที่ไม่ได้รับอนุญาต มันรับรองว่าการกระทำที่ไม่ได้รับอนุญาตสามารถค้นพบได้หลังเกิดเหตุ ทำให้การตอบสนองต่อเหตุการณ์และการรายงานต่อหน่วยงานกำกับดูแลเป็นไปได้

สคีมาบันทึกการตรวจสอบ: สิ่งที่ต้องบันทึกและเมื่อใด

สคีมา OpenTelemetry OTLP Log สำหรับบันทึกการตรวจสอบ Agent

OpenTelemetry OTLP proto v1.0 (กรกฎาคม 2023) ให้โครงสร้างมาตรฐานสำหรับบันทึกการตรวจสอบ agent การใช้ OTLP ช่วยให้การผสาน SIEM โดยไม่ต้องมี parsers แบบกำหนดเองและการเชื่อมโยง distributed traces ผ่าน TraceId และ SpanId

ฟิลด์ OTLP ที่จำเป็นสำหรับบันทึกการตรวจสอบ agent:

{
  "TimeUnixNano": "1719100800000000000",
  "ObservedTimeUnixNano": "1719100800050000000",
  "SeverityNumber": 9,
  "SeverityText": "INFO",
  "Body": {
    "event_type": "tool_call",
    "agent_id": "researcher-01",
    "session_id": "sess_a3f9b2c1",
    "tool_call_id": "tc_7e8d4f12",
    "tool_name": "http_request",
    "arguments": {
      "url": "https://api.example.com/data",
      "method": "POST",
      "headers": {"Authorization": "$CRED{api_key}"},
      "body_hash": "sha256:a4f3b2c1..."
    },
    "result_summary": "HTTP 200, 1842 bytes",
    "execution_status": "success",
    "rejection_reason": null,
    "duration_ms": 312,
    "cost_usd": 0.0042,
    "personal_data_fields": [],
    "credential_handles_used": ["api_key"]
  },
  "Attributes": {
    "agent_id": "researcher-01",
    "session_id": "sess_a3f9b2c1",
    "tool_call_id": "tc_7e8d4f12",
    "tool_name": "http_request",
    "authorization_level": "L2",
    "deployment_env": "prod"
  },
  "TraceId": "4bf92f3577b34da6a3ce929d0e0e4736",
  "SpanId": "00f067aa0ba902b7",
  "Resource": {
    "agent_type": "researcher",
    "agent_version": "0.4.2",
    "deployment_env": "prod"
  }
}

บันทึกฟิลด์สามรายการที่สำคัญต่อการปฏิบัติตาม:

ObservedTimeUnixNano: เวลาที่ pipeline บันทึกได้รับบันทึก แตกต่างจาก TimeUnixNano ความแตกต่างตรวจจับ clock skew และการฉีด logs ย้อนหลัง; รายการบันทึกที่มี ObservedTimeUnixNano ก่อน TimeUnixNano ถูกเขียนก่อน event ที่มันอธิบาย ซึ่งเป็นไปไม่ได้ทางกายภาพและบ่งชี้การปลอมแปลง

arguments.headers ด้วย $CRED{} handles: บันทึกการตรวจสอบบันทึก credential handle ($CRED{api_key}) ไม่ใช่ค่าข้อมูลรับรองที่แก้ไขแล้ว API keys ดิบไม่ปรากฏในบันทึก

personal_data_fields: array ที่ระบุว่าฟิลด์ arguments ใดมีข้อมูลส่วนบุคคลสำหรับการปฏิบัติตาม GDPR มาตรา 30 pipeline บันทึกตรวจสอบฟิลด์นี้เพื่อใช้กฎการเก็บรักษาที่เหมาะสมและสร้างบันทึกมาตรา 30

การทำความสะอาด PII ก่อนเขียนบันทึก

GDPR มาตรา 17 (สิทธิ์การลบ) สร้างความขัดแย้งในการปฏิบัติตาม: บันทึกการตรวจสอบต้องเก็บรักษา 1 ปีหรือมากกว่า (SOC 2) แต่ข้อมูลส่วนบุคคลต้องถูกลบตามคำขอของเจ้าของข้อมูล วิธีแก้ไขคือ pseudonymization: การแทนที่ข้อมูลส่วนบุคคลใน event records ด้วย deterministic hash ก่อนเขียนลงใน immutable log

import hashlib

PSEUDONYMIZATION_SALT = "$CRED{pii_salt}"  # แก้ไขจาก vault; อย่าใส่ในโค้ดโดยตรง

def pseudonymize_args(args: dict, pii_fields: list[str]) -> dict:
    """แทนที่ฟิลด์ PII ด้วยนามแฝง HMAC-SHA256 ก่อนเขียนบันทึก"""
    sanitized = dict(args)
    for field in pii_fields:
        if field in sanitized:
            value = str(sanitized[field])
            pseudonym = hashlib.sha256(
                f"{PSEUDONYMIZATION_SALT}:{value}".encode()
            ).hexdigest()[:16]
            sanitized[field] = f"pii:{pseudonym}"
    return sanitized

นามแฝง deterministic รักษาการเชื่อมโยงนิติวิทยาศาสตร์: รายการบันทึกทั้งหมดที่เกี่ยวข้องกับผู้ใช้รายเดียวกันสร้างนามแฝงเดียวกัน ทำให้การ query นิติวิทยาศาสตร์ทำได้โดยไม่ต้องใช้ตัวระบุดิบ เมื่อได้รับคำขอลบ GDPR ให้หมุน salt; นามแฝงที่มีอยู่ทั้งหมดจะกลายเป็น unlinked จากเจ้าของข้อมูลต้นฉบับอย่างถาวร ตอบสนองมาตรา 17 โดยไม่ต้องลบบันทึกการตรวจสอบ

ระยะเวลาการเก็บรักษาปลอดภัยเริ่มต้น: 3 ปี ครอบคลุมระยะเวลาการตรวจสอบ SOC 2 12 เดือน (มี buffer) ระยะเวลาการจำกัด GDPR ทั่วไป และข้อกำหนดการเก็บรักษาตามสัญญาส่วนใหญ่

การป้องกันการปลอมแปลงและการจัดเก็บที่ไม่เปลี่ยนแปลง

Cryptographic Hash Chains

Hash chain ให้การป้องกันการปลอมแปลงที่ระดับลำดับบันทึก: หาก record ใด ๆ ถูกแก้ไขหรือลบ chain จะขาดและการแก้ไขจะตรวจจับได้

import hashlib, json

class AuditLogChain:
    def __init__(self, previous_hash: str = "genesis"):
        self.previous_hash = previous_hash

    def append(self, record: dict) -> dict:
        """เพิ่ม record ลงใน chain ส่งคืน sealed entry"""
        record_with_prev = {**record, "previous_hash": self.previous_hash}
        serialized = json.dumps(record_with_prev, sort_keys=True).encode()
        current_hash = hashlib.sha256(serialized).hexdigest()
        sealed = {**record_with_prev, "record_hash": current_hash}
        self.previous_hash = current_hash
        return sealed

แต่ละ record มี hash ของ record ก่อนหน้า การแก้ไข record ใด ๆ จะเปลี่ยน hash ของมัน ทำให้ hash ถัดไปทั้งหมดไม่ถูกต้องแบบ cascade ผู้ตรวจสอบตรวจสอบ chain โดยการคำนวณ hash ใหม่จาก record 1 เป็นต้นไป; การขาดใด ๆ บ่งชี้การแก้ไขและตำแหน่งของมัน

Hash chains ตรวจจับการแก้ไขแต่ไม่ป้องกัน ผู้โจมตีที่ควบคุม log storage สามารถสร้าง chain ที่ถูกต้องใหม่บน records ที่แก้ไขโดยคำนวณ hashes ใหม่จากจุดแก้ไขเป็นต้นไป ใช้ WORM storage เพื่อป้องกัน

WORM Storage: AWS S3 Object Lock

AWS S3 Object Lock ในโหมด Compliance ป้องกันการแก้ไขหรือลบ objects ในช่วงระยะเวลาการเก็บรักษาโดยใครก็ตาม รวมถึง root account หรือ AWS support นี่คือความไม่เปลี่ยนแปลงระดับ infrastructure ที่ผู้ตรวจสอบ SOC 2 และนักสืบนิติวิทยาศาสตร์ต้องการ

การประมาณค่าใช้จ่าย: agent ที่ทำงานปานกลางสร้างข้อมูลบันทึกประมาณ 55 GB ต่อปี ที่ $0.023/GB/เดือนบน S3 Standard:

เก็บรักษา 1 ปี: 55 GB x 12 เดือน x $0.023 = ~$15/ปีต่อ agent
เก็บรักษา 3 ปี: 55 GB x 36 เดือน x $0.023 = ~$46/ปีต่อ agent

การกำหนดค่า immutable log storage:

# สร้าง bucket ด้วย Object Lock ที่เปิดใช้งาน (ไม่สามารถปิดใช้งานหลังสร้าง)
aws s3api create-bucket \
  --bucket agent-audit-logs-prod \
  --object-lock-enabled-for-bucket \
  --region us-east-1

# ตั้งค่าการเก็บรักษาเริ่มต้น: โหมด Compliance, 3 ปี
aws s3api put-object-lock-configuration \
  --bucket agent-audit-logs-prod \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {
        "Mode": "COMPLIANCE",
        "Years": 3
      }
    }
  }'

การผสาน SIEM และการวิเคราะห์แบบ real-time

การส่ง Audit Logs ของ Agent ไปยัง SIEM

การผสาน SIEM ให้บริการสองวัตถุประสงค์: การตรวจจับความผิดปกติแบบ real-time (การตรวจจับความพยายาม prompt injection ที่กำลังดำเนินอยู่) และการสืบสวนนิติวิทยาศาสตร์ (การ query historical records หลังเหตุการณ์) สคีมา OTLP ทำให้ทั้งสองเป็นไปได้

SIEM	วิธีการนำเข้า	การประมาณค่าใช้จ่ายสำหรับปริมาณบันทึก agent
Splunk	OTLP Collector -> Splunk HEC	$1.5-3/GB ที่นำเข้า
Elastic SIEM	OTLP Collector -> Logstash	$0.10-0.50/GB (self-hosted)
Microsoft Sentinel	OTLP Collector -> Log Analytics	$2.46/GB ที่นำเข้า
Datadog	OTLP Collector -> Datadog Agent	$0.10/GB (มาตรฐาน)
OpenSearch	OTLP Collector -> OpenSearch	ฟรี (self-hosted)

กฎการตรวจจับ real-time สามกฎที่ต้องกำหนดค่าเมื่อนำเข้า SIEM:

กฎ 1: การเรียกใช้เครื่องมือนอก allowlist: แจ้งเตือนเมื่อ tool_name ในบันทึกการตรวจสอบไม่ปรากฏใน registered tool list ของ agent role แม้แต่การเรียกใช้ที่ถูกปฏิเสธก็ยังทริกเกอร์; การเรียกใช้ที่ถูกปฏิเสธนอก allowlist หมายความว่าการฉีดถูกบล็อก แต่เห็นความตั้งใจของผู้โจมตี

กฎ 2: ความผิดปกติของ credential handle: แจ้งเตือนเมื่อ credential_handles_used มี handle ที่ไม่อยู่ใน approved list ของ agent role สัญญาณการตรวจจับหลักสำหรับการโจมตี credential pivot

กฎ 3: การพุ่งสูงของ rejection rate: แจ้งเตือนเมื่อมากกว่า 20% ของการเรียกใช้เครื่องมือในหน้าต่าง 5 นาทีมี execution_status: rejected บ่งชี้แคมเปญ prompt injection ที่กำลังดำเนินอยู่ซึ่งถูกบล็อกโดยการควบคุมความปลอดภัย

Legal Hold และ eDiscovery

เมื่อเหตุการณ์ที่เกี่ยวข้องกับ agent ทริกเกอร์การดำเนินคดีทางกฎหมายหรือการสืบสวนของหน่วยงานกำกับดูแล legal hold ป้องกันการลบหรือแก้ไขบันทึกตลอดระยะเวลาของคดี

ใน S3 Object Lock ใช้การขยายการเก็บรักษาอย่างชัดเจน:

import boto3
from datetime import datetime, timedelta

s3 = boto3.client('s3')

def apply_legal_hold(bucket: str, prefix: str, hold_until: datetime):
    paginator = s3.get_paginator('list_objects_v2')
    for page in paginator.paginate(Bucket=bucket, Prefix=prefix):
        for obj in page.get('Contents', []):
            s3.put_object_retention(
                Bucket=bucket,
                Key=obj['Key'],
                Retention={
                    'Mode': 'COMPLIANCE',
                    'RetainUntilDate': hold_until
                }
            )

# ใช้ hold 5 ปีกับบันทึกของวันที่เกิดเหตุการณ์
apply_legal_hold(
    bucket='agent-audit-logs-prod',
    prefix='2026/03/15/',
    hold_until=datetime.now() + timedelta(days=1825)
)

การสร้าง eDiscovery: export log records ภายในช่วงวันที่และขอบเขต agent_id เป็น JSON-L พร้อมไฟล์ manifest ที่มี S3 Object Lock retention metadata เป็นหลักฐานการเป็นเจ้าของ

การสืบสวนนิติวิทยาศาสตร์หลังเหตุการณ์ Agent

Timeline นิติวิทยาศาสตร์: การสร้างใหม่ว่า Agent ทำอะไร

หลังเหตุการณ์ความปลอดภัย การสืบสวนนิติวิทยาศาสตร์สร้างลำดับที่แน่นอนของการกระทำ agent ใหม่ รูปแบบ query timeline นิติวิทยาศาสตร์มาตรฐาน:

from datetime import datetime

def build_forensic_timeline(
    agent_id: str,
    session_id: str,
    start_time: datetime,
    end_time: datetime,
    log_store
) -> list[dict]:
    timeline = []
    for record in log_store.query(
        filter={
            "agent_id": agent_id,
            "session_id": session_id,
            "time_range": (start_time, end_time)
        }
    ):
        timeline.append({
            "timestamp": record["TimeUnixNano"],
            "tool": record["Body"]["tool_name"],
            "status": record["Body"]["execution_status"],
            "args_summary": record["Body"]["arguments"],
            "cost_usd": record["Body"]["cost_usd"],
            "rejection_reason": record["Body"].get("rejection_reason"),
            "record_hash": record.get("record_hash"),
        })
    return sorted(timeline, key=lambda r: r["timestamp"])

สี่คำถามที่ timeline นิติวิทยาศาสตร์ควรตอบได้:

Agent ทำอะไร? ลำดับ tool_name รวมถึงการเรียกใช้ที่ถูกปฏิเสธ การเรียกใช้ที่ถูกปฏิเสธแสดงให้เห็นว่า agent พยายามทำอะไรซึ่งการควบคุมความปลอดภัยบล็อก

เข้าถึงข้อมูลใด? ฟิลด์ arguments สำหรับทุกการเรียกใช้เครื่องมือที่เกี่ยวข้องกับบริการภายนอก มีพารามิเตอร์ใดที่ส่งผ่าน? หาก personal_data_fields เต็ม ข้อมูลส่วนบุคคลใดถูกเกี่ยวข้อง?

ใช้ credentials ใด? ฟิลด์ credential_handles_used หาก handle ปรากฏในบริบทที่ไม่คาดหมาย เช่น researcher agent ใช้ publisher's GitHub token นั่นคือการค้นพบด้านนิติวิทยาศาสตร์

ระบบภายนอกส่งคืนอะไร? ฟิลด์ result_summary หาก agent ขโมยข้อมูล HTTP 200, N bytes received คือหลักฐานการขโมยข้อมูลที่สำเร็จ

เอกสาร Chain of Custody

เพื่อให้หลักฐานนิติวิทยาศาสตร์รับได้ในการดำเนินคดีทางกฎหมาย ต้องรักษาเอกสาร chain of custody ใน S3 เปิดใช้งาน S3 access logging สำหรับ bucket บันทึกการตรวจสอบ; แต่ละคำขอ GET สร้างรายการ access log ที่มี IAM identity ของผู้ขอและ timestamp นี่คือบันทึก chain of custody สำหรับบันทึกการตรวจสอบเอง

เมื่อ export บันทึกไปยังบุคคลภายนอก (หน่วยงานกำกับดูแล ผู้ตรวจสอบ ทนายฝ่ายตรงข้าม) ใช้ S3 pre-signed URLs ที่มีการหมดอายุจำกัด (24-48 ชั่วโมง) แทนการแชร์ IAM credentials Pre-signed URL สร้างบันทึกที่จำกัดเวลาว่าเข้าถึง objects ใดและเมื่อไหร่

มุมมองของ OpenLegion

บันทึกการตรวจสอบคือการควบคุมการปฏิบัติตามที่ได้รับการลงทุนน้อยที่สุดในระบบ agent ที่ใช้งานจริง ทีมลงทุนใน tracing, metrics และ dashboards ซึ่งมีคุณค่าสำหรับการดำเนินงาน แต่เลื่อนบันทึกการตรวจสอบออกไปเป็น "สิ่งที่จะเพิ่มในภายหลัง" "ภายหลัง" มาถึงเมื่อผู้ตรวจสอบ SOC 2 ขอบันทึก event แต่ละรายการ 12 เดือน หรือเมื่อหน่วยงานกำกับดูแลขอเอกสาร มาตรา 30 สำหรับ agent ที่ประมวลผลข้อมูลลูกค้าเมื่อหกเดือนที่แล้ว

blackboard ของ OpenLegion เป็น append-only โดยการออกแบบ: ทุก write มีเวอร์ชัน มี timestamp และระบุตัวตนให้กับ agent_id ของผู้เขียน Zone 2 บันทึกทุกการเรียกใช้เครื่องมือก่อนที่การดำเนินการจะเสร็จสิ้น ทั้งสองไม่สามารถแก้ไขได้โดยโค้ด agent การใช้งาน OpenLegion มีโครงสร้างบันทึกก่อนการดำเนินการ ไม่เปลี่ยนแปลง มีการระบุตัวตนตั้งแต่วันแรกที่การปฏิบัติตามต้องการ

การโต้แย้งด้านต้นทุนสำหรับการลงทุนตั้งแต่เนิ่น ๆ: การเพิ่ม immutable audit log ย้อนหลังลงในระบบ agent ที่ใช้งานจริงต้องการการเปลี่ยนแปลงใน tool call pipeline, storage infrastructure และรูปแบบบันทึก โดยปกติคือวิศวกรรม 2-4 สัปดาห์ การสร้างที่ถูกต้องตั้งแต่การใช้งานใช้เวลาหนึ่งถึงสองวัน S3 Object Lock ที่มีการเก็บรักษา 3 ปีมีค่าใช้จ่ายประมาณ $46/ปีต่อ agent ค่าใช้จ่ายของการล้มเหลวในการตรวจสอบ SOC 2 เนื่องจากบันทึกที่ไม่เพียงพอคือการสูญเสียการรับรองการตรวจสอบ ซึ่งมักจะบล็อกการขายลูกค้า enterprise เป็นเวลา 6-12 เดือน

รูปแบบ PII pseudonymization แก้ไขความขัดแย้งการเก็บรักษา GDPR/SOC 2 ด้วยต้นทุนความซับซ้อนต่ำ คุ้มค่าที่จะใช้งานตั้งแต่ agent แรกที่สัมผัสข้อมูลส่วนบุคคล; การเพิ่ม pseudonymization ย้อนหลังลงในบันทึกที่มีอยู่ด้วย raw PII ซับซ้อนกว่าการสร้างที่ถูกต้องตั้งแต่แรก

สำหรับการควบคุมความปลอดภัย AI Agent ที่สร้าง audit events ที่บันทึกนี้จับ การเรียกใช้เครื่องมือที่ถูกปฏิเสธและความพยายาม prompt injection คือรายการที่มีคุณค่าทางนิติวิทยาศาสตร์มากที่สุด สำหรับกรอบการกำกับดูแล AI Agent ที่กำหนดนโยบายการเก็บรักษาและจังหวะการตรวจสอบ บันทึกการตรวจสอบคือฐานหลักฐาน

เริ่มต้น

ใช้งาน AI Agents ด้วยเส้นทางการตรวจสอบแบบ append-only ที่ฝังอยู่ บันทึกที่มีโครงสร้าง OTLP และความไม่เปลี่ยนแปลงของ S3 Object Lock

เริ่มสร้างบน OpenLegion อ่านเอกสาร สำรวจความปลอดภัย AI Agent

คำถามที่พบบ่อย

บันทึกการตรวจสอบ AI Agent คืออะไรและแตกต่างจากข้อมูล Observability อย่างไร?

บันทึกการตรวจสอบ AI Agent คือบันทึกแบบ append-only ที่ไม่เปลี่ยนแปลงของทุกการกระทำของ agent เขียนก่อนที่การดำเนินการจะเสร็จสิ้นและได้รับการปกป้องจากการแก้ไข ข้อมูล Observability (metrics, traces, dashboards) ตอบคำถาม "ระบบกำลังทำงานอยู่ตอนนี้ไหม?" และมักถูกสุ่มตัวอย่าง รวมกลุ่ม และเก็บรักษา 30-90 วัน บันทึกการตรวจสอบตอบคำถาม "agent นี้ทำอะไรในวันที่ 15 มีนาคม เวลา 14:32 น.?" และต้องเป็นบันทึก events แต่ละรายการที่ครบถ้วนโดยเก็บรักษา 1 ปีหรือมากกว่า SOC 2 CC7.2 และ GDPR มาตรา 30 กำหนดให้มีบันทึกระดับการตรวจสอบ; dashboards observability ไม่ตอบสนองมาตรฐานใด ๆ

SOC 2 Type II CC7.2 กำหนดให้มีอะไรจากบันทึกการตรวจสอบ AI Agent?

SOC 2 CC7.2 (การตรวจสอบระบบ) กำหนดให้มีบันทึก events แต่ละรายการ (ไม่ใช่ metrics รวมกลุ่ม) สำหรับทุกการเรียกใช้เครื่องมือที่มี agent_id, timestamp, พารามิเตอร์ทั้งหมด และผลลัพธ์ เก็บรักษาขั้นต่ำ 1 ปีเพื่อครอบคลุมระยะเวลาการตรวจสอบทั้งหมดเป็นข้อบังคับ หน่วยงานที่รับการตรวจสอบต้องไม่สามารถแก้ไขบันทึกของตัวเองได้; ผู้ตรวจสอบตรวจสอบโดยเฉพาะ นอกจากนี้ยังจำเป็นต้องมีหลักฐานการตรวจจับความผิดปกติอัตโนมัติและเอกสารการตรวจสอบเป็นระยะ dashboards observability ล้มเหลวในการควบคุมนี้เพราะไม่สามารถแสดง events แต่ละรายการ พิสูจน์ความครบถ้วน หรือพิสูจน์ความไม่เปลี่ยนแปลง

GDPR มาตรา 30 กำหนดให้มีอะไรจาก agents ที่ประมวลผลข้อมูลส่วนบุคคล?

GDPR มาตรา 30 กำหนดให้มีบันทึกกิจกรรมการประมวลผลสำหรับทุกการดำเนินการ agent บนข้อมูลส่วนบุคคล: agent_id, วัตถุประสงค์, ประเภทข้อมูลส่วนบุคคลที่เข้าถึง, ผู้รับ, ฐานทางกฎหมาย, ระยะเวลาการเก็บรักษา บันทึกต้องพร้อมให้แก่หน่วยงานกำกับดูแลตามคำขอ ค่าปรับสำหรับการไม่ปฏิบัติตามสูงถึง 10 ล้านยูโร หรือ 2% ของรายได้ต่อปีทั่วโลก ทุกการเรียกใช้เครื่องมือที่มีข้อมูลส่วนบุคคลในพารามิเตอร์ เช่น อีเมลผู้ใช้ IDs ลูกค้า หรือบันทึกทางการเงิน ต้องการบันทึกมาตรา 30 ที่ระบุฟิลด์เหล่านั้นเป็นข้อมูลส่วนบุคคลพร้อมวัตถุประสงค์และฐานทางกฎหมาย

แต่ละรายการบันทึกการตรวจสอบ agent ควรมีฟิลด์ใดบ้าง?

ขั้นต่ำ: agent_id, session_id, tool_call_id, timestamp (ก่อนการดำเนินการ), ชื่อเครื่องมือ, arguments ทั้งหมด (credential handles เป็น opaque $CRED{} tokens, PII ถูก pseudonymized), execution status (success/failure/rejected), เหตุผลการปฏิเสธหากถูกปฏิเสธ, duration, cost, credential handles ที่ใช้ และฟิลด์ข้อมูลส่วนบุคคลใด ๆ OTLP log spec ที่เสถียรให้โครงสร้างมาตรฐานด้วย TimeUnixNano, ObservedTimeUnixNano (สำหรับการตรวจจับการปลอมแปลง), TraceId และ SpanId (สำหรับการเชื่อมโยง distributed traces) และ Body object ที่มีโครงสร้าง

จะทำให้บันทึกการตรวจสอบไม่เปลี่ยนแปลงโดยไม่รบกวนการดำเนินการที่ถูกกฎหมายได้อย่างไร?

รวมกลไกสองอย่าง: cryptographic hash chains (แต่ละ record มี hash ของ record ก่อนหน้า ทำให้การแก้ไขตรวจจับได้ผ่านการยกเลิก hash แบบ cascade) และ WORM storage ที่ระดับ infrastructure (AWS S3 Object Lock ในโหมด Compliance ป้องกันการลบหรือแก้ไขแม้แต่โดย root account ตลอดระยะเวลาการเก็บรักษา) การอ่านบันทึกปกติและการเพิ่ม entries ใหม่เป็นที่อนุญาต; การแก้ไข records ที่มีอยู่ไม่เป็นที่อนุญาต สร้าง S3 bucket ด้วย Object Lock ที่เปิดใช้งาน (ไม่สามารถปิดใช้งานหลังสร้าง) และตั้งค่าการเก็บรักษาเริ่มต้นเป็นโหมด Compliance 3 ปี

จะจัดการคำขอลบ GDPR เมื่อบันทึกการตรวจสอบต้องไม่เปลี่ยนแปลงได้อย่างไร?

ใช้ pseudonymization: แทนที่ฟิลด์ข้อมูลส่วนบุคคลด้วย deterministic HMAC-SHA256 hashes โดยใช้ salt ที่เก็บไว้ใน credential vault ก่อนเขียนลงใน immutable log นามแฝงมีความเสถียรทำให้การเชื่อมโยงนิติวิทยาศาสตร์ระหว่างรายการบันทึกสำหรับเจ้าของข้อมูลเดียวกัน เมื่อได้รับคำขอลบ ให้หมุน salt; นามแฝงที่มีอยู่ทั้งหมดจะกลายเป็น unlinked จากเจ้าของข้อมูลต้นฉบับอย่างถาวร ตอบสนองมาตรา 17 โดยไม่ต้องลบบันทึกการตรวจสอบ บันทึกการตรวจสอบยังคงอยู่; ความสามารถในการเชื่อมโยงนามแฝงกับตัวตนจริงเท่านั้นที่ถูกทำลาย

ควรใช้การกำหนดค่า AWS S3 Object Lock ใดสำหรับบันทึกการตรวจสอบ agent?

ใช้โหมด Compliance (ไม่ใช่โหมด Governance) โหมด Compliance ป้องกันการแก้ไขหรือลบจากทุก account รวมถึง root; โหมด Governance อนุญาตให้ผู้ใช้ IAM ที่ได้รับอนุญาตสามารถ override lock ได้ agent ที่ทำงานปานกลางสร้างประมาณ 55 GB/ปีของข้อมูลบันทึก คิดเป็นประมาณ $15/ปีสำหรับการเก็บรักษา 1 ปีหรือ $46/ปีสำหรับ 3 ปีที่ $0.023/GB/เดือนบน S3 Standard เปิดใช้งาน S3 access logging บน audit bucket เพื่อให้การเข้าถึงของนักสืบถูกบันทึกเองเป็นเอกสาร chain of custody

จะสร้าง timeline นิติวิทยาศาสตร์จากบันทึกการตรวจสอบหลังเหตุการณ์ agent ได้อย่างไร?

Query audit log store ด้วย agent_id, session_id และช่วงเวลา เรียง records ด้วย TimeUnixNano จาก record แต่ละรายการดึง: ชื่อเครื่องมือ, execution status (รวมการปฏิเสธ), สรุป arguments, credentials ที่ใช้, สรุปผลลัพธ์ ตรวจสอบความสมบูรณ์ของ hash chain โดยการคำนวณ hashes ใหม่จาก record 1 เป็นต้นไป; การขาดใด ๆ บ่งชี้การปลอมแปลงและตำแหน่งของมัน สี่คำถามที่ timeline ควรตอบ: agent เรียกใช้เครื่องมือใด (รวมการปฏิเสธ)? เข้าถึงข้อมูลใด? credential handles ใดปรากฏในบริบทที่ไม่คาดหมาย? ระบบภายนอกส่งคืนอะไร? Export เป็น JSON-L พร้อม S3 Object Lock metadata เป็นหลักฐานการเป็นเจ้าของสำหรับการนำเสนอต่อหน่วยงานกำกับดูแล