> For the complete documentation index, see [llms.txt](https://shinkalabs.gitbook.io/hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shinkalabs.gitbook.io/hub/andromeda/guides/audit-log.md).

# Audit log

Every tenant has an append-only audit log: a hash chain of the actions taken with its API keys, where each entry is signed by an ed25519 key held in a KMS. You can fetch it and verify it cryptographically without trusting Andromeda's word for it.

{% hint style="info" %}
Audit-log endpoints require an API key with the `admin` scope. Exact request and response bodies are in the [OpenAPI spec](https://api.andromedainfra.pro/openapi.json).
{% endhint %}

## What is recorded

Actions like policy changes, recovery actions, future-sign arming, webhook configuration changes, and idempotency replays. Each entry has an event type, the resource it concerns, the actor (which API key), a payload, and its place in the chain.

Payloads are sanitised before they are written: only an allowlist of keys is kept, and string values are clamped to a bounded length. The log never contains secrets, raw signatures, or unbounded user data.

## Fetching it

Query the log for your tenant (with the `admin`-scoped key), optionally filtered by time, event type, or resource. You get back the entries plus enough information to verify them.

## Verifying it

The log is a hash chain: each entry commits to the previous one, and each entry is signed by the tenant's audit key. To verify:

1. Fetch the entries.
2. Recompute the chain: confirm each entry's "previous" hash matches the hash of the entry before it. A break means an entry was removed or altered.
3. Verify each entry's ed25519 signature against the published audit public key. A bad signature means an entry was forged or tampered with.

If both checks pass for the whole range, you have proof that the log is complete and unmodified for that range, regardless of whether Andromeda is honest.

## Why this matters

* **Compliance.** You can hand an auditor a log and a verification procedure that does not require trusting the service.
* **Incident response.** A tamper-evident record of what happened, in order.
* **Detecting a bad actor.** A break in the chain or a bad signature is unambiguous evidence.

## Related

* [Webhooks](/hub/andromeda/guides/webhooks.md) push these events as they happen.
* [Idempotency keys](/hub/andromeda/guides/idempotency.md): a replayed request is one of the recorded event types.
* [Key management](/hub/andromeda/security/key-management.md): where the audit signing key lives.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://shinkalabs.gitbook.io/hub/andromeda/guides/audit-log.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.