Aws Fis Experiment Prepare
WarnAudited by ClawScan on May 10, 2026.
Overview
The skill is aligned with AWS FIS setup, but it performs real cloud deployments and leaves broad or persistent permissions that should be reviewed before use.
Use this only if you intend the agent to create and modify AWS infrastructure. Prefer a non-production account, require explicit approval before deployment, review the generated CloudFormation and IAM policies, configure stop-condition alarms, and plan cleanup for any persistent EKS RBAC resources.
Findings (6)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A user asking for a prepared experiment could have AWS resources, IAM roles, dashboards, tags, and FIS templates created or changed in their account.
The skill instructs the agent to make real AWS CloudFormation deployments as part of preparation, not just generate files.
Generate all configuration files needed to run an AWS FIS experiment, then deploy via CloudFormation with self-healing iteration until the stack succeeds.
Require an explicit user approval step before deployment, support a generate-only/dry-run mode, and have the user review the CloudFormation template and IAM changes first.
If a prepared experiment is later run, a fault could continue until its configured duration even if monitored service health degrades.
The generated FIS templates are ready for later execution but do not include an alarm-based automatic stop condition by default.
Defaults to `source: "none"` (no stop condition alarm). Only creates CloudWatch alarms if the user explicitly provides one.
Ask the user to choose or explicitly waive a CloudWatch stop condition before producing a runnable experiment template.
A mistake or compromise in the setup Lambda could affect the whole EKS cluster, not just the namespace or experiment being prepared.
For EKS pod actions, the generated setup grants a Lambda role cluster-wide Kubernetes administrative authority.
Use `AmazonEKSClusterAdminPolicy` to grant the Lambda full K8s admin permissions ... AccessScope: Type: cluster
Prefer the least privilege scope possible, isolate experiments to non-production clusters or namespaces, and review all EKS access entries before deployment.
Permissions created for one experiment can remain available for future use, making cleanup and access review harder.
The skill intentionally creates shared Kubernetes RBAC resources that persist after the experiment stack is removed.
Delete: Do nothing — RBAC resources are shared and must NOT be deleted when a single experiment stack is removed
Document and provide an explicit cleanup path, make persistence opt-in, and use namespacing or ownership tags so users can audit and remove leftover RBAC resources safely.
The user must trust the packaged scripts to run AWS deployment logic correctly.
The skill relies on local helper scripts while registry metadata says there is no install spec and no required binaries.
Utility scripts (execute, do not read as reference): `scripts/precheck-cfn-permissions.sh` ... `scripts/deploy-with-retry.sh` ... `scripts/rename-output-dir.sh`
Review helper scripts before use and declare runtime dependencies such as AWS CLI and jq in metadata.
Poor handling of unusual resource names could break generated scripts or deployment names.
A user-controlled resource identifier is used in generated shell logic for slug construction. The shown use is quoted and purpose-aligned, but it should be hardened with an allowlist.
TARGET_SLUG=$(echo "${TARGET_RESOURCE_ID}" | tr '[:upper:]' '[:lower:]' | tr ' :/' '-' | cut -c1-20)Normalize generated names to a strict safe character set, quote every later use, and fail closed on invalid identifiers.