MCP Server: Secure Python boto3 AWS Operations

Overview

MCP Server: Secure Python boto3 AWS Operations exposes a controlled environment where short Python snippets using boto3 can be executed safely against AWS. It implements the Model Context Protocol (MCP) pattern so external agents (for example an LLM or automation engine) can request data from or perform operations on AWS resources through a constrained Python runtime, rather than granting broad direct AWS access.

This approach is useful when you need programmatic access to AWS from an automated system but want to enforce policies, audit every request, and reduce blast radius. The server mediates access using scoped credentials, allowlists/denylists, dry-run modes, and logging—letting developers run queries or targeted changes while keeping security controls in place.

Repository: https://github.com/baryhuang/mcp-server-aws-resources-python

Features

• Execute Python snippets that import and use boto3 in a sandboxed environment
• Policy controls: allowed actions/resources and deny rules
• Credential scoping via environment or assumed roles (least-privilege recommended)
• Dry-run and read-only modes for safe inspection
• Per-request logging and audit trail for governance
• Return structured results suitable for downstream processing (JSON/plaintext)
• Works with any AWS service supported by boto3 (subject to policy)

Installation / Configuration

Clone and install dependencies:

git clone https://github.com/baryhuang/mcp-server-aws-resources-python.git
cd mcp-server-aws-resources-python

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Environment configuration (example):

export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
export AWS_REGION=us-west-2

# Optional: point to a policy file
export MCP_POLICY_FILE=./policy.yaml

Start the server (example commands—adjust to the entrypoint in the repository):

# If the project provides a module entrypoint
python -m mcp_server

# Or run the provided app script
python app.py

Run with Docker (example):

# Dockerfile (example)
FROM python:3.10-slim
WORKDIR /app
COPY . /app
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

docker build -t mcp-server-aws:latest .
docker run -e AWS_ACCESS_KEY_ID=... -e AWS_SECRET_ACCESS_KEY=... -p 8080:8080 mcp-server-aws:latest

Policy configuration example (policy.yaml):

allowed_actions:
  - s3:ListBucket
  - s3:GetObject
  - ec2:DescribeInstances
allowed_resources:
  - arn:aws:s3:::example-bucket
  - arn:aws:ec2:us-west-2:123456789012:instance/*
deny_actions:
  - iam:CreateUser
dry_run: false

Available Resources

The server executes Python with boto3 available, so any AWS service supported by boto3 can be accessed subject to configured policies. Typical examples:

Note: Actual operations permitted are enforced by server policy and the IAM credentials the server runs with.

Use Cases

• Inventory and discovery: have an LLM or automation agent request a list of EC2 instances or S3 buckets in an account without giving it direct AWS keys. Example request payload (MCP-style):

{
  "tool": "python-boto3",
  "code": "import boto3\ns3 = boto3.client('s3')\nprint([b['Name'] for b in s3.list_buckets()['Buckets']])"
}

• Controlled remediation: allow a trusted automation flow to perform specific actions (e.g., stop a specific EC2 instance) while recording the action and enforcing an allowlist:

import boto3
ec2 = boto3.client('ec2')
ec2.stop_instances(InstanceIds=['i-0123456789abcdef0'])
print('stop requested')

• Policy-safe inspections: run read-only “audits” across multiple resources in dry-run mode to gather context for incident response or cost analysis.

• Multi-account access with least privilege: configure the server to assume roles in other accounts and enforce per-account policies so automation can query or modify resources across accounts under central control.

Security considerations

• Use least-privilege IAM credentials for the server process; prefer role assumption with limited permissions.
• Keep allow/deny policies tight and tested in dry-run before enabling