Most AWS servers assume one credential and one account; this one starts from AWS Organizations and fans out, which is the shape a security team actually works in. The Athena side is the other half — it reaches history that no describe call can answer, but only if the tables are already built.
An MCP server that puts AWS security services behind conversational queries. It discovers accounts through `organizations:ListAccounts`, assumes a named role in each one, and reads live configuration and findings across the security-relevant services — with an optional Athena path for log data already landed in S3.
- Findings from GuardDuty, SecurityHub and Access Analyzer read together, instead of one console at a time
- Resource and configuration detail across IAM, EC2, S3, Lambda, CloudFront, ELB/ALB/NLB, Route53, WAF, Shield, ECS/ECR and Organizations
- Cross-account reach: accounts discovered from AWS Organizations, then entered by assuming `aws-security-mcp-cross-account-access` in each
- Network topology and blast-radius questions answered from live configuration — which resource owns an address, what it can reach
- Athena queries over CloudTrail, VPC Flow Logs, CloudFront, ALB, WAF and Shield logs, correlated across sources
AWS credentials with the managed `SecurityAudit` policy attached — that policy is what the read paths run on. Cross-account discovery additionally needs `sts:AssumeRole` and `organizations:ListAccounts`, plus a role named `aws-security-mcp-cross-account-access` created in each target account. Python 3.11 or higher and `uv`. Region, profile and cross-account settings live in `config.yaml`; `MCP_LOG_LEVEL`, `MCP_STARTUP_QUIET` and `AWS_DEFAULT_REGION` override it. The server speaks SSE on port 8000 and clients reach it through `mcp-proxy`. Athena analysis is optional and needs its own Athena, Glue and S3 permissions plus tables that already exist. Responses can be large — the README recommends a client that handles token sizes greater than 100,000.