audit_slos

// WHEN AI AGENTS USE THIS TOOL

AI agents call audit_slos to retrieve information from CloudWatch Application Signals MCP Server without modifying any data. This is common in research, monitoring, and reporting workflows where the agent needs context before taking action. Because read operations don't change state, they are generally safe to allow without restrictions -- but you may still want rate limits to control API costs.

// WHY ENFORCE A POLICY ON AUDIT_SLOS

Even though audit_slos only reads data, uncontrolled read access can leak sensitive information or rack up API costs. An agent caught in a retry loop could make thousands of calls per minute. A rate limit gives you a safety net without blocking legitimate use.

// RECOMMENDED POLICY

Read-only tools are safe to allow by default. No rate limit needed unless you want to control costs.

cloudwatch-application-signals-mcp-server.yaml

tools:
  audit_slos:
    rules:
      - action: allow

See the full CloudWatch Application Signals MCP Server policy for all 22 tools.

// DETAILS

Tool Name audit_slos

Category Read

MCP Server CloudWatch Application Signals MCP Server MCP Server

Risk Level Low

// MORE CLOUDWATCH APPLICATION SIGNALS MCP SERVER TOOLS

Read analyze_canary_failures Read audit_group_health Read audit_service_operations Read audit_services Read get_enablement_guide Read get_group_changes Read get_group_dependencies Read get_service_detail

View all 22 tools →

// WHAT CAN GO WRONG

Agents calling read-class tools like audit_slos have been implicated in these attack patterns. Read the full case and prevention policy for each:

Browse the full MCP Attack Database →

// OTHER READ TOOLS ACROSS MCP SERVERS

Other tools in the Read risk category across the catalogue. The same policy patterns (rate-limit, allow) apply to each.

Firecrawl Web Scraping Server firecrawl_check_crawl_status Firecrawl Web Scraping Server firecrawl_crawl Firecrawl Web Scraping Server firecrawl_deep_research Firecrawl Web Scraping Server firecrawl_extract Firecrawl Web Scraping Server firecrawl_map Firecrawl Web Scraping Server firecrawl_scrape

// RELATED READING

// FAQ

What does the audit_slos tool do? +

