Audit Trail & Oversight
Every action a digital worker takes is logged, auditable and reviewable. This page covers how session logging works, how to review agent decisions, and how to provide feedback that improves future behaviour.
Session Logging
Every time an agent runs, it creates a session. A session records:
- Timestamp — When the session started.
- Agent and template — Which deployed agent ran and which template version it used.
- Target — What the agent was working on (e.g. Threat #1234).
- Status — Whether the session completed successfully, failed, or was interrupted.
- Duration — How long the session took.
- Token usage — Input and output token counts for cost visibility.
- Steps — A detailed sequence of everything the agent did during the session.
Session Steps
Each step within a session records:
- Sequence number — The order in which steps occurred.
- Event type — What kind of step it was (tool call, decision, guardrail check, error, etc.).
- Tool name — If the step involved a tool call, which tool was used.
- Content — The reasoning or output from that step.
- Duration and tokens — Per-step timing and token usage.
Guardrail Checks
When an agent encounters a decision boundary, a guardrail check is logged. Each check records:
- Target — What the guardrail was evaluating.
- Direction — Whether the check was on input or output.
- Decision — Whether the action was allowed, blocked, or modified.
- Profile — Which guardrail profile was applied.
Guardrail checks give you visibility into what the agent considered doing but was prevented from, and what actions were modified before they were taken.
Reviewing Sessions
Sessions are viewable in the portal from two places:
- Agent Sessions tab — Shows all sessions across all deployed agents. Filter by role, status, time range, or search by threat ID.
- Deployment detail page — Shows sessions for a specific deployed agent, along with metrics and configuration.
Click any session to expand it and see the full step-by-step sequence. From an expanded session, you can:
- Add a Learning — Capture a correction or preference based on what the agent did.
- Add Knowledge — Add context that would have helped the agent make a better decision.
- Navigate to the deployment — View the agent’s configuration and other sessions.
Providing Feedback
Learnings
Learnings are the primary mechanism for tuning agent behaviour. When you see a session where the agent made a decision that should have gone differently:
- Click + Add Learning on the session.
- Describe what the agent should have done differently.
- The learning is created in PROPOSED status.
- An administrator approves the learning to make it active.
- The agent applies the learning on future runs.
Learnings accumulate over time. The more feedback you provide, the better the agent aligns with your organisation’s specific conventions and preferences.
Knowledge
If a session shows the agent lacked context that would have improved its decision, add it as a knowledge source:
- Click + Add Knowledge on the session.
- Provide the context (e.g. “10.200.x.x is our internal monitoring subnet — traffic from these IPs is expected”).
- Scope it appropriately (organisation, project, or deployment).
- The agent retrieves this context when relevant in future sessions.
Metrics
The deployment detail page shows session metrics over time, including:
- Session volume and frequency.
- Success and failure rates.
- Duration trends.
- Token usage.
Use these metrics to understand how the agent is performing and whether tuning is needed.
Best Practices
- Review sessions regularly, especially in the first weeks after deployment. Early feedback has the most impact.
- Be specific in learnings — “Threats from 10.200.0.0/16 should always be marked as internal monitoring” is better than “Don’t flag internal traffic.”
- Scope knowledge carefully — Organisation-wide knowledge affects all agents. Use project or deployment scope when context is specific to one area.
- Approve learnings promptly — Proposed learnings do not take effect until approved.