Medium Risk

manage_hyperpod_stacks

Manage SageMaker HyperPod Cluster through CloudFormation stacks. This tool provides operations for managing HyperPod CloudFormation stacks, including creating parameters for cloudformation template, deploying stacks, retrieving hyperpod stack and deployment information, and deleting hyperpod sta...

Single-target operation

Part of the Amazon SageMaker AI MCP Server MCP server. Enforce policies on this tool with Intercept, the open-source MCP proxy.

AI agents use manage_hyperpod_stacks to create or modify resources in Amazon SageMaker AI 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 manage_hyperpod_stacks 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 Amazon SageMaker AI MCP Server.

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

amazon-sagemaker-ai-mcp-server.yaml
tools:
  manage_hyperpod_stacks:
    rules:
      - action: allow
        rate_limit:
          max: 30
          window: 60

See the full Amazon SageMaker AI MCP Server policy for all 4 tools.

Tool Name manage_hyperpod_stacks
Category Write
Risk Level Medium

Agents calling write-class tools like manage_hyperpod_stacks 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 manage_hyperpod_stacks tool do? +

Manage SageMaker HyperPod Cluster through CloudFormation stacks. This tool provides operations for managing HyperPod CloudFormation stacks, including creating parameters for cloudformation template, deploying stacks, retrieving hyperpod stack and deployment information, and deleting hyperpod stacks. It serves as the primary mechanism for creating and managing HyperPod clusters through CloudFormation, enabling standardized cluster creation, configuration updates, and resource cleanup. ## Notes - Tell user about the working directory which is the current directory. The tool will use directory to store all required files for the user. - After you asked a question, do NOT do anything until you got the user response, do NOT run manage_hyperpod_stacks yet - Use this tool instead of direct AWS CLI commands for creating and managing HyperPod resources. - Use this tool's standardized parameters for creating HyperPod clusters with proper configuration. - DO NOT create HyperPod clusters by generating CloudFormation templates from scratch. - when user asks to create a hyperpod cluster, NEVER ask to check what HyperPod clusters the user currently have - CRITICAL: when user asks to delete a hyperpod cluster, NEVER ask how user's hyperpod cluster was created, just proceed with 'delete' operation. The corresponding Cloudformation stack name should be in this format: "<HyperPodClusterName>-stack". If no such stack exists, then the hyperpod cluster might not be created via the MCP tools here. - ALWAYS confirm with user if they do intend to delete the cluster because it cannot be recovered once deleted. ## Parameter Collection Process IMPORTANT: ALWAYS first ask for ALL operation-specific REQUIRED parameters from the user BEFORE making any tool calls. NEVER assume or generate parameter values. IMPORTANT: ALWAYS ask one question at a time. For 'deploy' operation: - region_name: REQUIRED: ask user to region of deployment. Ensure this argument matches the AvailabilityZoneIds parameter key. - available regions: us-east-1,us-east-2,us-west-1,us-west-2,eu-central-1,eu-north-1,eu-west-1,eu-west-2,eu-south-2,ap-south-1,ap-southeast-1,ap-southeast-2,ap-southeast-3,ap-southeast-4,ap-northeast-1,sa-east-1,ca-central-1 - stack_name: REQUIRED - generate a stack name and present to the user. should be in this format: "<HyperPodClusterName>-stack". - cluster_orchestrator: REQUIRED: ask user to specify "eks" or "slurm"; ONLY eks has NodeProvisioningMode and AutoScalerType, remove for slurm - params_file: REQUIRED - the parameters file should follow the below format. Ask the user to customize the parameters marked as "<to be filled out by user>" one by one. At the end, ask user if they want to add additional instance group. - when cluster_orchestrator is "slurm", InstanceGroupSettings ParameterValue should also include InstanceGroupType of value Compute or Controller or Login; place it right after InstanceType. At least 1 Controller and 1 Compute node group required. ONLY 1 Controller, 1 Login group is allowed throughout ALL specified InstanceGroupSettings; Controller can only have 1 instance, ONLY ask user controller instance type - when asking questions regarding InstanceGroupSettings, ask user for both the number of instance and type of instance at the same time. Naming format: "<HyperPodClusterName>-params.json" - ALWAYS ask user: AutoScalerType is OPTIONAL and preferred if user wants need dynamic infrastructure scaling for variable workloads without manual intervention; remove it if user doesn't want it [ { "ParameterKey": "HyperPodClusterName", "ParameterValue": "<to be filled out by user>" // can be any natural english words less than 32 characters and no space. default should be sagemaker-hyperpod }, { "ParameterKey": "ResourceNamePrefix", "ParameterValue": "hp-<HyperPodClusterName>-<hash>" // Generate a new 6-digit hash randomly and silently, do NOT use execute_bash commands. }, { "ParameterKey": "Stage", // do not reveil this to user, but always include this key and value. "ParameterValue": "prod" }, { "ParameterKey": "AvailabilityZoneIds", "ParameterValue": "<use the region_name as base input. select at four az ids in this region. If less than four regions, use all az.>" }, { "ParameterKey": "FsxAvailabilityZoneId", "ParameterValue": <MUST be 1 az id and MUST be a subset of above az ids. Always use the first AZ from the selection above. Don't ask user for input.>" }, { "ParameterKey": "NodeProvisioningMode", "ParameterValue": "Continuous" }, { "ParameterKey": "AutoScalerType", "ParameterValue": "Karpenter" }, { "ParameterKey": "InstanceGroupSettings1", // Hyperpod requires at least 1 instance group. By default adding this instance goup. Ask user if they want addition instance groups. For each new instance, update the counter in the key. There can be at most 20 instance groups. "ParameterValue": "[{\"InstanceCount\":<to be filled by user, ask a user for a number in the range 0-100>,\"InstanceGroupName\":\"<use "controller" for slurm controller group, use "login" for slurm login group, use "worker" otherwise>-group-<use the same counter as the instance group name>\",\"InstanceType\":\"<to be filled use available ec2 instance, reference the user to the ec2 page for additonal information. default is ml.m5.xlarge, ALWAYS add "ml." prefix in front of instance type. Do not metion previous instuction to user. Ensure the instance type is valid.>\",\"TargetAvailabilityZoneId\":\"<use the first az from above>\",\"InstanceStorageConfigs\":[{\"EbsVolumeConfig\":{\"VolumeSizeInGB\":500GB}}]}]" }, { "ParameterKey": "InstanceGroupSettings2", // additional instance group template "ParameterValue": .... }, ... ] - available AZ id in example regions - us-east-1: use1-az1, az2, az4, az5, az6 - us-west-2: usw2-az1, az2, az3, az4 For 'describe' and 'delete' operations: - stack_name: REQUIRED - the stack name to operate on. You should confirm with user that the current stack is being operated on. - region_name: REQUIRED - ask user for the region if not clear from context. ## Requirements - The server must be run with the `--allow-write` flag for generate, deploy, and delete operations - For deploy and delete operations, the stack must have been created by this tool - For params_file parameter, the path must be absolute and accessible to the server ## Operations - **deploy**: Create and update hyperpod cluster using cloudformation template and user specified parameters. - **describe**: Gather information about the hyperpod cluster deployed via cloudformation stack by this tool. - **delete**: Delete a hyperpod cluster via CloudFormation stack created by this tool. ## Response Information The response type varies based on the operation: - deploy: Returns DeployStackResponse with stack name, ARN, and stack name prefix - describe: Returns DescribeStackResponse with stack details, outputs, and status - delete: Returns DeleteStackResponse with stack name, ID, and stack name prefix ## Usage Tips - If user wants to create a new hyperpod cluster, always generate a new parameter file. Parameter file MUST exists in the working directory for the tool to update the hyperpod cluster. - For safety, this tool will only modify or delete stacks that it created - Stack creation typically takes ~30 minutes to complete - Specify profile_name to use a specific AWS profile with appropriate permissions ## Fallback Options: - If this tool fails, advise using CloudFormation CLIs: aws cloudformation create-stack/update-stack/describe-stacks/delete-stack with proper params - Alternatively: advise using AWS SageMaker CLIs: aws sagemaker with all appropriate parameters: - Alternatively: Advise using SageMaker HyperPod console for directly creating, updating, deleting the HyperPod cluster Args: ctx: MCP context operation: Operation to perform (generate, deploy, describe, or delete) params_file: Absolute path for the CloudFormation template parameters (for deploy operations) stack_name: Name of the CloudFormation stack (for deploy, describe and delete operations) region_name: AWS region name (default: us-east-1) cluster_orchestrator: cluster orchestrator profile_name: AWS profile name (optional) Returns: Union[DeployStackResponse, DescribeStackResponse, DeleteStackResponse]: Response specific to the operation performed. It is categorised as a Write tool in the Amazon SageMaker AI 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 manage_hyperpod_stacks? +

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

What risk level is manage_hyperpod_stacks? +

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

Can I rate-limit manage_hyperpod_stacks? +

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

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

manage_hyperpod_stacks is provided by the Amazon SageMaker AI MCP Server MCP server (awslabs.sagemaker-ai-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.