Medium Risk

create_anomaly_detection_model

Create an anomaly detection computation model in AWS IoT SiteWise. Anomaly detection computation models enable you to automatically detect unusual patterns in asset property data. You can configure them either at the **asset model level** (for reuse across similar assets) or at the **asset level...

Single-target operation

Part of the AWS IoT SiteWise MCP Server MCP server. Enforce policies on this tool with Intercept, the open-source MCP proxy.

AI agents use create_anomaly_detection_model to create or modify resources in AWS IoT SiteWise MCP Server. Write operations carry medium risk because an autonomous agent could trigger bulk unintended modifications. Rate limits prevent a single agent session from making hundreds of changes in rapid succession. Argument validation ensures the agent passes expected values.

Without a policy, an AI agent could call create_anomaly_detection_model repeatedly, creating or modifying resources faster than any human could review. Intercept's rate limiting ensures write operations happen at a controlled pace, and argument validation catches malformed or unexpected inputs before they reach AWS IoT SiteWise MCP Server.

Write tools can modify data. A rate limit prevents runaway bulk operations from AI agents.

aws-iot-sitewise-mcp-server.yaml
tools:
  create_anomaly_detection_model:
    rules:
      - action: allow
        rate_limit:
          max: 30
          window: 60

See the full AWS IoT SiteWise MCP Server policy for all 72 tools.

Tool Name create_anomaly_detection_model
Category Write
Risk Level Medium

View all 72 tools →

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

Browse the full MCP Attack Database →

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

What does the create_anomaly_detection_model tool do? +

Create an anomaly detection computation model in AWS IoT SiteWise. Anomaly detection computation models enable you to automatically detect unusual patterns in asset property data. You can configure them either at the **asset model level** (for reuse across similar assets) or at the **asset level** (for specific assets). Property requirements: To set up anomaly detection, you must have the following requirements: At least one input property that is of either DOUBLE or INTEGER data type. It is either a measurement or transform property, and is used to train the model. A result property of STRING data type. It must be a measurement property, and stores the anomaly detection results. There are two ways to configure anomaly detection models: 1. **Asset Model Level Configuration**: - Uses AssetModelPropertyBindingValue in data binding - Defines computation logic at the asset model level - Must be tied to specific assets later via ExecuteAction API - Reusable across multiple assets of the same model type - Use when you want to define computation logic once and apply to multiple assets 2. **Asset Level Configuration**: - Uses AssetPropertyBindingValue in data binding - Defines computation logic for specific asset instances - Ready to execute immediately, no additional binding needed - Tied directly to specific asset properties - Use when you want computation logic for specific assets only Args: computation_model_name: The name of the computation model (required) input_properties: A list of asset or asset model property bindings used as inputs. All IDs (assetModelId, assetId, propertyId) must be UUIDs, not names. result_property: The asset or asset model property where the result will be stored. All IDs (assetModelId, assetId, propertyId) must be UUIDs, not names. region: AWS region (default: us-east-1) computation_model_description: Optional human-readable description tags: Optional metadata tags for the computation model Returns: Dictionary containing computation model creation response Example 1 - Asset Model Level Configuration: input_properties = [ {"assetModelProperty": {"assetModelId": "12345678-1234-1234-1234-123456789012", "propertyId": "11111111-1111-1111-1111-111111111111"}}, {"assetModelProperty": {"assetModelId": "12345678-1234-1234-1234-123456789012", "propertyId": "22222222-2222-2222-2222-222222222222"}} ] result_property = { "assetModelProperty": {"assetModelId": "12345678-1234-1234-1234-123456789012", "propertyId": "33333333-3333-3333-3333-333333333333"} } Example 2 - Asset Level Configuration: input_properties = [ {"assetProperty": {"assetId": "87654321-4321-4321-4321-210987654321", "propertyId": "11111111-1111-1111-1111-111111111111"}}, {"assetProperty": {"assetId": "87654321-4321-4321-4321-210987654321", "propertyId": "22222222-2222-2222-2222-222222222222"}} ] result_property = { "assetProperty": {"assetId": "87654321-4321-4321-4321-210987654321", "propertyId": "33333333-3333-3333-3333-333333333333"} } Decision Guide: - Use **Asset Model Level** for reusable logic across many assets of the same model. - Use **Asset Level** for computation logic tied to specific asset instances. - **Important**: All IDs (assetModelId, assetId, propertyId) must be UUIDs, not names. Use list_asset_models and describe_asset_model to get the correct UUIDs. Note: inputProperties and resultProperty must be single variable references like "${variablename}". For multiple input properties, use a single variable that maps to a "list" structure in the data binding. Do NOT use comma-separated variables like "${var1}, ${var2}" - this is invalid.. It is categorised as a Write tool in the AWS IoT SiteWise MCP Server MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.

How do I enforce a policy on create_anomaly_detection_model? +

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

What risk level is create_anomaly_detection_model? +

create_anomaly_detection_model is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.

Can I rate-limit create_anomaly_detection_model? +

Yes. Add a rate_limit block to the create_anomaly_detection_model 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 create_anomaly_detection_model completely? +

Set action: deny in the Intercept policy for create_anomaly_detection_model. 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 create_anomaly_detection_model? +

create_anomaly_detection_model is provided by the AWS IoT SiteWise MCP Server MCP server (awslabs.aws-iot-sitewise-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.

Deterministic policy on every MCP tool call. Per-identity grants. Full audit log.

// GET IN TOUCH

Have a question or want to learn more? Send us a message.

Message sent.

We'll get back to you soon.