Audit trails
Three systems keep records of who did what: the Organisations console keeps an audit log of administrative actions, the AlphaAgent Console keeps an audit log of licence events, and each Studio deployment keeps per-run records and usage rows rather than a single audit screen. This page says what each records, where it lives, how long it stays, and how you get it out.
Who this is for
Security and compliance engineers assembling evidence, and administrators answering "who changed this".
Before you start
The Organisations audit log is the one you will use most. It is reachable by an Organisations administrator (an owner, operator or viewer, or a holder of a role that grants audit reads). Studio has no audit screen of its own; its records are reached through the Organisations console, the programmatic API and your own AWS account.
Organisations audit
Administrative actions taken through the Organisations console and by the engine write rows to the alphaagent-org-audit table in your Organisations account. The table is partitioned by day, has point-in-time recovery, is encrypted at rest, and expires rows after 400 days.
The action names a row carries:
| Area | Action names |
|---|---|
| Roles and access | role.grant.created, role.grant.archived (a revocation), and the console access assignments made alongside them |
| Accounts | account.allowed_regions.updated |
| Deployments | deployment.upgrade.triggered, deployment.reconfigure.triggered, deployment.rollback.triggered, deployment.ecs.pause, deployment.ecs.resume, deployment.seat_cap.exceeded |
| Programmatic access | apikey.created, apikey.updated, apikey.rotated, apikey.external_id_rotated, apikey.revoked, apikey.expired, apikey.materialised, apikey.deleted, and apikey.run_data_purged when a key erases a run |
| Identity providers | platform_config.entra.credentials_updated |
| Libraries | library.item.deleted; every share and pull outcome is written as a transfer record on the Library (kept 90 days, shown as the Library's Activity) |
Job progress (each step's outcome, parked steps and the decisions taken on them) is recorded in the job's own event stream and shown on the job page rather than in the audit table.
The Audit screen filters by actor (an exact email, or a worker id for actions the engine took), a From and To date in UTC (default the last seven days), and an exact action name, fifty rows per page, with columns When, Who, Action and Target.
Getting records out: there is no export button on the screen. GET /audit?from&to&actor&action&limit&cursor on the Organisations API returns the same rows as JSON, up to 200 per page across a window of at most 90 days, with a cursor for the next page. Because the table is in your account, you can also read it directly with your own AWS credentials, or export it with DynamoDB's export to S3.
Console licence audit
The AlphaAgent Console writes one audit event for every licence operation that crosses a trust boundary: licence created, token regenerated, licence revoked, activation received, each heartbeat received (with a warning severity when the verdict was invalid), each five-minute period missed, each usage batch accepted, and every enforcement change an operator makes. Events carry the licence id, the event type, a timestamp and small structured details; they never carry a secret or a token.
Where it lives: a table on the Console side, read through GET /v1/license-keys/<licence id>/audit and shown on the licence's page in the Console. Where the Console's audit pipeline is configured with it, an immutable copy is written to S3 with Object Lock in compliance mode with a seven-year retention.
Studio records
Studio keeps records per object rather than one log:
| Record | Where | What it answers |
|---|---|---|
| Run events and board | alphaagent-execution-run-events and alphaagent-runtime-graphs, and GET /api/v1/runs/{run_id}/events for key-triggered runs | Every step, tool call and decision in a run; who approved a gate and when |
| Code executions | alphaagent-code-executions, 30 days | Each sandbox execution with its truncated output |
| Programmatic API usage | USE# rows in alphaagent-api-keys, 90 days | Every request a key made: method, path, status, source address, reason for a refusal; rolled up hourly in the Organisations console |
| Usage events | alphaagent-runtime-metering-outbox, mirrored into your Organisations account every 120 seconds | Which principal caused which model call, by kind and model; shown as the deployment's usage in the Organisations console |
| Inbox activity | alphaagent-activity, 24 hours | Live run cards; not an audit record |
| Service logs | CloudWatch Logs, default 30 days | Request and error logs per service |
Records of your AWS account's own actions on the deployment (role assumptions by the engine and by sandboxes, secret reads, table access) are CloudTrail's, and CloudTrail is yours to enable; see Shared responsibility and best practices.
Steps: pull an audit extract
- In the Organisations console, open Audit, set the actor or action and the date range, and page through the rows.
- For a machine-readable copy, call
GET /auditon the Organisations API with the same filters and follownext_cursoruntil it is empty. - For a licence, open it in the AlphaAgent Console and read its audit list, or call
GET /v1/license-keys/<licence id>/audit. - For one workflow run, call
GET /api/v1/runs/{run_id}/eventswith a key that holdsruns:read, followingnext_after_seq. - For the deployment's model usage, open the deployment in the Organisations console and read Health and analytics, grouped by model or by kind.
What you should see
- Every grant, revoke, key lifecycle change and triggered upgrade, reconfigure or rollback as a row with an actor, an action and a target.
- Heartbeats on the Console every five minutes and no missed periods while the deployment is healthy.
- Usage totals that agree between the deployment's view in Organisations and the licence's view in the Console.
Limits
- The Organisations audit API walks at most 90 days per call and returns at most 200 rows per page.
- Audit rows expire after 400 days. Export before then if you need them longer.
- Studio's run event replay is available for key-triggered runs on the programmatic API; runs started in Studio are inspected in Studio's run view.
- Records are counts and identifiers. No audit surface carries prompts, documents or results.
If something goes wrong
- An action you expect is missing from the Organisations audit: check the date range (UTC) and that you used the exact action name; partial names do not match.
- The Console shows missed heartbeats while Studio is running: the deployment lost outbound access to the Console; see What leaves your account.
GET /auditanswers 422: thefromortovalue is not aYYYY-MM-DDdate, or the window exceeds 90 days.