Documentation Index
Fetch the complete documentation index at: https://docs.crewship.ai/llms.txt
Use this file to discover all available pages before exploring further.
Audit Log
Crewship maintains an append-only audit log that records every mutation in the system. The audit log provides a complete trail for security review, compliance, and debugging.What Is Audited
Theaudit_logs table currently captures these mutations. Other
entities (crews, missions, credentials) emit journal events but do
not yet have WriteAuditLog calls wired into their handlers:
| Category | Actions | Source |
|---|---|---|
| Agents | create, update, delete | internal/api/agents_create.go, agents_update.go, agents_query.go |
| Backups | backup.create, backup.restore, backup.unlock, backup.rotate, backup.delete, backup.download | internal/api/backup.go, backup_admin.go |
keeper_requests table (see below), not in audit_logs.
Keeper Decision Auditing
Keeper security decisions are stored in thekeeper_requests table with detailed fields:
| Field | Description |
|---|---|
intent | The agent’s stated reason for access |
request_type | access (credential read via /keeper/request) or execute (command run via /keeper/execute) |
command | Shell command (for execute requests) |
decision | ALLOW, DENY, or ESCALATE |
reason | LLM-generated explanation |
risk_score | Numeric risk assessment (1-10) |
ollama_prompt | Full prompt sent to the Keeper LLM |
ollama_raw_response | Raw LLM response for review |
Audit Log Table Structure
| Column | Type | Description |
|---|---|---|
id | TEXT | Random hex ID (32 chars) |
workspace_id | TEXT | Workspace the action occurred in |
user_id | TEXT | User who performed the action (null for system actions) |
action | TEXT | Action type — CRUD verbs (create, update, delete) for agent mutations, backup.* for backup lifecycle events |
entity_type | TEXT | Entity type (AGENT, CREW, MISSION, etc.) |
entity_id | TEXT | ID of the affected entity |
metadata | TEXT | JSON object with action-specific details |
ip_address | TEXT | Client IP address |
user_agent | TEXT | Client user agent string |
created_at | TEXT | ISO 8601 timestamp |
Querying the Audit Log
GET /api/v1/audit
Required role: OWNER or ADMIN (manage permission)Query Parameters
| Parameter | Type | Default | Description |
|---|---|---|---|
page | integer | 1 | Page number (1-based) |
limit | integer | 50 | Entries per page (1-100) |
action | string | Filter by action (e.g., create, delete) | |
entity_type | string | Filter by entity type (e.g., AGENT, CREW) | |
entity_id | string | Filter by specific entity ID | |
user_id | string | Filter by user who performed the action | |
date_from | string | ISO 8601 start date | |
date_to | string | ISO 8601 end date |
Response
user_email and user_name joined from the users table for convenience.
Pagination
The audit log uses offset-based pagination:- Default limit: 50 entries per page
- Maximum limit: 100 entries per page
- Minimum limit: 1 entry per page
- Pages are 1-based (page 1 is the first page)
Example Queries
- All agent deletions
- Actions by a specific user
- Recent activity (date range)
How Audit Entries Are Written
Audit entries are written synchronously during mutation handlers using theWriteAuditLog function (defined at internal/api/internal_handler.go:51):
j is non-nil — dual-emits a typed audit.entity_* entry into the unified Crew Journal. If the write fails, a warning is logged but the original operation is not rolled back — the audit log is best-effort to avoid blocking user operations.
What’s Next
Admin API
Keeper audit log endpoint and workspace administration.
RBAC
Role-based access control that determines who can view audit logs.