Access control
Restrict who can trigger chat analyses on which projects, and how chat identities map to SigSentry users
By default, anyone in a chat workspace where SigSentry is installed
can run /sigsentry analyze against any of your tenant's projects.
That's fine for small teams. As you scale, you'll often want
project-level restrictions — for example, only the billing team
can trigger analyses on the billing project.
How identity mapping works
When a chat user runs /sigsentry analyze, SigSentry needs to know
who they are in your tenant. The mapping uses email:
| Step | What happens |
|---|---|
| 1 | Chat platform passes the user's email to SigSentry |
| 2 | SigSentry looks up a user with that email in the tenant |
| 3 | If found, the analysis is attributed to that user |
| 4 | If not found, the analysis is attributed to the workspace installer |
| Platform | Email visible to bot? |
|---|---|
| Slack | Yes (with users:read.email scope) |
| Teams | Yes |
| Google Chat | Yes |
| Discord | No by default — privacy choice on Discord's side |
For Discord, the analysis runs but is attributed to the installer rather than the actual triggering user. This affects audit log attribution but not the analysis itself.
Project access lists
A project access list is the explicit allowlist of users who can trigger chat analyses for that project. Configure it under Project → Channels → Access list.
If the access list is empty, all team members can trigger analyses on the project. If it has at least one user, only those users can.
This means there are two states:
| Access list | Who can trigger from chat |
|---|---|
| Empty | Any team member |
| Non-empty | Only listed users |
There's no "deny" mode — only an allowlist.
Setting up an access list
Add the right users to your tenant first
If a user isn't a SigSentry user, you can't add them to the access list. Invite them under Team → Invite user if needed.
Open the project access list
Under Project → Channels, scroll to the Access list section at the bottom.
Add users
Pick from the dropdown of team members. The dropdown only shows people in your tenant.
| Field | Notes |
|---|---|
| User | Pick from team members |
You can add multiple users; click Add for each.
Verify
Have one of the listed users run /sigsentry analyze from chat.
The analysis should run. Have an unlisted user try — they should
see "User not authorized" with a help link.
Channel-level project bindings
In addition to access lists, you can pin a chat channel to a specific project. Under Settings → Integrations → Connected workspaces → channel-bindings, map a chat channel ID to a SigSentry project ID.
When users in that chat channel run /sigsentry analyze without a
--project=<slug> flag, the bot resolves the bound project
automatically.
| Use case | Setup |
|---|---|
#api-incidents Slack channel always works on the api project | Bind #api-incidents → api project |
#billing-alerts always on the billing project | Bind #billing-alerts → billing project |
| Default to the tenant's default project | Don't create a binding |
Audit trail
Every chat-triggered analysis is logged in the Audit log with:
- The chat platform (Slack, Teams, Discord, Google Chat)
- The chat user identity (mapped or installer)
- The project and analysis ID
- Timestamp
This is searchable under Team → Audit log.
Recommended setup for production
For most production teams:
- Per-project access lists for sensitive projects (billing, internal admin)
- Open access (empty access list) for the default and shared projects
- Channel bindings for any channel where you don't want users
typing
--project=<slug>every time
This combination keeps the noise floor low without making the bot hard to use.