Knowing who changed what and when is essential for any team that manages secrets. dotEnv Cloud records an audit trail of significant actions across your organization so you can review activity, investigate incidents, and demonstrate accountability.
What the audit log captures
Each audit entry is scoped to an organization and records the action together with enough context to reconstruct what happened. Every entry includes:
| Field | Description |
|---|---|
| User | The member who performed the action. |
| Organization | The organization the action took place in. |
| Action | What was done, for example a create, update, or delete. |
| Model | The type and identifier of the affected resource (project, target, environment, and so on). |
| IP address & user agent | Where the request originated and the client used. |
| Context | Additional structured metadata about the action. |
| Timestamp | When the action occurred. |
Reviewing activity
Audit entries are organized per organization, so you always see activity in the context of the team it belongs to. Entries can be filtered by user, by action, by affected resource type, and by recency, which is exactly what you need when answering questions like "who deleted the production environment?" or "what changed last Tuesday?".
Roles and visibility
Audit visibility pairs naturally with the Auditor role described in Role-Based Access Control. Auditors get read-focused access for reviewing activity without the ability to change secrets, ideal for compliance and security reviewers who should observe but not modify.
Reconstructing the picture with key history
For changes specifically related to encryption, the audit trail is complemented by per-project key history. You can list every key version, see which is active, and confirm when rotations happened straight from the CLI:
Together, the organization audit log and project key history give you a complete answer to "what changed, by whom, and when", including the security-sensitive question of when keys were rotated.
Good practices
- Review the audit log regularly, not only after an incident, so anomalies surface early.
- Use distinct API keys for distinct automations so actions attribute clearly to a source.
- Pair auditing with least-privilege roles to reduce the surface that can make changes in the first place.
To keep automated changes attributable and safe, read Securing CI/CD Pipelines.