Audit

Audit records are structured events for Anyy actions that change state, touch sensitive surfaces, require approval, or need an operator-visible trail.

Audit is not the same as the transcript. It stores event metadata, risk, category, object identity, and redacted payloads so runtime changes can be reviewed without exposing raw secrets.

Audit Categories

Anyy uses typed categories for different kinds of activity:

Category	Examples
approval, change_plan, force_path	User decisions, ChangePlan lifecycle, force-approved paths.
shell, root_tool, file_write	Host/runtime operations and file mutations.
config_change, provider_change, channel_change, pairing_change	Local configuration changes.
cron_change, task_change, skill_change	Scheduled jobs, durable tasks, and skill visibility or edits.
messaging, connector_action	Outbound delivery and email/calendar actions.
desktop_control	computer_use desktop actions.
runtime_read	Selected runtime reads such as skill_view, artifact_list, and artifact_inspect.
mcp_config_change, mcp_server_start, mcp_server_stop, mcp_tool_call	MCP config and runtime events.

Each event stores actor_id, role_id, workspace_id, session_id, turn_id, run_id, summary, risk, object_type, object_id, and created_at when available.

Sensitive Data Redaction

Audit payloads are explicitly named redacted_payload. Anyy redacts at several layers:

Source	Redaction behavior
Global secret redactor	Redacts known secret values in summary, object id, and nested payload fields.
Terminal tools	Redacts environment values.
Process input	Redacts stdin/input fields for write-like process actions.
Skill management	Redacts file content and patch strings.
computer_use	Redacts typed text and desktop tree/snapshot fields.
Email/calendar connectors	Redacts bodies, attendees, attachments, provider payloads, tokens, and passwords.

Redaction keeps byte counts where useful so an operator can understand size without seeing sensitive content.

Tool Call Records

Tool audit events include:

Field	Meaning
tool	Effective tool name.
status	Tool result status.
force	Whether execution used force-approved metadata.
arguments	Sanitized and tool-specific redacted arguments.
change_plan_id	Present when the result created or used a ChangePlan.
details_ref	Present when the result stores large details separately.
Approval correlation	Approval id, approved tool call id, and approved ChangePlan id when replayed.

Read tools are not all audited. Runtime-read audit is intentionally narrow in this build and includes successful skill_view, artifact_list, and artifact_inspect.

Connector Records

Connector mutations such as sending email or creating calendar events use approval and connector audit categories. Read/status/list calls use direct read behavior unless governance changes the descriptor.

Connector audit redaction avoids storing raw message bodies, attendee lists, attachments, access tokens, refresh tokens, or passwords.

MCP Records

MCP management operations write MCP-specific categories for config changes, server lifecycle, bridge approvals, and external MCP tool calls. MCP status and logs redact configured secret values before returning diagnostics.

For MCP setup and policy, see MCP Integration.

Querying Audit

Local and dashboard surfaces use the gateway audit RPC:

Parameter	Meaning
session_id	Optional session filter.
category	Optional audit category filter.
limit	Optional result cap. Default is 50, maximum is 200.

The RPC returns events ordered newest first. ListBySession storage helpers keep session-specific events in chronological order for replay and tests.

Debug And Logs

Audit is one part of observability. For runtime diagnosis, combine it with:

Surface	Use
doctor / doctor RPC	Runtime health checks.
logs RPC	Tail logs/anyy.log with optional filtering.
Dashboard status pages	Operator-friendly runtime views.

Debug bundles and logs must follow the same secret-redaction rule: do not expose raw credentials, tokens, approval replay metadata, or connector payload bodies.