Data Privacy for Rootly AI

​

Data Access & Scope

​

What Data Does Rootly AI Access?

The conversational Rootly AI agent starts with the incident and conversation context for the request in front of it. Its available tools can fetch more data within that surface’s access boundaries, including configured connectors and recent messages in the current Slack channel. AI SRE has a separate investigation context and can start automatically without a user request. Depending on the surface, that context includes:

• In Slack: app mentions in channels where it’s been added, messages in incident channels (where Rootly creates an assistant thread automatically when it’s mentioned), DMs sent directly to the bot, the recent context of the active thread, and an active incident bridge transcript if one is attached via the Meeting Scribe.
• In the web and mobile apps: the incident you’re viewing and your conversation with it—its timeline, severity, status, roles, alerts, and (subject to your privacy settings) related Slack discussion.
• Through the Chat API: the message and optional incident or alert context supplied by the calling application, subject to the API caller’s authorization and the Chat API’s separate availability controls. See AI chat OAuth scopes.
• In AI SRE: the alert or non-maintenance incident under investigation, related Rootly context, applicable instructions, relevant active memory, and results returned by available connectors. Alert investigations can also consider the alert-specific recent operational history described below. Manual runs use the initiating responder’s Rootly authorization for Rootly-native and user-scoped access, including Private Agent capabilities. Connector queries can still use the team’s configured provider or service credentials. Automatic alert and incident investigations have no initiating responder: they use the AI SRE background identity, team-configured connector credentials and allowlists, and registered Private Agent capabilities authorized for the ai-sre system actor.
• From connectors: data fetched on demand for the investigation. With optional fact ingestion enabled, supported observability connectors can contribute derived service identities and dependency relationships; AWS can contribute account, region, and resource inventory facts; Google Cloud can contribute selected project, hierarchy, Cloud Run service, and Compute Engine instance facts; and GitHub can contribute infrastructure-as-code facts from a selected repository.

In Slack, the conversational agent can read the active thread, recent messages in the current channel for a top-level mention, and recent messages in that same channel when using its search tool. Those channel reads can call Slack’s conversations.history API. The agent does not search other channels through this tool or browse channels the Rootly app cannot access. Separately, Rootly can collect incident-channel messages under the team’s Slack history collection setting; eligible stored messages can later be used by AI SRE and Memory.

​

Does It Read History Retroactively?

The conversational agent does not run a workspace-wide historical backfill. In Slack, it can read recent messages in its current channel as described above; web and mobile chat use the incident open in the app, and Chat API uses the session and optional incident or alert selected by the caller. Rootly’s separate incident-channel history collection can store messages according to the team’s Slack history collection setting. When Memory seeding is enabled, Rootly can read those stored messages and a published retrospective from an eligible, non-private past incident to propose Memory notes. It skips incidents without a published retrospective or with Slack history collection disallowed. This path is separate from the conversational agent’s current-channel reads; see Atlas Memory. For alert investigations, AI SRE can use history that Rootly already stores: relevant active context notes, completed verdicts from the previous 30 days for related alerts, and resolution or mitigation notes from linked incidents. Earlier conclusions are supplied as hypotheses and must be rechecked against current evidence. Incident investigations can recall relevant active context notes but don’t use this alert-specific 30-day verdict lookup. See Past Alerts, Incidents and Conclusions.

​

Can We Limit Rootly AI to Specific Channels?

