Access Audit Trail
Review who changed access to what, when, and why in your Devpilot workspace.
Access Audit Trail
The access audit trail is an immutable log of every access-related change in your Devpilot workspace — who requested access, who granted or revoked it, which role was involved, and when it happened. Use it to investigate incidents, prove compliance during access reviews, or simply understand how a member came to have the access they have today.
The audit trail is read-only. Entries cannot be edited or deleted, and every authorized access change is recorded automatically the moment it happens.
Who Can View the Audit Trail
Workspace Owners and Admins can view the audit trail. Members do not see it.
The trail is scoped strictly to the current workspace — audit entries from one workspace never leak into another, even for users who belong to both.
What Gets Tracked
Devpilot writes an audit entry whenever one of the following actions happens:
| Action | When it fires |
|---|---|
granted | A member was given a resource-level role (directly, via an accepted invitation, or via an approved access request). |
revoked | A member's resource-level access was removed. |
modified | A member's existing role on a resource was changed to a different role. |
requested | A member submitted an access request. |
approved | An Owner or Admin approved an access request (if the request named a specific resource, the matching granted entry is written too). |
rejected | An Owner or Admin rejected an access request. |
Every entry belongs to exactly one workspace and references the member whose access changed, the resource involved, and the actor who performed the change.
Opening the Audit Trail
Open Your Workspace
Navigate to the workspace whose access history you want to review.
Go to Team and Then Audit Trail
From the Team area, open the Audit Trail tab. Entries are sorted newest first and paginated (15 per page by default, up to 100 per page).
Filter the Results
Narrow the list using the filters in the toolbar. Filters combine, so you can (for example) ask for every revoked event on Project #42 between two dates.
| Filter | What it does |
|---|---|
| Member | Show only events for a specific workspace member. |
| Resource type | Limit to one resource kind — workspace, server, project, app, or artifact. |
| Resource | Limit to a specific resource id within the chosen type. |
| Action | Keep only events with a given action (granted, revoked, modified, requested, approved, rejected). |
| From / To date | Restrict to a date range. From alone, To alone, or both are accepted. |
What Each Audit Entry Shows
Every entry in the trail contains the following fields:
| Field | Meaning |
|---|---|
| Action | The access-related action that occurred (granted, revoked, modified, requested, approved, rejected). |
| Member | The workspace member the action affects, with the linked user record (name, email). |
| Resource type | One of workspace, server, project, app, artifact. |
| Resource id | The specific resource the change applies to (may be empty for workspace-wide entries). |
| Old role | The resource-level role before the change — one of admin, collaborator, viewer, or empty when the action is a create. |
| New role | The resource-level role after the change — one of admin, collaborator, viewer, or empty when the action is a delete. |
| Performed by | The Owner, Admin, or system actor who made the change. |
| Description | A short auto-generated sentence summarising the change (for example, "Granted Jane collaborator access to project #42"). |
| IP address | The IP address of the reviewer's session when the change was made, if captured. |
| User agent | The browser / client user-agent string from the actor's request. |
| Access record | A link back to the underlying workspace access record created or deleted by the event, when applicable. |
| Timestamp | The exact time the event was recorded. |
Entries tied to an access request carry a link back to that request so you can jump from the audit entry to the approval or rejection that triggered it.
Common Investigations
Filter by Member and sort by newest. The latest granted, approved, or modified entry against the resource of interest shows exactly when and by whom the access was given, including whether it came from a direct grant, an accepted invitation, or an approved access request.
Filter by Member and Action = revoked. The result is a timeline of every access this member has lost, with the performer, the resource, and the role they previously held recorded on each row.
Filter by Resource type = project and the specific project id. You will see every grant, revoke, and modification on that project regardless of member, so you can reconstruct its access history end to end.
Filter by From / To date narrowed to yesterday. Combine with Action if you want to focus on a specific class of change (for example, only approved and rejected to audit review decisions).
Example Entries
A typical audit row looks like this in plain English:
granted— "Granted Janecollaboratoraccess to app #17" by Admin Sarah.modified— "Changed Jane access to project #5 fromviewertoadmin" by Owner Alex.approved— "Approved Jane request foradminaccess to server #2" by Admin Sarah (followed by a pairedgrantedentry for the same resource).revoked— "Revoked Janecollaboratoraccess to project #5" by Admin Sarah.
The auto-generated description is included so you can scan the trail quickly without expanding every row.
Retention and Compliance
- Retention. Audit entries are retained for the lifetime of the workspace. Deleting a member or a resource does not delete their audit history.
- Immutability. No UI or API route exists to edit or delete audit entries. Even Owners can only read them.
- Scope. The trail captures workspace-role assignments (Owner, Admin, Member changes are logged through member-management actions) as well as resource-level role changes for servers, projects, apps, and artifacts.
- Paper trail for reviews. Pair the audit trail with the access requests list when running periodic access reviews — one shows who asked, the other shows what actually happened.
The audit trail shows access changes, not every action a user performed. For a view of deployments, project edits, and similar per-action activity, use Team analytics instead.
Tips
- Export before investigating at scale. Long-range compliance investigations are faster with a CSV or JSON export of the relevant slice — filter first, then export so the file stays small.
- Correlate IP addresses. When multiple admins share responsibility, the IP address and user-agent fields help narrow down which session made a change.
- Use
modifiedto spot privilege escalation. Anymodifiedentry whose new role isadminis worth a second look — especially on production servers and projects.
Next steps
Access requests
Approve, reject, and cancel workspace access requests.
Roles and permissions
Understand the workspace and resource-level roles that appear in the trail.
Team management
Add, remove, and adjust members whose access shows up in audit entries.
Team analytics
See activity metrics that complement the access-only view of the audit trail.