Administration Govern and monitor
Logs, audit and system health
See who did what, investigate an agent's steps, safely reveal redacted data, and check the platform is healthy.
For Org Admins and Security Admins
Which logs exist
| Log | What it records | Who can read it |
|---|---|---|
| Access logs | Every important action: sign-ins, creating, changing and deleting resources, sharing, role and membership changes, policy and quota changes, credential changes, reveals | Org Admins and Security Admins (everything, with CSV export). Group Admins see entries tagged with their groups. |
| Agent logs | Each step of an agent's turn: what it was asked, what it reasoned, which tools it used with what inputs, and what it answered | The conversation's owner, Group Admins for their members, Org and Security Admins |
| AI logs | Technical traces of AI calls | Your observability tooling |
| System logs | Technical logs of the platform | The people who run the installation |
Find the first two under Admin › Access logs and Admin › Agent logs.
Personal data in logs
Logs never hold personal data in the clear. Detected values are replaced with <REDACTED> when the entry is written, using the same rules as AI masking. Values of secure playbook variables are always redacted.
Revealing
Only a Security Admin can reveal redacted values.
- Open the entry, or a whole turn, in the log.
- Choose Reveal and give a reason (3 to 500 characters).
- The original appears. Hide and Show toggle it on the page.
Every reveal is itself recorded with your reason, and nothing is ever changed in the stored entry. The revealed values stay only on your screen and disappear when you reload. CSV exports stay redacted.
Investigating something that went wrong
- In Access logs, filter by action (for example,
tool_policy,credential,share) or actor to find the change. - In Agent logs, find the conversation or turn, and step through what the agent saw and did.
- In the chat or Control Room, open the run for its step-by-step record, and Retry from failed step if a playbook run failed.
- If it involves personal data, ask a Security Admin to reveal the relevant entry.
System health
Admin › System shows:
- Health of the main parts: the application, its database, queue, file store, search store, browser and sandbox services.
- Usage metrics: active people, conversations, messages, automation runs, tokens used and tool usage.
- Console links your operators add, to monitoring tools.
If something looks unhealthy, hand the details to whoever operates your installation.
Notifications about problems
Failed automations, agent tasks and runs appear in the notification bell of their owner. A good starting use case is a routine review: list the automations whose runs failed this week. Ask the copilot: “Which of my automations had failed runs?”