Intent audit event fields-AgentLoop(AgentLoop)-阿里云帮助中心

This topic is intended for users who need to write custom queries, understand the data structure of intent audits, or integrate with external analysis systems. This topic describes the fields in the user intent recognition result table audit-event and the different field forms of normal intents and risk intents. Fields and values may be extended as the product evolves. The fields and values displayed in the console and returned in actual results prevail.

Note: All sample values in this topic are anonymized or synthetic. They are used only to illustrate field forms and data semantics. They do not represent real user data and are not equivalent to complete recognition conditions.

Table overview

User intent recognition reads user sessions from the application-side agent-event and agent-event-webtracking Logstores, extracts the user input at the start of each turn, and then summarizes the main intents by user and session.

Recognition results are written to audit-event. Each intent corresponds to one record. A session can contain multiple normal intents and risk intents. Each record references one representative user input event and retains the association identifier of the entire session.

audit-event is a Logstore shared by multiple types of audit results. In addition to intent recognition results, it may also contain agent context facts whose event_domain=agent_context, such as Skill read records whose event_name=skill.read. This topic describes only intent records whose event_name is intent.user_intent or intent.custom_user_intent. When you query data, first limit the scope by event_name.

A normal intent describes the work that a user completes by using an agent, such as coding and development, data analysis, or O&M troubleshooting. A risk intent describes an abnormal or malicious goal that a user explicitly expresses, such as a jailbreak attempt, theft of sensitive information, or exfiltration of data to external destinations. A risk intent does not prove that the agent has completed the corresponding action. To confirm actual side effects, further check the session and high-fidelity security events.

Common fields

The following fields appear in both normal intent records and risk intent records.

Field	Type	Description
`audit_event_id`	string	The stable primary key of the intent recognition result. It is suitable for deduplication, idempotent writes, and references from external systems.
`event_name`	string	The intent source. The value is `intent.user_intent` for default user intents and `intent.custom_user_intent` for custom user intents. Normal results and risk results use the same source value.
`event_domain`	enum	The result type. The value is `user_intent` for normal intents and `security` for risk intents.
`time_unix_nano`	int64	The Unix timestamp, in nanoseconds, of the representative user input event.
`source_scope`	enum	The value is fixed to `application`, which indicates that the result comes from application-side session data.
`service_name`	string	The name of the agent application or service.
`agent_type`	string	The agent type. The current value is `qoder`.
`user`	string	The flattened query column for the user entity. The value is preferentially taken from `user.id`.
`host`	string	The flattened query column for the host entity. The value is preferentially taken from `host.name`. If `host.name` is empty or missing, `__tag__:__hostname__` is used for compatibility.
`source_ip`	string	The flattened query column for the agent host IP entity. The value is preferentially taken from `host.ip`. If `host.ip` is empty or missing, `__source__` is used for compatibility. This field does not indicate a network peer or an outbound destination.
`entities`	object[]	The snapshot of associated entities, such as the user, host, and agent host IP. It is used for multi-entity relationships and exact entity lookups.
`reason`	string	A brief description, in Chinese, of the current intent classification.
`usage_total_tokens`	int64	The number of session tokens allocated based on the proportion of the intent. The sum of this field across all intents in a session equals the total number of tokens of the session.
`evidence_event_id`	string	The ID of a real user input event that represents the current intent.
`evidence_session_id`	string	The ID of the session to which the current intent belongs. It is used for session drill-down and aggregation.
`operation_stage`	enum	A common nullable field of the audit result table. A user intent does not represent a specific operation, so this field is empty. A risk intent does not indicate that the related operation has been initiated or executed.
`detector_name`	string	The name of the detector or service that generates the result.
`detector_version`	string	The version of the detector that generates the result.

user, host, and source_ip are flattened query columns for common entities and are suitable for direct filtering and grouping. For multi-entity relationships and exact entity lookups, still use entities. These flattened columns can be empty if the corresponding values cannot be extracted from historical records.

Normal intent fields

Normal intent records meet the condition event_domain=user_intent and use the following classification fields:

Field	Type	Description
`intent_category`	string	The domain of the normal intent, such as software engineering, data and analytics, O&M and platform, or product and business.
`intent_subcategory`	string	The type of the normal intent, such as coding and development, data analysis, O&M troubleshooting, or product planning.

Normal intents do not write risk_type, risk_subtype, or severity. The absence of these risk fields indicates that the record is a normal work intent, not that the data is incomplete.

Risk intent fields

Risk intent records meet the condition event_domain=security and use the following risk fields:

Field	Type	Description
`risk_type`	string	The security risk category, such as `credential_access`.
`risk_subtype`	string	`risk_type`The security risk subcategory under `private_key_read`.
`severity`	enum	The severity of the risk intent. Valid values: `critical`, `high`, `medium`, and `low`.
`evidence_security_event_ids`	string[]	This field is currently an empty array. User intent recognition directly analyzes raw sessions and does not depend on `security-event`.

