DocsICP FilingConsole
Documentation
Home Page AgentLoop User Guide AI Agent Audit Audit overview

Audit overview

Updated at:
Copy as MD
Product
My Favorites

AI agents have system-level capabilities such as file system manipulation, shell command execution, API calls, and outbound network access. During operation, they are exposed to risks such as sensitive data exposure, abnormal behavior, privilege overreach, and security compliance issues. The AgentLoop audit module provides end-to-end audit capabilities for all types of AI agent applications, from data ingestion and risk detection to evidence investigation. It helps security teams and application owners build visibility into and governance over agent behavior and risks.

Feature overview

The AgentLoop audit module follows the core workflow of "Integration configuration → Audit Management → Risk discovery → Entity Investigation → Audit Facts replay" and provides the following core capabilities:

  • Access Center — Supports session log ingestion for multiple types of AI agents and AI node Runtime/eBPF ingestion. Currently supported: AI coding agents such as Qoder, Cursor, Claude Code, and Codex, as well as AI node Runtime/eBPF runtime collection.

  • Audit Management — Centrally configure application risk detection, runtime risk detection, and semantic detection options, manage custom audit rules, connect existing application tracing data to audit, and view the status of detection tasks and data ingestion.

  • Custom Audit Rules — Use the Loopie chat assistant to create or modify behavior detection rules and event correlation rules, and view rule relationships, running status, and the type catalog.

  • Risk Audit — Use Overview, Risk Explorer, User Risk, and Intent Audit to view the risk posture, risk events, detection findings, and investigation evidence.

  • Entity Investigation — View associated risks, sessions in which an entity appears, and co-occurrence relationships centered on entities. Supports reverse context lookup from entities such as secrets, PII, file paths, outbound domains, target IPs, applications, hosts, users, Agent host IPs, tools, and commands.

  • Audit Facts — Provides session browsing, token analysis, and behavior analysis. Directly describes raw audit facts and standardized audit activity data, without requiring Risk Audit Scheduled SQL to be enabled.

Core value

The audit module helps you answer the following key questions:

  • What are the highest-priority risks today?

  • Did sensitive data exposure or exfiltration occur in this session?

  • Did the agent execute unauthorized code, perform destructive operations, or change permissions?

  • What work do users mainly use agents for, and is there any abnormal or malicious intent?

  • What call chains are associated with a specific AccessKey, domain, or user?

  • How did sensitive information enter the agent context?

  • What protection policies should be generated?

Target users

Role

Primary needs

Security operations personnel

Identify priority risks, investigate and validate

Agent application owners

Understand whether the agents they are responsible for have risks

Platform administrators

Manage data collection configuration and security inspection settings

Prerequisites

  • AgentLoop is activated.

  • An AgentSpace is created.

  • AI agent applications (such as Qoder, Cursor, or Claude Code) are deployed on the target host or cluster.

Workflow

Complete the following steps to use the audit features:

  1. Ingest data — Configure AI application log collection or AI node Runtime/eBPF collection in the Access Center to report agent behavior data to AgentLoop. If the application is already connected to observability Traces, you can also connect application tracing data to audit in Audit Management. For more information, see Audit Integration Guide and Connect application tracing data to audit.

  2. View audit facts — After data ingestion, browse sessions and view token analysis and behavior analysis in Audit Facts to verify ingestion results and reconstruct the original interaction context. For more information, see Audit Facts.

  3. Enable risk audit — On the Audit Management page, enable application or runtime risk detection, and select advanced detection capabilities such as prompt injection, unexpected code execution, and destructive operations as needed. For more information, see Audit Management.

  4. Configure custom rules as needed — Use the Loopie chat assistant to create detection and correlation rules that meet your enterprise risk standards, review the validation evidence, and then save and apply the rules. For more information, see Custom audit rules.

  5. View risk audit — Assess the overall risk level in Overview, view risk events and detection findings in Risk Explorer, and use User Risk and Intent Audit to locate the scope of impact. For more information, see Risk Audit.

  6. Entity investigation — Starting from risk-related entities, trace the sessions in which they appear, co-occurrence relationships, and risk evidence to conduct in-depth security investigations. For more information, see Entity Investigation.

Data architecture

The audit module organizes data processing into the following layers:

  • Raw Facts Layer — Application-side agent event logs (agent-event and agent-event-webtracking) and eBPF runtime events (ebpf-event). This layer serves as the foundation for risk detection, audit facts, and investigation analysis.

  • Standardized Activity Layer — Normalizes agent behavior from both the application side and the runtime side into unified audit activity data, used by risk detection, audit facts, and investigation entry points.

  • Low-Fidelity Discovery Layer — security-event stores rule-based, low-fidelity security findings.

  • High-Fidelity Event Layer — incident-event stores actionable, high-fidelity security events.

  • Risk Query View Layer — risk_view supports risk ranking, reporting, and investigation entry points.

Data storage is based on Simple Log Service (SLS), using Scheduled SQL for scheduled security detection tasks.

Logstore naming conventions

SLS physical Logstore names (the API logstore parameter, ingestion configurations, and query examples) always use hyphens (kebab-case). The source of truth in code is src/constants/audit-logstores.ts.

Logical key

SLS physical name

Purpose

agentEvent

agent-event

Stores standardized events of AI agent session logs

agentEventWebtracking

agent-event-webtracking

Stores AI agent session logs written through the WebTracking pipeline

ebpfEvent

ebpf-event

Stores raw runtime events from eBPF Runtime

securityEvent

security-event

Stores low-fidelity security findings

incidentEvent

incident-event

Stores high-fidelity security events

The following names are not physical Logstore names and can keep underscores in documents and SQL:

  • SQL field names (such as security_event_id)

  • Logical table or view names and intermediate query layer names

  • Scheduled SQL job names (such as agentloop_security_event_application_etl)

  • Logical identifiers in data contracts (such as source_scope = 'application')

Previous：AI Agent AuditNext：Connect application tracing data to audit