Secure Sentry access for AI agents

Through Sentry, agents can look up organizations and projects, search issues and events, pull up a specific issue/trace/span, and kick off Seer's automated root-cause analysis – useful for triage and debugging without giving an agent free rein to resolve, ignore, or reassign issues on its own. Every call runs through your policies and is logged for audit.

Server URL: https://mcp.sentry.dev/mcp

Credential modes

Sentry supports per-org dynamic registration only, so there is no app to create on Sentry's side and no client ID or secret to enter. See Credential modes for how it compares with Use SecureAuth's app and Bring your own app.

Before you begin

• A Sentry account that can reach the organizations and projects your agents need.
• Administrator access to your Agent Authority workspace, to add the resource.

Setup

1. In the Agent Authority console, go to Resources and click Add Resource.
2. Select Sentry from the catalog.
3. On Choose how to install Sentry, click Per-org dynamic registration. Selecting it adds the resource right away with its tools pre-configured.

Dynamic client registration

When you add the resource, the gateway registers its own OAuth client with Sentry – the credential that lets it sign users in. Sentry's own organization, project, and team permissions still apply, so an agent can only reach what the person who signed in could already reach.

Verify the connection

The gateway syncs the Sentry tools automatically. To check the connection end to end, ask your agent to run a request:

List my Sentry organizations

If your organizations come back, the connection is working.

How users connect

Access is per user. Each additional user connects their own Sentry account the first time their agent calls a Sentry tool: the gateway returns a sign-in link, the user authorizes once, and the tools work from then on. Go to Connections to manage linked accounts.

Users sign in to Sentry directly, through your SSO provider if your Sentry organization uses one. Sentry then shows an authorization screen headed SecureAuth AI Gateway is requesting access to Sentry, with four permission groups already selected:

• Inspect Issues & Events – read-only access to issues, events, traces, replays, releases, monitors, profiles, and project metadata
• Seer – Sentry's AI debugger, for root-cause analysis
• Triage Issues – resolve, assign, and update issues
• Manage Projects & Teams – create and modify projects, teams, and DSNs

Selecting Approve grants all four and returns the user to the gateway with the account connected.

Available tools

Two of these deserve a second look before you allow them broadly: update_issue is the one tool that mutates issue state, and execute_sentry_tool can run any tool search_sentry_tools surfaces – including long-tail write operations not listed above – so denying it is the only way to be sure no Sentry write reaches an agent.

Required scopes

The gateway does not request a fixed scope list for Sentry. It registers the client without naming any scopes and records the ones Sentry returns.

Sentry decides the scopes instead, and presents them as the four permission groups described in How users connect. Approving all four grants the connection more in Sentry than the nine tools above expose, because Manage Projects & Teams covers creating and modifying projects, teams, and DSNs. Use policies to control what agents can call – the scopes granted at authorization stay as granted.

Policy examples

Rules are evaluated top to bottom and the first match wins. Allow rules on their own restrict nothing – your org starts with a seeded Allow all rule, so any tool your allows don't cover still falls through to it. Narrowing access needs a catch-all deny scoped to this resource, ordered below the allows. See Policies.

• Read-only Sentry for everyone. Deny update_issue and execute_sentry_tool scoped to this resource, above the seeded Allow all rule. Reads (find_*, search_*, get_sentry_resource, analyze_issue_with_seer) keep working.
• Scope one agent to issue triage. Deny * scoped to this resource and to that agent, then allow find_organizations, find_projects, search_issues, search_events, get_sentry_resource, and analyze_issue_with_seer above the deny – ordered above it, since new rules insert at the top and evaluation is first-match-wins.

Next steps

• Create a policy – start from the read-only pattern in Policy examples above.
• Policies – how rule order, scoping, and the seeded Allow all rule interact.
• Connections – manage the Sentry accounts your users have linked.