Risk intents do not write intent_category or intent_subcategory. When you use risk intent results, make judgments based on event_domain, risk_type, and risk_subtype. Do not interpret the absence of normal intent fields as a data exception.

Default user intents and custom user intents use the same two-level security risk classification. They differ in source only by event_name, and the severity and proportion have the same meanings. The risk classification is consistent with security detection. However, a risk intent indicates only the goal expressed by the user and does not indicate that the corresponding action has occurred.

Historical risk intents

Historical records written before the upgrade use risk_type=user_intent_risk and retain the original 11 values of risk_subtype. The console continues to display, query, and filter these records by their original Chinese names, and does not automatically convert them to the new security risk classification. When a query spans the upgrade time, always aggregate by the complete risk_type + risk_subtype combination. Even if the risk_subtype text of a new record and an old record is the same, the records cannot be merged.

Event examples

The following examples show only the fields commonly used in intent audits.

Normal intent

{
  "audit_event_id": "intent-demo-normal-001",
  "event_name": "intent.user_intent",
  "event_domain": "user_intent",
  "time_unix_nano": 1786208400000000000,
  "source_scope": "application",
  "service_name": "ai-coding-agent-qoder",
  "agent_type": "qoder",
  "user": "user-demo-001",
  "host": "demo-host",
  "source_ip": "10.0.1.42",
  "intent_category": "software_engineering",
  "intent_subcategory": "coding",
  "reason": "The user mainly asked the agent to develop APIs and adjust code.",
  "usage_total_tokens": 8400,
  "evidence_event_id": "evt-user-query-001",
  "evidence_session_id": "session-demo-001",
  "entities": [
    {
      "type": "user",
      "id": "user-demo-001",
      "display_name": "Sample user"
    }
  ]
}

Risk intent

{
  "audit_event_id": "intent-demo-risk-001",
  "event_name": "intent.user_intent",
  "event_domain": "security",
  "time_unix_nano": 1786208460000000000,
  "source_scope": "application",
  "service_name": "ai-coding-agent-qoder",
  "agent_type": "qoder",
  "user": "user-demo-001",
  "host": "demo-host",
  "source_ip": "10.0.1.42",
  "risk_type": "credential_access",
  "risk_subtype": "private_key_read",
  "severity": "high",
  "reason": "The user explicitly asked for access credentials outside the scope of the current task.",
  "usage_total_tokens": 3600,
  "evidence_event_id": "evt-user-query-002",
  "evidence_session_id": "session-demo-001",
  "evidence_security_event_ids": [],
  "entities": [
    {
      "type": "user",
      "id": "user-demo-001",
      "display_name": "Sample user"
    }
  ]
}

The two examples come from the same session. The intent proportions add up to 100%, and the allocated tokens add up to the total number of session tokens. The risk intent proves only that the user expressed a risk goal, not that the agent has obtained the credentials.

Query suggestions

Scenario	Recommended condition or field	Description
Query all intent results	`event_name IN ('intent.user_intent', 'intent.custom_user_intent')`	Queries both default and custom user intents and excludes other types of audit results in `audit-event`.
Query only normal intents	`event_domain = 'user_intent'`	Aggregate by `intent_category` and `intent_subcategory`.
Query only risk intents	`event_domain = 'security'`	Aggregate by the complete `risk_type`, `risk_subtype`, and `severity`.
Analyze by user	`user`	Filter or group directly by the flattened query column. Parse `entities` only when you need complete entity relationships.
Analyze by host	`host`, `source_ip`	Filter or group by the host on which the agent runs and by the agent host IP, respectively.
Trace back to the original user input	`evidence_event_id`	Locate the representative user input event in `agent-event` and `agent-event-webtracking`.
Trace back to the complete session	`evidence_session_id`	In session browsing, view the user input, model responses, and tool behavior of the same session.

Aggregate the risk distribution by both risk category and risk subcategory:

GROUP BY risk_type, risk_subtype

When you filter by multiple risk classifications, generate conditions based on complete combinations of risk category and risk subcategory. Do not use separate IN clauses on the two fields:

(
  (risk_type = 'credential_access' AND risk_subtype = 'private_key_read')
  OR
  (risk_type = 'user_intent_risk' AND risk_subtype = 'jailbreak')
)

Relationship with other audit data

Data	Relationship
`agent-event` / `agent-event-webtracking`	The raw application-side session data for user intent recognition.
`security-event`	Rule-based low-fidelity security findings. User intent recognition does not depend on this table.
`incident-event`	High-fidelity security events, which are used to confirm risk actions or data exposure that have already occurred.
`audit-event`	A Logstore shared by multiple types of audit results. Intent records store both normal intents and risk intents. Other `event_domain` values can store non-intent facts, such as agent context.