Access list
Restrict which users can run analyses against a specific project from chat triggers
By default, any team member can run an analysis against any project from a chat command. The access list lets you tighten that on a per-project basis — useful for projects containing sensitive logs or expensive (e.g., very high log volume) workloads.
How it works
When the access list is empty, all team members can target this project from chat. When the list has at least one entry, only listed users can target this project.
The restriction applies to:
- Chat commands — Slack, Teams, Discord, Google Chat
- Support desk auto-triage when triggered by an internal user
- API requests authenticated as a specific user (JWT)
It does not apply to:
- API keys — they carry their own permission scope
- Watchdog auto-runs — those are system-initiated
- Dashboard access — controlled by team roles, not the access list
Where to manage it
Project → Settings → Access list. Add team members one at a time from a typeahead. Remove with the trash icon.
Only admins and the owner can edit the access list.
Example: locked-down billing-data project
The "Billing" project has logs containing customer payment metadata. You want only the finance ops team to run analyses against it.
Add the finance ops users to the access list
Project → Settings → Access list → Add user. Add each finance ops team member.
Verify other users see the lockout
Anyone not on the list typing @SigSentry analyze ... --project=billing
in chat will get a "You don't have access to this project" response.
Owners and admins are not auto-included
Even an admin must be explicitly added to the access list — there's no implicit override. This avoids surprise access for new admins.
When to use it
| Scenario | Use access list? |
|---|---|
| Sensitive logs (PII, payments) | Yes |
| Expensive log sources you don't want casually queried | Yes |
| Production project where casual analyses might consume quota | Maybe |
| Internal tooling project where everyone should have access | No |
| Sandbox / staging | No |
Removing yourself
A user can remove themselves from a project's access list. They lose chat access immediately. Re-adding requires an admin.