PRIMARY SLO AUDIT TOOL - The #1 tool for comprehensive SLO compliance monitoring and breach analysis. **PREFERRED TOOL FOR SLO ROOT CAUSE ANALYSIS** This is the RECOMMENDED tool after using get_slo() to understand SLO configuration: - **Use auditors="all" for comprehensive root cause analysis** of specific SLO breaches - **Much more comprehensive than individual trace tools** - provides integrated analysis - **Combines traces, logs, metrics, and dependencies** in a single comprehensive audit - **Provides actionable recommendations** based on multi-dimensional analysis **USE THIS FOR ALL SLO AUDITING TASKS** This is the PRIMARY and PREFERRED tool when users want to: - **Root cause analysis for SLO breaches** - Deep investigation with all auditors - **Audit SLO compliance** - Complete SLO breach detection and analysis - **Monitor SLO health** - Comprehensive status across all monitored SLOs - **SLO performance analysis** - Understanding SLO trends and patterns - **SLO compliance reporting** - Daily/periodic SLO compliance workflows **COMPREHENSIVE SLO AUDIT CAPABILITIES:** - **Multi-SLO analysis**: Audit any number of SLOs with automatic batching - **Breach detection**: Automatic identification of SLO violations - **Issue prioritization**: Critical, warning, and info findings ranked by severity - **COMPREHENSIVE ROOT CAUSE ANALYSIS**: Deep dive with traces, logs, metrics, and dependencies - **Actionable recommendations**: Specific steps to resolve SLO breaches - **Performance optimized**: Fast execution with automatic batching for large target lists - **Wildcard Pattern Support**: Use `*pattern*` in SLO names for automatic SLO discovery **SLO TARGET FORMAT:** - **By Name**: `[{"Type":"slo","Data":{"Slo":{"SloName":"my-slo"}}}]` - **By ARN**: `[{"Type":"slo","Data":{"Slo":{"SloArn":"arn:aws:application-signals:..."}}}]` **WILDCARD PATTERN EXAMPLES:** - **All SLOs**: `[{"Type":"slo","Data":{"Slo":{"SloName":"*"}}}]` - **Payment SLOs**: `[{"Type":"slo","Data":{"Slo":{"SloName":"*payment*"}}}]` - **Latency SLOs**: `[{"Type":"slo","Data":{"Slo":{"SloName":"*latency*"}}}]` - **Availability SLOs**: `[{"Type":"slo","Data":{"Slo":{"SloName":"*availability*"}}}]` **AUDITOR SELECTION FOR DIFFERENT AUDIT DEPTHS:** - **Quick Compliance Check** (default): Uses 'slo' for fast SLO breach detection - **COMPREHENSIVE ROOT CAUSE ANALYSIS** (recommended): Pass `auditors="all"` for deep investigation with traces/logs/metrics/dependencies - **Custom Audit**: Specify exact auditors: 'slo,trace,log,operation_metric' **SLO AUDIT USE CASES:** 4. **Audit all SLOs**: `slo_targets='[{"Type":"slo","Data":{"Slo":{"SloName":"*"}}}]'` 22. **Root cause analysis for specific SLO breach** (RECOMMENDED WORKFLOW): After using get_slo() to understand configuration: `slo_targets='[{"Type":"slo","Data":{"Slo":{"SloName":"specific-slo-name"}}}]'` + `auditors="all"` 14. **Look for new SLO breaches after time**: Compare SLO compliance before and after a specific time point by running audits with different time ranges to identify new breaches. **PAGINATION SUPPORT FOR WILDCARD PATTERNS:** - **Automatic Pagination**: Wildcard patterns now process SLOs in batches of 5 (configurable with `max_slos`) - **Continue Processing**: Use `next_token` from previous response to continue auditing remaining SLOs - **Example Pagination Workflow**: 1. First call: `audit_slos(slo_targets='[{"Type":"slo","Data":{"Slo":{"SloName":"*"}}}]')` 2. If more SLOs available, response includes: `next_token="abc123"` and time parameters 3. Continue: `audit_slos(slo_targets='[...]', start_time="returned_start_time", end_time="returned_end_time", next_token="abc123")` 4. Repeat until no more `next_token` returned **TYPICAL SLO AUDIT WORKFLOWS:** 1. **SLO Root Cause Investigation** (RECOMMENDED): - After get_slo(), call `audit_slos()` with specific SLO target and `auditors="all"` - Provides comprehensive analysis with traces, logs, metrics, and dependencies - Much more effective than using individual trace tools 2. **Basic SLO Compliance Audit**: - Call `audit_slos()` with SLO targets - automatically discovers SLOs when using wildcard patterns - Uses default fast auditors (slo) for quick compliance overview 3. **Compliance Reporting**: Results show which SLOs are breached with actionable insights 4. **Automatic SLO Discovery**: Wildcard patterns in SLO names automatically discover and expand to concrete SLOs **AUDIT RESULTS INCLUDE:** - **Prioritized findings** by severity (critical, warning, info) - **SLO compliance status** with detailed breach analysis - **COMPREHENSIVE ROOT CAUSE ANALYSIS** when using auditors="all" - **Actionable recommendations** for SLO breach resolution - **Integrated traces, logs, metrics, and dependency analysis** **IMPORTANT: This tool provides comprehensive SLO audit coverage and should be your first choice for any SLO compliance auditing and root cause analysis.** **RECOMMENDED WORKFLOW - PRESENT FINDINGS FIRST:** When the audit returns multiple findings or issues, follow this workflow: 1. **Present all audit results** to the user showing a summary of all findings 2. **Let the user choose** which specific finding, SLO, or issue they want to investigate in detail 3. **Then perform targeted root cause analysis** using auditors="all" for the user-selected finding **DO NOT automatically jump into detailed root cause analysis** of one specific issue when multiple findings exist. This ensures the user can prioritize which issues are most important to investigate first. **Example workflow:** - First call: `audit_slos()` with default auditors for compliance overview - Present findings summary to user - User selects specific SLO breach to investigate - Follow-up call: `audit_slos()` with `auditors="all"` for selected SLO only. It is categorised as a Read tool in the CloudWatch Application Signals MCP Server MCP Server, which means it retrieves data without modifying state.

How do I enforce a policy on audit_slos? +

Add a rule in your Intercept YAML policy under the tools section for audit_slos. You can allow, deny, rate-limit, or validate arguments. Then run Intercept as a proxy in front of the CloudWatch Application Signals MCP Server MCP server.

What risk level is audit_slos? +

audit_slos is a Read tool with low risk. Read-only tools are generally safe to allow by default.

Can I rate-limit audit_slos? +

Yes. Add a rate_limit block to the audit_slos rule in your Intercept policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

How do I block audit_slos completely? +

Set action: deny in the Intercept policy for audit_slos. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

What MCP server provides audit_slos? +

audit_slos is provided by the CloudWatch Application Signals MCP Server MCP server (awslabs.cloudwatch-applicationsignals-mcp-server). Intercept sits as a proxy in front of this server to enforce policies before tool calls reach the server.

Let agents act without letting them run wild.