# Set up Enrich Security Alerts

This is a read-only composite, but it needs a model credential and every listed data source configured before it can run. Set up isolated test accounts or workspaces first, grant only the smallest read scope that exposes the test data, and store every credential only in Dome's secret inputs. Never put a key or secret in this repository, an agent prompt, or a chat message.

## Create the model credential

- Create an API key in the [Anthropic Console](https://console.anthropic.com/settings/keys).
- Enter the raw key as `anthropic_api_key` during import. Do not prepend `Bearer `.
- The template uses that key only for its managed `claude-sonnet-5` model connection.

## Create the provider credentials

- `slack_oauth_client_id`: A Slack app client ID.
- `slack_oauth_client_secret`: The Slack app client secret.
- `github_oauth_client_id`: The Client ID of a GitHub OAuth app registered with Dome's callback URL.
- `github_oauth_client_secret`: The client secret for the GitHub OAuth app.

For a provider that asks you to register a manual OAuth app, use this callback URL exactly:

`https://api.domesystems.ai/oauth/callback`

## Set up each connected provider

### Datadog

This provider uses Dynamic Client Registration (DCR). Do **not** create or paste an OAuth client ID or client secret: after import, Dome registers the client and opens the provider's consent page.

Before starting OAuth, a Datadog organization administrator must open
**Organization Settings → MCP OAuth Redirect URLs** and add this exact URL:

`https://api.domesystems.ai/oauth/callback`

Datadog rejects the consent flow with **Mismatching redirect URI** until that
allowlist entry exists. Dome uses Dynamic Client Registration, so no separate
Datadog OAuth client or client secret is needed. Dome requests Datadog's
published `mcp_all` scope during consent.

Before connecting, an organization administrator must also enable **MCP Access**
in Datadog. The authorizing test user needs **MCP Read** and the underlying
resource permissions (for example, Monitors Read); custom roles need those
permissions added explicitly. This composite starts with Datadog's generally
available `core` toolset. Add the Preview `apm` toolset only after obtaining
Datadog's APM Preview access.


After saving, complete OAuth with a test user that has read access only to the selected services, logs, and dashboards. This composite targets US1 and uses the `core` toolset.

### Sentry

This provider uses Dynamic Client Registration (DCR). Do **not** create or paste an OAuth client ID or client secret: after import, Dome registers the client and opens the provider's consent page.

After saving, complete OAuth with a test user that can view only the target organization and projects. Use project-scoped Sentry access wherever available.

### Slack

Before import, create a Slack app at [api.slack.com/apps](https://api.slack.com/apps). Choose **From scratch**, make it internal to the intended workspace, then copy the client ID and client secret from **Basic Information**. In **OAuth & Permissions**, add `https://api.domesystems.ai/oauth/callback` as a redirect URL. In **Agents**, enable **Slack Model Context Protocol (MCP) Server**. Add only the read/search/history/channel/user scopes requested by this template; do not add any write scope. Install or reinstall the app to the dedicated test workspace after changing scopes.

- `slack_oauth_client_id` and `slack_oauth_client_secret`: enter values from an approved internal Slack app.

In the Slack app's **Agents** section, enable the **Slack Model Context Protocol (MCP) Server** feature. Register Dome's redirect URI and grant only the template's search, history, channel, user, canvas-read, and list-read scopes. Do not add `chat:write`, file-write, canvas-write, or other write scopes.

### GitHub

GitHub's hosted MCP server supports OAuth, but does not expose Dynamic Client
Registration. Before import, create a GitHub OAuth app in the
[GitHub developer settings](https://github.com/settings/developers): select
**OAuth Apps**, then **New OAuth App**. Use a recognizable name, your
organization's homepage URL, and this callback URL:

```text
https://api.domesystems.ai/oauth/callback
```

After creating the app, copy its client ID and generate its client secret.
GitHub's [OAuth-app creation guide](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app)
has the current field-by-field instructions.

- `github_oauth_client_id` and `github_oauth_client_secret`: enter the GitHub
  OAuth app credentials. Configure the app's callback URL as
  `https://api.domesystems.ai/oauth/callback`.
- After import, start the shared GitHub OAuth connection and approve it as a
  dedicated test user. The template requests `public_repo` and `read:org`, and
  connects to GitHub's read-only MCP endpoint. This permits public-repository
  investigation while preventing the MCP server from exposing write tools.
- Before relying on the connection, verify the consent scopes and organization
  OAuth-app policy, then test one allowed public repository. GitHub OAuth does
  not have a read-only private-repository scope: do not grant `repo` merely to
  make this composite work. Keep repository administration, workflow, package,
  and organization-write access out of the authorization.

For a headless connection, use the separate fine-grained-PAT configuration and
limit it to the intended repositories with read-only permissions.

### GitLab

This provider uses Dynamic Client Registration (DCR). Do **not** create or paste an OAuth client ID or client secret: after import, Dome registers the client and opens the provider's consent page.

GitLab.com supports OAuth 2.0 Dynamic Client Registration for its hosted MCP
server, so this composite does not require a manually registered application or
an access token.

- After import, complete shared OAuth as a dedicated test member. The template
  requests GitLab's `mcp` scope; verify a known test project is
  visible and that an unshared private project is unavailable.

This composite targets GitLab.com. For a headless connection, use a separate
project, group, or personal access-token configuration with the same read-only
scopes. Use a separately reviewed template for a self-managed instance or a
write-capable workflow.

## Import and verify

1. Import the template and provide the values above.
2. Complete every browser OAuth flow with the intended dedicated test user. Token-based sources do not open a browser.
3. Open **Tools**, refresh discovery, and confirm every connection is attached to the template gateway.
4. Run the managed agent against known test data. Treat the template as verified only when the run succeeds **and calls at least one expected read-only tool**.

If a connection is unreachable, check the provider section above for its callback, API/MCP enablement, token prefix, consent scopes, and user/workspace access before retrying.