:bolt: | Logging Into Aiceberg | See Aiceberg in action. | /pages/86b52bb11c848c6966983712348694d2b33f98d9 | ||
:user-police: | Listen vs Enforce | Learn the basics of Aiceberg | /pages/bbfc9ab36e355f8f946b42148732bda2b21cb8ad | ||
Close window
* 
Expand to full screen
* 
Trace
* 
Report Signal
* 
Bookmark
* 
All Signals passed
* 
Signal failed, prompt wasn't blocked based on Profile settings
* 
Signal failed, prompt was blocked
You can also copy the Prompt ID (click to copy) for reference.
{% endstep %}
{% step %}
### Prompt area
The Prompt section shows:
* an icon for the prompt action
* tokens used
* a copy-to-clipboard action for the whole text
* a full screen icon
Prompt action icons include:
* .svg)
Blocked
*  Redacted
{% endstep %}
{% step %}
### Signal results cards
The next four cards are Signal result groups. To learn more about Signals and the four groups, see the [Signals documentation](/signals/what-are-risk-signals).
* Tap the chevron on any group to expand/collapse and see subcategories (if present).
If a Signal is detected, hover over the circle to the left of the category to display the probability percentage associated with that category. The size of the red circles represents the likelihood that the prompt falls into a category or subcategory.
{% endstep %}
{% endstepper %}
Learn more about Trace [here](/monitoring/what-is-the-monitoring-page/how-can-i-see-more-details-for-a-prompt/how-do-i-see-why-a-signal-fired-the-way-it-did-the-trace-feature).
# How do I see why a Signal fired the way it did? The Trace feature
## What is Trace?
One of the most powerful features in Aiceberg is the ability to see why a Signal was triggered and why it wasn't. **Trace** is the feature that powers our Signal detection without relying on generative AI models.
Incoming prompts are semantically chunked to preserve meaning and processed through our patented models to identify the most relevant samples. Those samples are then used to determine Signal results. Probability calculations are made and users can see the likelihood that the content matches specific risk Signals as well as the actual samples that contribute to the result.
Why this matters:
* Every detection can be audited and traced back to specific training examples
* Unpredictable outputs are reduced with verifiably consistent performance
* CPU-only processing means classification is fast
* Scores are based on mathematical proximity, not black box decisions, so scoring is transparent
To view Trace, tap into [prompt details](/monitoring/what-is-the-monitoring-page/how-can-i-see-more-details-for-a-prompt) from Monitoring and tap the Trace icon at the top.
Aiceberg semantically chunks long inputs, ensuring that each piece contains complete thoughts or concepts to improve retrieval accuracy and reduce noise.
Use the toggle to switch between prompt and response analysis and see any flagged Signals or detected Intent. The numbers in the Signal pills indicate the chunk in which the Signal was found.
Tapping the numbered selector above the chunk text will navigate you to that chunk. Selectors are highlighted to show where Signals occurred. Tap the Explainability chevron to show the five nearest neighbor samples that were used to determine similarity for Signals in that chunk.
# What are Events and how are they monitored?
**Events** are discrete interactions between two participants in an AI system (usually an agentic system) that involve an input, processing, and an output.
### Overview
Event monitoring captures and analyzes interactions in your AI ecosystem, from simple chat completions to sophisticated multi-agent workflows. Each Event represents a communication between different participants in your AI system and provides detailed insights into the flow, security, and compliance of your AI operations.
{% stepper %}
{% step %}
### Event Participants
Events are categorized by the participants involved in the interaction:
| Participant | Description |
| ------------------ | -------------------------------------------------- |
| **User** | The end user initiating requests and interactions |
| **LLM** | Large language models processing requests |
| **Agent** | Autonomous agents in agentic frameworks |
| **Tool** | External tools, APIs, or plugins agents can access |
| **Memory** | Memory storage systems for agent state |
| **Initialization** | Agent initialization (future feature) |
| {% endstep %} | |
{% step %}
### Event Types
Events are classified based on participant relationships.
#### Basic Events
* **user\_llm**: Standard user-to-LLM interactions (chat completions, Q\&A)
* **user\_agent**: User requesting an agentic system to perform tasks
#### Agent Events
* **agent\_llm**: Agent communicating with LLMs for various purposes
* **agent\_tool**: Agent invoking external tools or APIs
* **agent\_agent**: Agent-to-agent communication
* **agent\_mem**: Agent accessing memory storage
* **agent\_init**: Agent initialization and configuration
#### Agent-LLM Event Subtypes
* **agent\_llm.planning**: Agent requesting workflow planning from LLM
* **agent\_llm.action**: Agent asking LLM how to execute specific actions
* **agent\_llm.content**: Agent requesting content creation from LLM
#### Tool Integration Events
* **agent\_tool.mcp**: Agent using Model Context Protocol (MCP)
* **agent\_tool.api**: Direct API tool invocations
* **agent\_tool.data\_source**: Agent accessing non-MCP data sources
#### Agent Communication Events
* **agent\_agent.a2a**: Agent-to-Agent protocol communication
* **agent\_agent.custom\_channel**: Custom communication channels
{% endstep %}
{% step %}
### Event Properties
Each event includes comprehensive metadata and analysis results.
#### Core Identifiers
* **event\_id**: Unique ULID identifier (lexicographically sortable)
* **event\_type**: Classification based on participants
* **session\_id**: Groups related events in a session
* **profile\_id**: Associated Aiceberg monitoring profile
#### Content
* **input**: The original request or message
* **output**: The response from the receiving participant
* **user\_id**: Identifier for the initiating user or application
#### Analysis Results
* **input\_signal\_result**: Security and compliance analysis of inputs
* **output\_signal\_result**: Analysis of outputs
* **event\_result**: Overall event assessment
* **input\_system\_actions**: Automated actions taken on inputs
* **output\_system\_actions**: Automated actions taken on outputs
{% endstep %}
{% step %}
### Event Status
Events progress through various states:
| Status | Description |
| ------------------------------- | ------------------------------------ |
| `created` | Event logged and queued for analysis |
| `running` | Analysis in progress |
| `running.input_analysis` | Analyzing input content |
| `running.fetching_llm_response` | Waiting for LLM response |
| `running.output_analysis` | Analyzing output content |
| `finished.input_blocked` | Input blocked by policies |
| `finished.output_blocked` | Output blocked by policies |
| `success` | Event completed successfully |
| `success.input_modified` | Input was modified before processing |
| `success.output_modified` | Output was modified before delivery |
| `failed` | Event processing failed |
| {% endstep %} | |
| {% endstepper %} | |
***
## Event Monitoring
### Viewing Single Events
Events appear in the Monitoring interface and Prompt Details.
To view Events in Monitoring, navigate to the appropriate tab and tap the filter icon.
Tap the gear icon and enable the Event To and Event From columns.
Event icons are now visible. Filtering and sorting on Event type, status, or participant will be included in a future release. Hovering over an Event icon will show the participant type.
In Prompt Details, Event participant icons are located near the Prompt and Response text.
### Viewing Events as Part of an Agentic Workflow
Single events can be seen in context by enabling the Sessions view in Monitoring. For complex agentic systems, event monitoring provides:
#### Planning Visibility
Track how agents break down complex requests:
```
user_agent: "Create a quarterly report"
└── agent_llm.planning: Agent requests execution plan
└── agent_tool.data_source: Agent retrieves Q3 data
└── agent_llm.content: Agent generates report sections
```
#### Tool Usage Tracking
Monitor agent tool interactions:
* API calls and responses
* Data source queries
* MCP protocol communications
* Custom tool integrations
#### Agent Communication
Observe multi-agent coordination:
* Task delegation between agents
* Information sharing
* Collaborative problem-solving
### Best Practices
#### Event Organization
* Implement session management for related interactions
* Leverage event subtypes for granular analysis
### Security Monitoring
* Regularly review failed events for security indicators
* Monitor agent tool usage for unauthorized access attempts
* Track input/output modifications for compliance auditing
### Performance Optimization
* Filter events by time range for large-scale analysis
* Use event\_type filtering to focus on specific workflows
* Monitor processing times for performance insights
# What are Sessions?
**Sessions** are continuous interaction sequences between a user and an AI model or agent. Sessions encompass:
* Multiple related prompts and responses in a conversation thread
* Events and participant interactions across an agentic workflow
Learn more about [Events](/monitoring/what-is-the-monitoring-page/what-are-events-and-how-are-they-monitored) here.
## How Sessions are Created
Sessions are automatically grouped using two methods:
* The same user sends another prompt within 45 seconds of their previous prompt
* Prompts sent via the API that include the same Session ID
The first or header input in a Session must originate from either a User or Agent Participant. If the first prompt comes from another Participant type, the Session will have no header. Learn more about Participants [here](/monitoring/what-is-the-monitoring-page/what-are-events-and-how-are-they-monitored).
## How to View Sessions
{% stepper %}
{% step %}
### Open Monitoring and enable Sessions column
1. Navigate to the Monitoring page and tap the filters icon.
2. Tap the Settings menu (top right) and ensure the Session column is enabled.
{% endstep %}
{% step %}
### Filter to show only session headers
* To filter out "child" prompts and show only the first prompt in a Session, open the filters and enable "Show only sessions."
Note: Single prompts are considered a Session of one and will still show even when "Show only sessions" is enabled.
{% endstep %}
{% step %}
### View the full Session thread
* In the Monitoring page, a Sessions column is now available. Tap the Sessions icon to view the whole conversation.
* Prompts are filtered to only those that are in a single Session. The threading on the left shows the hierarchy of inputs by time, and the top input will always be the Session header. (Increased threading depth beyond one child is a future feature.)
{% endstep %}
{% step %}
### Return to the regular Monitoring view
* To navigate back to the regular Monitoring view, tap the back arrow next to the Bookmarks tab at the top.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Sessions will "close" if 24 hours elapse between inputs. Any additional content sent with the same Session ID via the API will result in an error.
{% endhint %}
# How do I manage Users and Roles?
Account admins can access the User Management features via the Tools menu.
This page shows all users added to the account, displaying first and last names, email, and created date.
* Email address is the only required field, but can't be edited after a user is created
* To add a new user, tap the + icon at the top right
* To delete a user, tap the kabob menu at the top left
* The yellow warning icon indicates that the invitee has not yet changed their password and logged in
| Value | Boundary | Description |
|---|---|---|
| user_llm | User --> LLM | A human or machine user submitting input to an AI agent or LLM. Default value |
| user_agt | User --> Agent | A human or machine user submitting input to an AI agent. Default value |
| agt_llm | Agent --> LLM | An AI agent submitting a prompt or context to an LLM for inference or completion |
| agt_tool | Agent --> Tool | An agent invoking an external, API, or function call. Pass tool call details as a JSON-serialized string in input with keys tool_name, tool_args, and tool_call_id. Pass the tool result as a JSON-serialized string in output with keys tool_name, tool_call_id, and tool_result |
| agt_mem | Agent --> Memory | An agent reading from or writing to a memory or context store |
| agt_agt | Agent --> Agent | An orchestrator agent delegating tasks to a sub-agent |
| agt_user | Agent --> User | A human or machine user receiving output from an AI agent |
| Field | Type | Description |
|---|---|---|
| event_id | string | Unique identifier for this analysis event |
| event_type | string | Type of event ("user_llm") |
| status | string | Processing status ("finished", "processing", "failed") |
| created_at | number | Unix timestamp when the event was created |
| finished_at | number|null | Unix timestamp when processing completed |
| input | string | The original input prompt |
| output | string | Generated response if processed, or block message if rejected |
| session_id | string|null | Session identifier for tracking related events |
| profile_id | string | Profile used for analysis |
| profile_version | number | Version of the profile configuration |
| user_id | string | User identifier defaults to 'apikey' if not set. To set a custom value, pass inside the metadata object--top level is not accepted |
| log_group | string | Logging category ("monitoring", "sandbox") |
| input_signal_result | string | Overall risk assessment for input |
| output_signal_result | string|null | Overall risk assessment for output (null if no LLM response generated) |
| event_result | string | Final event classification (e.g., passed, flagged, rejected) |
| input_system_actions | array | Actions taken on input (e.g., "log", "modify", "block", "alert") |
| output_system_actions | array | Actions taken on output (e.g., "log", "alert") |
| input_token_count | number | Number of tokens in the input |
| output_token_count | number | Number of tokens in the output (0 if blocked) |
| initiator | string | Type values include user, agent, LLM |
| sender | object | Type values include user, agent, LLM |
| receiver | object | Type values include user, agent, LLM, memory, tool |
- Streaming output to your UI
- Logging and debugging
- Watching things as they happen
- Safety checks and guardrails
- Blocking bad content
- Enforcing rules
User to Agent Forward
User to Agent backward
Agent to LLM Forward
Agent to LLM backward
Agent to Tool Forward
Agent to Tool backward
Agent to memory forward
Agent to memory backward
for short term memory