In Slack, per-channel scopes (for example, restricting @Rootly to #incidents-* channels) are not currently configurable. Incident Response Owners and Admins with an Incident Response seat can enable or disable the self-service Slack agent for the current Rootly team under AI SRE → Atlas → Conversations → Slack (AI & Agents → Features → Slack if your sidebar doesn’t have an AI SRE item).

​

Are DMs Covered?

Yes. In Slack, when Rootly AI is enabled, users can DM the bot directly. Rootly-native write operations such as paging or creating action items are filtered out at that surface and only work inside incident channels. A connector can expose separately governed external actions in DMs; its guide documents the required Rootly permission and provider identity. DMs honor the same Rootly access controls as everywhere else: a user can only retrieve incident data they’re already entitled to see in the Rootly web app. Connector-sourced data follows the connected provider account’s access model. For example, Devin repository tools read repositories available to the team’s service user.

​

What About Private Channels?

In Slack, Rootly AI processes events from any channel it’s been invited to, public or private. There is no separate data path for private-channel content. If your security model requires private-channel data to flow through different infrastructure, please flag to your CSM.

---

​

Data Privacy

​

Is Our Data Used to Train AI Models?

Customer data is processed in-context for each request and is not used to fine-tune base models. Rootly AI uses Claude Sonnet 4.6 from Anthropic as the default with OpenAI’s GPT-5 as a fallback. Both are accessed through a managed gateway.

​

Where Is Data Processed?

Hosted conversations and AI SRE investigations use Rootly’s infrastructure, the Rootly-managed LLM gateway, and model-provider infrastructure. SaaS connector calls originate from Rootly’s hosted connector path and go to the connected provider. Private Agent uses a separate customer-local path for AI SRE investigations and Rootly Agent conversations in Slack. The agent opens an outbound gRPC connection to Rootly for enrollment, capability registration, and capability calls, then calls allowlisted services directly from inside your network. Only the bounded results and transport metadata return to Rootly; results used in an investigation or Slack conversation can then enter the hosted AI processing path described above.

​

What Data Is Stored, and Where?

The shared AI path stores data in the following places, with derived connector facts stored only when that option is enabled:

1. Conversation history: persisted to Rootly’s database so multi-turn conversations work. Connector-specific redaction can replace raw tool results and derived responses with omission markers. See retention below.
2. Model traces: every LLM call is logged to Rootly’s evaluation and observability platform for quality monitoring and debugging.
3. Provider request logs: Anthropic and OpenAI handle request data per their standard data-use policies.
4. Derived connector facts: with optional fact ingestion enabled, Rootly stores derived connector facts in its database. Supported observability connectors can contribute service identities and dependency relationships; AWS can contribute account, region, and resource inventory facts; Google Cloud can contribute selected project, hierarchy, Cloud Run service, and Compute Engine instance facts; and GitHub can contribute infrastructure-as-code facts from a selected repository. Rootly does not store the underlying telemetry or raw query result set as part of this graph. Disconnecting a connector immediately deletes the derived facts it authored. Disabling fact ingestion stops future ingestion and scheduled refreshes but does not delete existing facts; disconnect the connector to remove them.
5. AI SRE memory: when enabled, Rootly stores context notes and their version history in its database. Private incidents and alerts linked to any private incident don’t propose, grade, or automatically activate team Memory notes. Notes already sourced from an incident that becomes private, or from an alert while it is linked to a private incident, are excluded from Memory listing, history, direct note access, and recall. For eligible public sources, proposed, active, deprecated, and quarantined notes are visible on the team-shared Memory page, and superseded versions remain accessible in History. Only active notes are available for recall. Owners and admins with an Incident Response seat can activate a proposal manually. If optional automatic activation is enabled, eligible categories can become active without human approval after at least two distinct investigations each grade the proposal 70 or higher out of 100 as strongly useful; false-positive patterns are not eligible. Automatic activation is Rootly-managed, so contact your Rootly representative to verify, enable, or disable it. Deprecating or quarantining an eligible note removes it from recall but does not delete or hide the record or its earlier versions. See Atlas Memory.
6. AI SRE investigation records: Rootly stores the investigation session, progress, gathered findings, and completed report with the alert or incident so responders can review the run. Connector-specific redaction still applies to durable session history where documented.

All PII is automatically scrubbed from outgoing prompts, and all LLM inference for Rootly AI runs in US-based infrastructure. Rootly does not currently offer region routing for teams. If this is a requirement, please contact your CSM.

​

How Long Is Conversation And AI SRE Data Retained?

Rootly AI keeps session messages for multi-turn follow-ups. After 90 days without activity, Rootly removes those messages and expires the session record. In Slack, Rootly AI’s replies and users’ prompts also live as regular Slack channel messages—Rootly stores those alongside every other message from channels where the Slack integration is active, with no automatic expiry today. Meeting Scribe transcripts (when bridge recording is on) are likewise currently retained without automatic expiry. Structured AI SRE investigation records and completed reports aren’t removed by the 90-day session-message cleanup and don’t currently have a separate configurable automatic expiry. AI SRE context notes and their version history are also durable until separately removed; changing a note to Deprecated or Quarantined prevents recall but doesn’t delete it.

​

Can We Configure Our Own Retention Window?

Per-tenant retention configuration is not currently available. The 90-day default applies to AI session messages for all tenants; it doesn’t set the lifetime of Slack messages, Meeting Scribe transcripts, structured AI SRE investigation records, or AI SRE memory.

​

Are Queries Logged for Support and Debugging?

Yes. Tool-call telemetry (which tools Rootly AI invoked, durations, outcomes) is logged to Rootly’s observability platform for support and quality monitoring. Tool arguments are scrubbed of PII before logging. Full LLM traces (prompts, completions) are logged to Rootly’s evaluation platform. A per-customer opt-out of debug logging is not currently available.

​

How Is Private Agent Data Logged and Retained?

Private Agent is an early-access path for querying customer-local resources during AI SRE investigations and Rootly Agent conversations in Slack. Its Private Connect transport has separate storage and filtering from the shared AI path described above:

• Transport records: invocation inputs, actor metadata, results, errors, and metrics are encrypted at the application layer in Rootly’s database. Terminal invocation records become eligible for scheduled deletion seven days after their last update. Cleanup is asynchronous; scheduling and backlog can delay deletion.
• Transport logs and traces: Private Connect filters invocation inputs, actor attribution, results, and errors from its request logs and transport tracing. This is a transport-specific protection, not a promise that the returned data is excluded from every Rootly log or trace.
• Downstream AI use: returned tool data can be incorporated into model context, evaluation traces, and investigation or conversation history. The shared AI logging and product-surface retention policies still apply to those copies. Deleting a Private Connect transport record does not delete downstream AI records, Slack messages, or other copies.

The seven-day transport cutoff is therefore neither a conversation retention override nor an end-to-end deletion guarantee. Restrict local namespaces, resource types, and sensitive reads before enabling access; data allowed out of the customer network can enter the AI processing path.

---

​

Encryption, Keys & BYOK

​

Does BYOK (Bring Your Own Key) Apply?

BYOK support is on the roadmap. Hosted model inference currently uses the Rootly-managed gateway and model credentials. Connector and Private Agent authentication follows the separate credential paths documented for each integration.

---

​

Cost & Usage

​

Are There Token Caps?

Yes. Each tenant has a configurable, per-minute token budget enforced server-side. The default sits in the 250,000 tokens-per-minute range. This is a generous cap to prevent abuse. When a tenant exceeds its budget, Rootly AI returns a rate-limit message and the request stops.

---

​

Access Control & Permissions

​

Does Rootly AI Respect Our Existing Rootly Roles and Permissions?

For user-initiated conversations and manual AI SRE runs, Rootly AI cannot perform a Rootly-native action the requesting user couldn’t perform themselves in the Rootly web app. Access checks happen at three layers:

• Tool-class permissions (the user’s role must allow the category of action)
• Per-field permissions (sensitive fields like incident summary require specific abilities)
• Runtime data scoping (read queries are scoped to records the user can see)

Custom roles, per-severity restrictions, per-status restrictions, and incident-level permission sets are all honored. Automatic AI SRE alert and incident investigations have no requesting user. They run with the AI SRE background identity and the tools available for background execution, plus the team’s configured connector credentials and allowlists. When Private Agent and AI SRE are enabled, registered capabilities can also run under the ai-sre system actor without an individual user’s role check or interactive approval pause. See Running an Investigation for the unattended-use boundary. Connector reads and actions can use a provider account shared by the Rootly team. They are governed by the connector’s own Rootly permission checks and the connected provider account’s access, which can differ from the requesting user’s personal provider access. See each connector guide for its exact boundary. An AI SRE investigation report is shared at the alert or incident level. Anyone who can read that alert or incident can view the completed report; its evidence isn’t re-filtered according to whether that later viewer could invoke the originating connector or Private Agent capability. Scope those evidence sources with the report’s full reader audience in mind. AI SRE Memory has a broader visibility boundary than an investigation report for eligible public sources. Members with an Incident Response seat and access to AI & Agents can view proposed, active, deprecated, and quarantined notes without a new check against whether they could invoke the originating connector or Private Agent capability; superseded versions remain accessible in History. Owners and admins with an Incident Response seat manage note status and edits. Deprecating or quarantining a note removes it from recall but does not hide or delete it. Private incidents and alerts linked to any private incident don’t participate in team Memory learning, and notes whose source becomes private are excluded from Memory listing, history, direct access, and recall. That exclusion also applies to users who can view the source incident because Memory is team-shared rather than a private, per-incident store. Automatic activation is a Rootly-managed team setting, not a self-service Memory toggle; contact your Rootly representative to verify, enable, or disable it. Treat Memory review and automatic activation as team-wide disclosure boundaries for every eligible source.

​

Who Can Configure Rootly AI?

Incident Response Owners and Admins with an Incident Response seat enable or disable self-service Rootly AI features for the current Rootly team under AI SRE → Atlas → Global and AI SRE → Atlas → Conversations (AI & Agents → Global and AI & Agents → Features if your sidebar doesn’t have an AI SRE item). Rootly evaluates that role and seat on the selected team; authority on another team in the workspace does not carry over. In Slack, Slack workspace admins control whether the Rootly app is installed, while those feature controls remain in Rootly. Rootly AI SRE uses a separate enablement path: your Rootly account team enables it for the selected team. After enablement, Incident Response Owners, Incident Response Admins, and On-Call Admins who have an Incident Response seat can manage team-wide AI SRE instructions under AI SRE → Atlas (AI & Agents → AI SRE if your sidebar doesn’t have an AI SRE item). Incident Response Owners, Incident Response Admins, and On-Call Admins can manage investigation rules without an Incident Response seat; without that seat, they append /account/ai/surfaces/investigation_rules to the Rootly app URL because the parent AI & Agents area remains seat-gated. Memory has its own role and seat requirements: owners and admins with an Incident Response seat manage note status and edits, while eligible members can view the Memory page. See Manage User Permissions for the complete matrix. Connector authorization is also evaluated on the selected team. Incident Response Owners and Admins, and On-Call Admins, can connect, reconnect, configure, and disconnect AI connectors without an Incident Response seat. Without that seat, they append /account/ai-sre/integrations to the Rootly app URL instead of entering through AI & Agents. Members of the team can view the connector catalog and connection status when that surface is enabled, but they cannot manage the accounts unless they hold one of those roles. Provider-side administrator, OAuth, or IAM requirements still apply.

---

​

Audit & Compliance

​

Are AI Actions Logged in the Audit Trail?

Yes. Rootly-native actions that a person initiates (incident updates, role changes, action item creation, paging, status page publishing) are captured in the standard Rootly audit trail and attributed to that actual user, not to a generic bot identity. An automatic AI SRE investigation has no requesting user. Rootly records the investigation and connector tool-call telemetry under the AI SRE background context rather than attributing it to the user who configured the rule. A Private Agent invocation carries the system actor ai-sre in Rootly’s invocation record and to the agent. External AI connector actions use the connected provider account. A provider-side change is not a standard Rootly audit event attributed to a requesting user; the provider’s audit history normally identifies the connected account, service identity, or local credential that performed it. For Private Agent, whether the downstream system also records the forwarded ai-sre actor depends on that capability’s implementation. Review both Rootly’s investigation record and the provider’s audit history when auditing an automatic run. Conversational transcripts (the back-and-forth between user and Rootly AI) are stored separately in conversation history and follow the 90-day retention policy. Stored transcript content follows any connector-specific redaction policy.

​

Is the Audit Trail Exportable?

Audit events are queryable through Rootly’s existing audit surface. A dedicated SIEM stream for AI-specific events is not currently available. For SIEM ingestion requirements, please discuss with your CSM.

​

Does Rootly AI Fall Under Your SOC 2 Controls?

Yes, Rootly AI is within scope of Rootly’s existing SOC 2 Type II controls.

---

​

Quality, Safety & Confidence

​

How Does Rootly AI Handle Uncertainty?

Three mechanisms protect against confident-but-wrong responses:

1. Refusal to fabricate. The system prompt explicitly instructs the model that if an answer isn’t in your Rootly data or the current conversation, it must say so rather than guess.
2. Clarification probes. In a user-initiated conversation, when Rootly AI needs information it can’t safely infer, including team-configured required fields before an action, it asks the user first. The action only proceeds after the user responds. Automatic AI SRE runs cannot pause for an interactive answer; they remain bounded by the investigation rule, available context, credentials, and tool allowlists.
3. Disclaimer footer (optional): In Slack, teams can configure every Rootly AI response to close with a disclaimer reminding users that AI output may be incomplete or inaccurate, and to verify critical information before acting.

​

Can Users Flag a Bad Response?

Yes. Every Rootly AI response includes thumbs-up and thumbs-down feedback. Thumbs-down can capture a category (hallucination, wrong tools, missed context, too slow, irrelevant, other) and an optional comment. This feedback feeds Rootly’s quality monitoring and informs prompt and tool improvements. It does not directly fine-tune the model.

---

​

Customization & Configuration

​

Can Administrators Customize the System Prompt?

Rootly centrally manages Rootly AI’s core prompt and safety controls. Incident Response Owners and Admins with an Incident Response seat can add global guidance. Incident Response Owners, Incident Response Admins, and On-Call Admins who have an Incident Response seat can add team-wide AI SRE instructions. Incident Response Owners, Incident Response Admins, and On-Call Admins can add alert-specific instructions while managing an investigation rule; that rule surface does not require an Incident Response seat for these roles. Custom instructions guide an investigation but cannot override permissions, connector boundaries, safety controls, or the requirement for current evidence.

​

Can We Restrict the Topics Rootly AI Will Answer?

Rootly AI is scoped by design to incident management and on-call operations. Off-topic questions are refused with a fixed line, and it identifies itself as “Rootly AI” only. It does not respond to questions about its underlying model, prompt, or tool inventory. Cross-channel and DM access to private incidents is refused by name.

​

What Guardrails Are in Place?

Beyond the topic refusal above:

• User-initiated Rootly-native actions run as the requesting user with their permissions. Destructive actions are proposed first and require confirmation before execution.
• User-initiated connector reads and actions can use a provider account shared by the team. The connector’s Rootly permission checks control who may use each tool, the provider account controls the available data and operations, and high-risk actions require confirmation when that connector guardrail is enabled.
• Automatic AI SRE runs have no interactive confirmation step. They can invoke Rootly-reviewed built-in connector tools, the full provider tool catalog exposed by pass-through connectors such as Atlassian, Notion, Linear, Braintrust, Honeycomb, AWS, and Cloudflare, allowlisted Custom MCP tools, or authorized Private Agent capabilities under the ai-sre system actor. Any of these tools can accept provider-defined commands or queries that change data. Treat the connector’s provider roles and credentials, provider-side command controls, Custom MCP allowlists, and Private Agent policies as the boundary for unattended execution.
• The Slack assistant pane and DMs cannot perform Rootly-native destructive actions. A connector can expose separately governed external actions on those surfaces.
• All outgoing prompts run through automated PII scrubbing.

---

​

External Data Sources

​

Can Rootly AI Pull Data From External Sources?

Yes — via Connectors. Admins can connect observability, code, docs, work tracking, feature flag, and cloud infrastructure providers, plus a publicly reachable MCP server via the Custom MCP connector using OAuth or a bearer key. Rootly AI normally fetches provider data on demand for an investigation rather than maintaining a full replica of the underlying raw data. Connector actions can come from Rootly-reviewed built-in tools, a pass-through provider’s full tool catalog, or customer-allowlisted Custom MCP tools. Each path has its own Rootly and provider-side permission boundary; provider roles, credentials, and command controls determine what an available tool can do. Conversation-history retention varies by connector. Buildkite, DeepWiki, Devin, GitHub, pganalyze, Sentry, Splunk, and Sumo Logic use redacted session history: Rootly replaces raw tool results and the response derived from them with omission markers in durable AI session history. Other connectors can retain outputs and derived responses in conversation history. Connector results can still appear in retained LLM traces used for quality monitoring. The early-access Private Agent path also stores encrypted transport records. For supported connectors, optional fact ingestion runs scheduled read-only queries. Observability connectors can store derived service identities and dependency relationships; AWS can store account, region, and resource inventory facts; Google Cloud can store selected project, hierarchy, Cloud Run service, and Compute Engine instance facts; and GitHub can store infrastructure-as-code facts from a selected repository. It does not persist the underlying telemetry or raw query result set. See Connectors for the current provider list, setup, and data-handling details. In addition to those explicit integrations, Rootly AI reads Rootly-internal data: incidents, on-call, schedules, services, severities, escalation policies, custom fields, and so on.

---

​

Integrations & Triggers

​

Can Rootly AI Be Invoked From Workflows or via API?

The conversational Rootly AI agent responds to @Rootly mentions and agent threads in Slack, the chat panel in the web and mobile apps, and requests to the Chat API. The Chat API lets an authorized application send a message with optional incident or alert context and receive a reply or stream it; it has separate availability controls. There is no built-in Rootly workflow trigger for a conversational session. Rootly AI SRE is a separate investigation surface. A responder can start it from an alert or a non-maintenance incident, and an investigation rule can start it automatically for a matching alert. Rootly’s workflow product offers separate single-turn AI tasks (Anthropic, OpenAI, Mistral) for workflow automation. These are distinct from Rootly AI.

​

Is There a /rootly Slash Command for Rootly AI?

In Slack, Rootly AI runs through @Rootly mentions, the assistant sidebar, DMs, and interactive card responses. Earlier /rootly slash commands exist for the single-turn AI features but are not entry points to Rootly AI.

---

​

Reliability & Failover

​

What happens if the LLM provider is unavailable?

Rootly offers two layers of resilience:

1. Cross-vendor failover. Each model tier in the configuration has a primary and a fallback on a different provider. Retryable errors (rate limits, overloaded responses, 5xx) automatically retry against the fallback.
2. Graceful failure. If multiple providers fail or another error occurs, Rootly AI replies with a “Something went wrong, please try again” message and stops. Failed requests do not automatically retry, and users must invoke Rootly AI again to complete their original request.

​

Is There Rate Limiting per Workspace or per User?

Per-team token-per-minute budgets are enforced (see Cost & Usage). A per-user rate limit on top of that is not currently implemented.

---

​

Related Pages