---
name: audit-review
description: Pull recent audit-log events for the workspace and summarize unusual activity. Owner role + Business tier required.
arguments: []
---
# Audit-log review for the API key's workspace

Default look-back: **24 hours**. If the user mentioned a different
window in their message ("last 72 hours", "this week", "past 30 days"),
honor that instead — convert to a whole-hour integer for the tool call.

The audit log is the SOC 2 evidence artifact, so the findings here go
into security review.

## Step 1 — Probe permissions

```
get_me()
```

If `role !== "owner"` OR `workspace.tier !== "business"`, stop here and
explain what's gating access:

- Wrong role → tell the user only owners can read the audit log;
  ask their workspace owner to run this prompt.
- Wrong tier → tell the user the audit log is a Business-plan feature;
  link them to https://pinappai.com/pricing/.

## Step 2 — Read the window

Use the look-back set at the top of this prompt (default 24h, or the
user's override). Compute `from = now - hours * 3600 * 1000`:

```
list_audit_events({ from: <ms-since-epoch>, limit: 200 })
```

If `limit` rolls (200 returned), warn the user the window has more events
than fit in one call and offer to paginate (`offset: 200`, `offset: 400`,
…).

## Step 3 — Summarize

Bucket the rows by `action`. For each bucket give:

- Count
- Most-active actor (by count of `actor_email`)
- One representative `target_id` example

Then call out **unusual** patterns:

- `result: "failure"` rows. Especially `*.schedule-deletion` failures —
  those indicate someone was trying to delete a workspace/project but
  hit the confirmation phrase guard.
- Any single `actor_ip` doing >10 actions inside a 5-minute window.
- `role.change` rows promoting someone to `owner` or `admin`.
- `api_key.revoke` rows where the actor isn't an owner/admin (shouldn't
  happen — server gates this — but worth catching if it ever does).
- `workspace.schedule-deletion` or `project.schedule-deletion` (you
  probably want the user to know if a teammate just queued a deletion
  they didn't expect).

## Step 4 — Recommend follow-ups

If you flagged anything in step 3, propose concrete next steps:

- "Cancel pending workspace deletion" → user clicks the email magic link,
  OR (if they're the owner) you can hand them the recovery URL from the
  `metadata_json.recovery_url` field of the schedule-deletion row.
- "Check active sessions" → the audit trail shows every actor_ip /
  actor_ua pair; a sudden new IP for an admin is worth investigating.
- "Rotate suspicious API keys" → walk through `list_api_keys` →
  `revoke_api_key`. Remind the user revoke_api_key refuses to revoke
  the calling key; they'll need to mint a replacement first.

## Don't

- Don't paste the entire raw event dump into the response. The audit log
  contains IPs and metadata that the user might not want logged in their
  session transcript. Show the summary; let them re-run with `limit: 5`
  if they want raw rows.
- Don't volunteer to call `revoke_api_key` or `delete_workspace` based
  on this review without an explicit confirmation. The audit-review
  prompt is read-only by design.

{{include: _shared/output-language.md}}