MCP server AWS permissions boundary security — IAM permissions boundaries for MCP server roles, least-privilege enforcement, and privilege escalation prevention

How permissions boundaries differ from identity-based policies

AWS IAM evaluates permissions as the intersection of the identity-based policy (what the role is explicitly granted) and the permissions boundary (the maximum permitted). An action is allowed only if both the identity-based policy allows it AND the permissions boundary allows it. If a role has AdministratorAccess attached but a permissions boundary that only allows s3:GetObject and s3:PutObject, the role can only perform those two S3 actions regardless of the broad attached policy.

Why MCP server IAM roles are high-value targets

MCP tools that interact with AWS — reading S3 buckets, querying DynamoDB, calling Lambda, sending SES emails — run with the permissions of the EC2 instance profile or ECS task role that hosts the MCP server. This role is automatically available via IMDS without any credentials in the code. A prompt-injection attack that convinces the LLM to pass a crafted string to an AWS-calling tool can:

1. Call iam:CreateRole with a trust policy pointing to an external account if the MCP server role has that permission
2. Call iam:AttachRolePolicy to attach AdministratorAccess to the new role
3. Call sts:AssumeRole to receive credentials for the elevated role — now with full AWS account access

Constructing a permissions boundary for an MCP server role

The boundary policy should allow only the AWS API actions the MCP server legitimately needs, plus explicitly deny all IAM write actions and privilege escalation paths.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowMcpServerOperations",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket",
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:Query",
        "dynamodb:Scan",
        "ses:SendEmail",
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyPrivilegeEscalation",
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "sts:AssumeRole",
        "organizations:*",
        "account:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyBoundaryModification",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteRolePermissionsBoundary",
        "iam:PutRolePermissionsBoundary"
      ],
      "Resource": "*"
    }
  ]
}

Attaching the boundary in Terraform and AWS CDK

# Terraform: create the boundary policy and attach to the MCP server role
resource "aws_iam_policy" "mcp_server_boundary" {
  name   = "McpServerPermissionsBoundary"
  policy = file("mcp-server-boundary.json")
}

resource "aws_iam_role" "mcp_server" {
  name = "mcp-server-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action    = "sts:AssumeRole"
      Effect    = "Allow"
      Principal = { Service = "ec2.amazonaws.com" }
    }]
  })

  # Attach the boundary — caps maximum permissions regardless of attached policies
  permissions_boundary = aws_iam_policy.mcp_server_boundary.arn
}

# Attach the actual operational policy (intersection with boundary = effective permissions)
resource "aws_iam_role_policy_attachment" "mcp_server_ops" {
  role       = aws_iam_role.mcp_server.name
  policy_arn = aws_iam_policy.mcp_server_ops.arn  # Your specific operational policy
}

// AWS CDK (TypeScript)
import * as iam from 'aws-cdk-lib/aws-iam';

const boundary = new iam.ManagedPolicy(this, 'McpServerBoundary', {
  document: iam.PolicyDocument.fromJson(boundaryJson),
});

const mcpRole = new iam.Role(this, 'McpServerRole', {
  assumedBy: new iam.ServicePrincipal('ec2.amazonaws.com'),
  permissionsBoundary: boundary,
});

SCPs vs permissions boundaries — which to use when

Service Control Policies (SCPs) in AWS Organizations apply to every identity in an account or OU — they cannot be set per-role. Permissions boundaries apply to specific roles. For MCP servers:

• Use an SCP to block actions that should never occur in the account at all (e.g., deny all EC2 launch in non-production accounts, deny root user API calls)
• Use a permissions boundary to cap an individual MCP server role to only the AWS API surface it legitimately needs, even when the platform team's broad operational policy grants more
• Both are belt-and-suspenders: an SCP blocks at the account level, a boundary blocks at the role level — privilege escalation requires bypassing both

SkillAudit findings for permissions boundary issues in MCP servers

SkillAudit checks IAM role configurations exported via CloudFormation templates or Terraform plans. Run a free audit to surface privilege escalation paths in your MCP server's AWS configuration.