Team Management

Abuse prevention best as a team effort. Dregs supports multiple users on a team with role-based access so everyone has the right level of control. Analysts investigate day-to-day scoring and alerts, and admins manage the team and infrastructure.

Roles

Three roles control what each team member can see and do. Every user is assigned exactly one role, and permissions are enforced across both the dashboard and the API.

Admin

Full access to everything. Admins manage the team, configure alert rules and badge rules, create and manage notification channels, maintain datasets, and control API credentials. They can invite new members and assign roles. If something can be configured in Dregs, an admin can do it.

Every team starts with one admin — the person who created the account. At least one admin must exist at all times; the last admin on a team cannot delete their account or be downgraded.

User

Standard operational access. Users can browse the dashboard, view identities, devices, and events, and manage alerts (acknowledge and close them). They can view settings but cannot modify rules, channels, credentials, or team membership.

This is the right role for analysts who need to investigate suspicious activity and triage alerts but should not be changing how the system is configured.

Invitations

Admins invite new team members by email address. When you send an invitation, the recipient receives an email with a link to create their account and join your team. The invitation includes the team name so they know what they are joining.

Pending invitations are visible in the Team section of Settings. If someone has not accepted their invitation yet, you can revoke it. Once accepted, the invitation is consumed and the user appears in your team roster.

Invited users register with their own password and profile information. You choose their role at invitation time, and it can be changed later by any admin.

API Credentials

API credentials are the key pairs that authenticate the tracking script and any server-side integrations with the Dregs API. Each credential consists of:

• Public key — a token that identifies your account. This is safe to embed in client-side code like the tracking script, since it cannot be used to read data or make changes on its own.
• Secret key — a private token used for server-side API calls. Keep this out of client-side code. Anyone with the secret key can access your account's data through the API.
• Allowed origins — the domains that are permitted to use this credential from a browser. This prevents someone from copying your public key and using it on their own site to send junk data into your account.

Credentials can be enabled or disabled. Disabling a credential immediately stops it from authenticating requests without deleting it — useful when you suspect compromise and need to cut off access quickly while you investigate.

You can also revoke credentials permanently. A revoked credential cannot be re-enabled. Create a new one to replace it.

Security Best Practices

A few recommendations for keeping your Dregs account secure:

• Use separate credentials for each environment. Create distinct key pairs for development, staging, and production. This way, if a development credential leaks, your production data is unaffected.
• Restrict allowed origins. Set the allowed origins on each credential to only the domains that actually need it. Do not use wildcards in production.
• Keep secret keys server-side. The public key goes in the tracking script. The secret key goes in your backend environment variables. Never commit secret keys to version control or include them in client-side bundles.
• Rotate credentials if you suspect compromise. Create a new credential, update your integrations to use it, then disable the old one. The transition can be seamless if you update the tracking script and backend configuration before revoking the old key.
• Limit admin access. Most team members should be ordinary users. Only people who need to manage credentials, rules, and team membership should be Admins.