1 Key Risks
The most critical security risks an operator inherits when deploying this agent in its documented default configuration. The dominant exposures concentrate on untrusted multi-channel input ingestion without dedicated prompt filtering, autonomous workflow actions on lower-impact triggers, and AI output reaching external audiences without outbound content controls.
2 AIRQ Scores
The four headline scores quantify how exposed the agent is, how damaging a successful attack would be, and how much the agent’s own controls reduce that risk. Rootly AI SRE lands in the lower band of the composite score, where the trifecta-elevated attack surface outpaces the vendor's documented default defense controls.
The attack surface sits at the upper boundary of the medium band, blast radius stays in the low-to-medium range, and defense controls reach the mid-tier of the fifteen-point scale, placing this agent in the Tight Operators quadrant.
Attack Surface and Blast Radius are each scored out of ten, Defense Controls out of fifteen, and the AIRQ composite integrates all three into a single risk-adjusted capability measure.
| Metric | Score | Comments |
|---|---|---|
| AIRQ Score | 4.01 | Vendor-documented PII redaction, tenant isolation, and human-in-the-loop approval partially offset the trifecta-elevated attack surface, leaving input and output guardrails as the primary hardening priorities. |
| Blast Radius | 3.75 / 10 | The cloud-hosted model eliminates host-level file system and direct code execution blast, while network egress and deployment-access webhooks carry the upper bands. |
| Attack Surface | 4.8 / 10 | All three trifecta conditions are met on the documented default, elevating the composite into the medium band despite moderate per-surface base scores across the ten attack surfaces. |
| Defense Controls | 8 / 15 | Vendor documentation supports PII redaction, cloud tenant isolation, and human-in-the-loop approval gates as defaults, but input filtering and output controls remain at the lowest documented tier. |
3 Attack Surface
Attack surfaces are the entry points and interaction patterns through which adversarial input can reach the agent’s reasoning loop and steer its behavior. The dominant exposures for Rootly AI SRE are its multi-channel input ingestion from Slack and monitoring integrations, the external model provider dependency, and the broad MCP tool surface.
Seven of ten surfaces sit at the medium band and three score low, meaning no single chokepoint dominates and hardening must address multiple input channels simultaneously.
Each row ties an attack surface to its base score and a per-surface assessment of the architectural exposure the operator inherits on the documented default.
| Surface | Score | Comments |
|---|---|---|
| User Input | 2 / 4 | Multiple input channels including Slack mentions, slash commands, web copilot queries, MCP protocol, and REST API carry user-authored content into the reasoning loop without a dedicated prompt shield or injection detection layer. [4][5] |
| External Data | 2 / 4 | Ingests alerts from more than seventy monitoring integrations and Slack channel messages with configurable privacy levels, processing third-party-authored payloads through PII redaction without dedicated content scanning. [4][15] |
| Memory | 1 / 4 | Incident-scoped context with cross-incident read-only queries via Web Copilot; no persistent learning loop, no cross-session memory writes, and no autonomous context expansion beyond the current incident boundary. [4][10] |
| Reasoning | 2 / 4 | Multi-step parallel hypothesis checks with visible confidence scores delegate to vendor-hosted or operator-supplied model keys; reasoning chain visibility reduces opacity but does not prevent goal hijacking, a class-level risk documented for agentic applications. [2][9] |
| Planning | 2 / 4 | Workflow engine decomposes incident response into trigger-conditioned action sequences with mandatory condition re-evaluation before each execution cycle, gating higher-impact actions behind approval workflows. [13] |
| Tool Execution | 2 / 4 | Over one hundred and fifty MCP tools generated from the OpenAPI specification with security-sensitive operations excluded by default; remediation triggers pre-configured scripts rather than arbitrary operator-supplied code. [8] |
| Orchestration | 2 / 4 | Event-driven workflow automation fires actions on alert triggers and lifecycle events within the platform boundary; workflows cannot self-modify, spawn concurrent agents, or escalate their own permissions at runtime. [13] |
| Inter-Agent | 1 / 4 | MCP server exposes a token-authenticated protocol to external IDE clients with a vendor-defined tool surface; the agent does not orchestrate external agents or connect to an agent marketplace. [8] |
| Output Processing | 1 / 4 | Text output with PII redaction covering emails, phone numbers, credit cards, and passwords in URLs; no dedicated data-loss prevention, exfiltration blocking, or URL sanitization beyond the scrubbing pipeline. [5] |
| Configuration | 2 / 4 | Admin-only AI feature toggles with per-feature enable and disable controls and RBAC enforcement; no auto-loaded project config files, no community plugin marketplace, and the vendor's open-source tooling applies path traversal and injection validation. [3][4] |
The Lethal Trifecta is triggered when an agent processes untrusted content, accesses private data, and communicates externally in the same session — the three conditions that turn an isolated prompt injection into full-chain exfiltration. Rootly AI SRE exhibits all three conditions on the documented default: Slack messages and monitoring alerts carry untrusted content into a reasoning loop that reads incident data and streams outputs to external channels.
Rootly AI SRE exhibits all three of these conditions in its documented default configuration:
- Untrusted input — Slack incident channel messages authored by any participant, alert payloads from monitoring integrations, and MCP queries from external IDE clients carry untrusted content into the reasoning loop. [4][14]
- Sensitive data — The agent reads incident timelines, alert details, service ownership, on-call schedules, and code repository context including deployments and pull requests spanning production infrastructure. [4][11]
- External egress — Incident data flows to external model providers for processing, AI-generated content posts to messaging channels and public status pages, and the MCP server streams responses to external clients. [5][8]
4 Blast Radius
The blast radius is what an attacker who controls the agent can reach — which systems they touch, which credentials they read, and which actions they take without operator approval. The cloud-hosted model eliminates host-level file system blast, but network egress to external providers, credential passthrough for integrations, and deployment-triggering workflow webhooks carry the mid-band exposure.
No factor reaches the high band and one scores zero, with four of six factors anchored at the mid-band through network, credential, autonomous action, and deployment channels.
Each row ties a blast factor to the scope of damage an attacker could achieve by compromising the agent's access to that resource on the documented default.
| Factor | Score | Comments |
|---|---|---|
| Code execution | 1 / 4 | Workflow actions trigger pre-configured scripts including kubectl rollback and Ansible playbooks through webhooks with approval gates; no direct shell access or arbitrary code execution surface is exposed. [8] |
| File system access | 0 / 4 | Cloud-hosted SaaS with no host file system access; the agent operates entirely within the vendor's managed infrastructure boundary with no documented local storage surface. [4] |
| Network access | 2 / 4 | Outbound data flows to external model providers with PII redaction, posts to Slack and Teams messaging channels, and updates to public-facing status pages that cross the trust boundary. [5] |
| Credential access | 2 / 4 | Integration OAuth tokens and API keys managed by the platform with bearer token authentication for the MCP server; access does not extend to SSH keys, browser credential stores, or secrets vaults. [8] |
| Autonomous action | 2 / 4 | Workflows fire on alert triggers with conditional gates; high-impact remediation requires explicit human approval, while lower-impact actions such as channel creation and notification dispatch execute autonomously. [13] |
| Deployment access | 2 / 4 | Can trigger deployment-related actions including kubectl rollback and Terraform scaling through workflow webhooks; human approval gates are documented for high-impact deployment operations. [8] |
5 Defense Controls
Defense controls are what the agent’s own architecture does to detect, contain, and report attacks before they reach the operator’s systems. The vendor ships cloud tenant isolation, human-in-the-loop approval gates, and SOC 2 Type II audit trail as defaults, while input filtering and output controls remain limited to PII redaction.
Three of five components reach the upper band while input and output guardrails carry the lowest tier, making those two controls the primary targets for procurement or configuration hardening.
Each component is scored on what the vendor implements by default, with higher scores reflecting controls that ship enabled without operator configuration or additional procurement.
| Component | Score | Comments |
|---|---|---|
| Input Guardrails | 1 / 3 | PII redaction strips emails, phone numbers, credit cards, and passwords before external model submission; no dedicated prompt shield or injection detection mechanism is documented as a shipped default. [5] |
| Execution Isolation | 2 / 3 | Cloud-hosted SaaS with vendor-managed tenant isolation ensures the AI operates within the platform boundary with no local execution surface; tenant data isolation is enforced by design with no cross-organizational data access. [4][12] |
| Action Controls | 2 / 3 | Human-in-the-loop approval gates for high-impact remediation, RBAC enforcement, admin-only AI feature toggles, and per-incident AI access evaluation are documented as shipped defaults. [4][9] |
| Output Guardrails | 1 / 3 | PII redaction on AI outputs and configurable Slack scope levels for message ingestion privacy are present; no dedicated data-loss prevention or exfiltration blocking beyond the scrubbing pipeline. [5][14] |
| Monitoring | 2 / 3 | Platform-level audit controls include access logging, change management, and vulnerability management under SOC 2 Type II attestation; incident timeline logging, workflow execution records, and a structured vulnerability disclosure program round out the observability baseline. [1][6][7] |
6 Hardening Tips
Concrete actions an operator can take to reduce the risks reported above, grouped by which defense control each tip strengthens. The highest-leverage changes are deploying a prompt-injection detection layer before the reasoning loop, adding outbound data-loss prevention on AI outputs, and forwarding audit logs to a centralized SIEM.
Input Guardrails
Input guardrails intercept adversarial content before it reaches the reasoning loop.
- Policy Restrict Slack scope to the most restrictive privacy level that supports incident workflows — counters User Input exposure from unrestricted channel message ingestion.
- Configuration Enable private-incident exclusion for all sensitive incident categories — counters External Data ingestion of confidential operational details through the default open intake.
- Engineering Deploy a prompt-injection detection layer between Slack ingestion and model submission — counters the absence of dedicated input filtering beyond PII redaction.
Execution Isolation
Execution isolation contains what a compromised agent can do on the host.
- Policy Require bring-your-own model keys with a dedicated tenant to ensure data isolation at the inference provider layer — counters shared inference fleet exposure at the model boundary.
- Configuration Configure network egress policies on the organization's side to allowlist only required platform endpoints — counters unrestricted outbound connectivity from the cloud boundary.
- Engineering Instrument a proxy between the platform and external model providers to log and audit all inference requests — counters the observability gap at the model boundary.
Action Controls
Action controls govern which tools and actions the agent can invoke autonomously.
- Policy Mandate human approval for all workflow actions that modify production infrastructure, not only high-severity remediation — counters Autonomous Action on lower-impact triggers.
- Configuration Restrict MCP server API key scope to read-only operations for investigative use cases — counters the full read-write tool surface exposed by a permissive key.
- Engineering Build a custom approval webhook requiring two-person sign-off for deployment-modifying workflows — counters single-approver risk on deployment-related actions.
Output Guardrails
Output guardrails inspect what the agent sends to other systems and users.
- Policy Require review of AI-generated status page updates before public publication — counters untrusted AI output reaching external audiences without content validation.
- Configuration Configure Slack channel permissions to prevent AI-generated messages from being forwarded outside the organization — counters exfiltration through message sharing channels.
- Engineering Deploy a data-loss prevention proxy on outbound messaging to scan AI output for sensitive operational patterns — counters the absence of dedicated output filtering.
Monitoring
Monitoring captures what the agent did and surfaces anomalies for review.
- Policy Forward platform audit logs to a centralized SIEM with alerting rules for unusual AI query patterns — counters the absence of real-time anomaly detection on AI interactions.
- Configuration Establish a quarterly review cadence for AI feature configuration and Slack scope settings — counters configuration drift that silently expands the AI data access surface.
- Engineering Instrument custom telemetry on MCP server tool invocations to track which tools are called and by which clients — counters the observability gap on the external protocol interface.
7 References
The evidence base behind every score and finding in the profile, grouped by source type so the reader can verify any claim. Numbers in brackets throughout the report (e.g. [7, 13]) refer to entries below, listed in citation order.
Selected Vulnerabilities
- Rootly Vulnerability Disclosure Policy The vendor operates a responsible disclosure program covering rootly.com, api.rootly.com, Slack/Teams apps, and the MCP server, with no paid bounty and a structured triage timeline.
Selected Research
- OWASP Top 10 for Agentic Applications 2026 Class-level framework identifying the ten highest-impact security risks for autonomous AI agents, including goal hijack, tool misuse, memory poisoning, and cascading failures.
- Rootly-AI-Labs graphify-importer SECURITY.md The vendor's open-source graphify tool documents a local-only threat model with API key protection, XSS sanitization, and path traversal validation.
Vendor Documentation
- Rootly AI Documentation Primary vendor documentation covering AI capabilities, privacy-first design, per-incident access evaluation, team-level configuration toggles, and the human-in-the-loop contract.
- Data Privacy for AI The vendor documents PII redaction before OpenAI submission, private incident exclusion, a zero third-party training policy, and configurable Slack scope privacy levels.
- Rootly Trust Center The vendor's SafeBase-powered trust center lists SOC 2 Type II report, penetration test report, and vulnerability assessment report as available security documentation.
- Rootly Compliance Blog The vendor documents SOC 2 Type II independent attestation, GDPR and CCPA alignment, HIPAA-ready workflows, DORA reporting, RBAC, SCIM provisioning, and MFA enforcement.
- Rootly MCP Server Documentation The MCP server exposes over 150 tools from the OpenAPI specification while excluding security-sensitive operations from the default tool surface.
- Rootly AI SRE Product Page The vendor describes parallel hypothesis checks with confidence scores, visible reasoning chains, zero third-party model training, and mandatory human sign-off before remediation execution.
- Ask Rootly AI Documentation The Slack Copilot is scoped to the current incident only, while the Web Copilot enables cross-incident history queries with organizational data isolation.
- Rootly GitHub Integration The rootlyhq GitHub App requests read access to code, deployments, checks, PRs, and metadata, plus read-write access to issues for incident follow-up tracking.
- Rootly Privacy-First AI Blog The vendor describes privacy-by-design architecture with opt-in controls, partial-disclosure modes, PII and secret scrubbing, and enterprise-grade data handling.
Other Sources
- Rootly Workflows Documentation The workflow engine runs structured actions on trigger events with configurable run conditions, sequential execution, delay scheduling, and automatic condition re-evaluation before each cycle.
- Rootly Slack Scope Updates Administrators configure five privacy levels for incident channel message ingestion, from fully permissive to completely off, controlling what Slack content the AI can process.
- Rootly Integrations Page The platform connects to more than seventy tools across alerting, communication, project management, and automation categories, each adding a potential data ingestion channel for the AI.