Audit logs
Track administrative and account activity in your org — what happened, who did it, and when.
What gets logged
Once audit logging is turned on, the audit log records administrative and account activity in your organization. It's append-only — entries cannot be modified. The log captures:
| Category | Examples |
|---|---|
| Organization settings | Organization updated, SSO configured or disabled, SCIM token regenerated, audit logging turned on, org skill library updated |
| Members | Member added to the organization, member removed |
| Teams | Team created, updated or deleted, team members added, changed or removed, team ownership transferred, team permissions and skill store settings updated |
| Domains | Domain added, verified or removed |
| Skills | Skill installed or removed |
| Connections | Connection updated, moved or removed |
| Assistants | Assistant created, updated or deleted |
| Files | File uploaded, updated, shared or deleted |
| API keys | API key created, revoked or deleted |
| Sign-ins and messages | User sign-ins, and messages sent or generated by assistants |
Each entry records the time, the actor (an email address, or "system"), the action, the type of thing it affected, and — where relevant — extra detail such as which fields changed.
Audit logging is off until an org admin turns it on. Activity that happens while it is off is not recorded.
Availability
Audit Logs is an Enterprise plan feature.
Browsing the log
Go to Organization → Audit Logs. At the top, a toggle turns Audit logging on or off. Below it, the table shows the events, 25 per page, with these columns:
- Time — when the action happened
- Actor — who did it
- Action — a short identifier such as
member.provisioned - Entity type — what kind of thing it affected, such as
team
Click a row that has a chevron to expand the extra detail recorded for it.
Click Filters to narrow the list by actor email, action, entity type, and an After / Before date range.
Delivering logs to your own S3 bucket
For long-term retention or SIEM integration, you can have the platform copy your logs into a bucket in your own AWS account. Click the gear icon next to the toggle to open S3 Delivery Settings.
The screen walks you through a one-time AWS setup: create an IAM role in your account with the trust policy and permission policy shown there (both can be copied), then enter:
- S3 Bucket ARN — the bucket to deliver to (it must already exist)
- IAM Role ARN — the role you created
- Region — the bucket's region
- Path Prefix — the folder for the logs (defaults to
agnt-audit-logs)
Click Save. Delivery only needs s3:PutObject on your bucket.
Once audit logging is on and delivery is configured, a Deliver logs section appears. Pick a From and To date (leave them blank to deliver the last 30 days) and click Deliver. The screen shows the job's progress and how many files were copied. Delivery is on demand rather than scheduled.
Files arrive as newline-delimited JSON (.jsonl), one event per line, organized by date under your prefix, in folders like year=2026/month=09/day=29/. Redelivering the same range is safe, and if you process the files programmatically, de-duplicate on the event ID.
Retention
The Audit Logs page shows events from the last 30 days. S3 delivery is how you get older history out — manage how long you keep it there with your own S3 lifecycle policies.
There is no way to extend the 30-day window shown in the dashboard.
Compliance use cases
The audit log is designed to support common compliance requirements:
SOC 2 — the log provides evidence of access control changes and administrative activity. Deliver the entries for the audit period to your bucket to share with auditors.
HIPAA — if your org processes protected health information, the audit log documents who had administrative access and when it changed.
GDPR / data deletion — member removal and related events in the audit log can serve as evidence that a request was actioned.
The audit log is a record of administrative and account events, not a per-access log of who read which record.