{"slug": "mcp-for-aws-security-engineers-build-a-read-only-security-hub-triage-agent", "title": "MCP for AWS Security Engineers: Build a Read-Only Security Hub Triage Agent", "summary": "AWS has introduced a managed Model Context Protocol (MCP) path for security engineers to build read-only Security Hub triage agents. The approach uses AWS Agent Toolkit and managed MCP Server to connect AI coding agents to AWS documentation and APIs while enforcing security boundaries through IAM, SCPs, and tool approval. The architecture separates the AI model from the control layer, ensuring that IAM policies—not the model—determine what actions are permitted.", "body_md": "For AWS-heavy security work, I would start with **AWS Agent Toolkit for AWS and the managed AWS MCP Server**, not a custom MCP server.\n\nThe reason is practical. AWS now provides a managed MCP path that can connect AI coding agents to AWS documentation, AWS APIs, AWS skills, and existing IAM credentials. The Agent Toolkit also provides plugin-based setup for supported agents such as Claude Code and Codex.\n\nFor security teams, that is the right starting point because the enforcement point remains AWS IAM, not the model.\n\nThe initial operating model should be strict:\n\nThat is the same posture I would use for a governed Claude Code or Codex rollout: named identities, SSO, scoped credentials, default deny, tool approval, audit logs, and security evidence tied back to tickets, pull requests, CI logs, and cloud findings.\n\nThis article walks through a practical security workflow:\n\nA read-only Security Hub triage assistant that helps a junior security engineer produce a daily or weekly findings summary, remediation backlog, and evidence pack without allowing the agent to modify AWS.\n\nThe agent will be able to:\n\nThe agent will **not** be able to:\n\nThis is not a generic AI demo. This is a security-controlled workflow where MCP gives the agent access to context, while IAM, SCPs, tool approval, and human review define the real boundary.\n\n**MCP stands for Model Context Protocol.**\n\nIn plain English, MCP is a standard way for an AI assistant to connect to external systems such as cloud platforms, source code repositories, ticketing systems, databases, monitoring tools, documentation, and security platforms.\n\nA simple mental model:\n\n```\nLLM / Agent\n   |\n   | asks for context or tool execution\n   v\nMCP Client\n   |\n   | speaks MCP\n   v\nMCP Server\n   |\n   | exposes approved tools and data\n   v\nAWS / GitHub / Jira / Security Hub / Internal APIs\n```\n\nMCP is **not the model**.\n\nMCP is **not Claude**.\n\nMCP is **not Codex**.\n\nMCP is the connector layer that lets an AI tool interact with approved external capabilities in a consistent way.\n\nA practical comparison:\n\n| Component | What it is | Example |\n|---|---|---|\n| AI model | The reasoning engine | Claude, GPT, Nova, Qwen |\n| Agent client | The user-facing agent tool | Claude Code, Codex, Cursor, Kiro |\n| MCP server | The tool and data connector | AWS MCP Server, GitHub MCP Server |\n| Tool | An action exposed by the server |\n`securityhub:GetFindings` , documentation search |\n| Resource | Read-only context exposed by the server | Documentation, metadata, finding details |\n| IAM / policy | The enforcement layer | AWS role, SCP, permission boundary |\n\nThe important security point is simple:\n\nMCP gives the agent hands. IAM decides what those hands are allowed to touch.\n\nAn MCP server exposes capabilities to an AI agent.\n\nThose capabilities usually fall into three areas:\n\n| MCP capability | Meaning | Security impact |\n|---|---|---|\n| Tools | Callable functions or actions | Can be read-only or mutating |\n| Resources | Context or data the model can read | Usually safer, but can expose sensitive data |\n| Prompts | Reusable task templates | Useful for standardized workflows |\n\nThat matters because a junior engineer may think, “The model only answers questions.”\n\nThat assumption is no longer safe once tools are attached.\n\nWith MCP, the model may be able to:\n\nThat is why the first security decision is not:\n\nWhich model should we use?\n\nThe first security decision is:\n\nWhat tool permissions will this agent have, and where are those permissions enforced?\n\nFor production security work, the model must never be treated as the control boundary.\n\nThe control boundary must be:\n\nA useful operating model is:\n\n``` php\nPrompt -> Agent loop -> MCP tools -> External systems -> Evidence/output\n```\n\nThe **agent loop** is the cycle where the model reasons, requests a tool, receives the result, reasons again, and continues until the task is complete.\n\nThe **harness** is everything around that loop: tool permissions, context management, project rules, logs, approval gates, hooks, and safety boundaries.\n\nFor security work, MCP sits inside the harness.\n\n```\nClaude Code / Codex\n   |\n   | project rules, approval mode, permissions\n   v\nMCP client\n   |\n   | approved tool calls only\n   v\nAWS MCP Server\n   |\n   | authenticated AWS API access\n   v\nAWS IAM role / permission set\n   |\n   | read-only Security Hub permissions\n   v\nAWS Security Hub\n```\n\nThat distinction is important.\n\nThe model can recommend. The harness controls. IAM enforces.\n\nSecurity work is context-heavy.\n\nA security engineer rarely needs a generic answer. We need the assistant to understand:\n\nWithout MCP, the engineer manually copies and pastes data into the AI tool.\n\nWith MCP, the agent can retrieve approved read-only data directly and produce a consistent investigation output.\n\nUseful security workflows include:\n\nBut MCP is not magic.\n\nIt does not replace security ownership, SOC judgment, IAM design, threat modeling, change control, CI/CD gates, incident commander decisions, or audit evidence review.\n\nMCP should reduce manual collection and improve consistency. It should not become an ungoverned SOAR platform.\n\n**Recommendation: use official or vendor-supported MCP servers first. Build your own only when you have a specific internal workflow that existing servers cannot safely support.**\n\nFor AWS security work, start with:\n\n| Use case | Build your own MCP server? | Recommended path |\n|---|---|---|\n| AWS documentation lookup | No | AWS Agent Toolkit / AWS MCP Server |\n| Security Hub read-only triage | No, initially | AWS MCP Server with read-only IAM |\n| GuardDuty / Inspector / Macie review | No, initially | AWS MCP Server with scoped read-only permissions |\n| Jira ticket drafting | Usually no | Vendor MCP server or local draft output |\n| GitHub repo analysis | Usually no | GitHub MCP or native repo context with repo-scoped permissions |\n| Internal CMDB enrichment | Maybe | Internal read-only MCP server |\n| Internal GRC evidence register | Maybe | Private MCP server or API wrapper |\n| Automated remediation | Not initially | Keep outside MCP until governance is mature |\n| Security Hub suppression/update | No for junior workflow | Human and SOC-approved process only |\n\nUse this priority order for MCP servers:\n\nBe careful with random public MCP servers.\n\nFor a security team, an MCP server is not a harmless browser extension. It is a privileged integration point.\n\nA malicious or poorly written MCP server can become:\n\nTreat MCP servers like production integrations.\n\nAWS Agent Toolkit provides plugins that bundle AWS MCP Server configuration and curated AWS skills for agent workflows.\n\nFor the workflow in this article, the relevant AWS MCP Server capabilities are:\n\n| Capability | Use in this workflow | Initial recommendation |\n|---|---|---|\n| Documentation search | Explain Security Hub controls and AWS service behavior | Allow |\n| AWS API calls | Read Security Hub, GuardDuty, Inspector, Config, and CloudTrail context | Allow only through read-only IAM |\n| Sandboxed script execution | Run multi-step AWS checks | Disable or require explicit approval at pilot stage |\n| Presigned URL generation | File transfer support | Disable unless specifically needed |\n| Long-running task polling | Check status of API/script tasks | Allow only if required |\n\nFor a read-only security workflow, I would allow documentation tools and controlled AWS API calls. I would **deny or require approval for script execution initially**, especially for junior engineers.\n\n```\nSecurity Engineer\n   |\n   | asks question in Claude Code or Codex\n   v\nClaude Code / Codex\n   |\n   | MCP client\n   v\nAWS Agent Toolkit / AWS MCP Server\n   |\n   | authenticated request\n   v\nAWS IAM Identity Center profile: sec-mcp-readonly\n   |\n   | read-only permissions only\n   v\nAWS Security Hub\n   |\n   | Get / List / Describe / BatchGet only\n   v\nLocal output files\n   |\n   | markdown summary, CSV backlog, JSON evidence\n   v\nHuman review\n   |\n   | Jira / Slack / audit evidence\n```\n\nThe key design choice is that the agent can **read and reason**, but it cannot **change the environment**.\n\nThis aligns with a production cloud security baseline: least privilege, centralized identity, MFA, guardrails, logging, evidence retention, and clear owner accountability.\n\nUse IAM Identity Center if available.\n\nCreate a permission set:\n\n```\nPermission set name: SecMCPReadOnly\nSession duration: 4 hours\nAssigned group: SecurityEngineering-MCP-ReadOnly\nAccounts: security tooling account and selected workload accounts\nMFA: required through IdP / IAM Identity Center\n```\n\nDo not use:\n\nUse a named human identity with SSO. The goal is that every MCP-driven AWS API call is attributable to a real engineer.\n\nAWS provides managed read-only policies, but for this workflow I prefer a custom policy because the scope is explicit and easier to explain during audit.\n\n```\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowIdentityCheck\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"sts:GetCallerIdentity\"\n      ],\n      \"Resource\": \"*\"\n    },\n    {\n      \"Sid\": \"AllowSecurityHubReadOnly\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"securityhub:Get*\",\n        \"securityhub:List*\",\n        \"securityhub:Describe*\",\n        \"securityhub:BatchGet*\"\n      ],\n      \"Resource\": \"*\"\n    },\n    {\n      \"Sid\": \"AllowReadOnlyInvestigationContext\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"cloudtrail:LookupEvents\",\n        \"guardduty:GetFindings\",\n        \"guardduty:ListFindings\",\n        \"guardduty:ListDetectors\",\n        \"inspector2:ListFindings\",\n        \"access-analyzer:ListFindings\",\n        \"access-analyzer:GetFinding\",\n        \"organizations:DescribeOrganization\",\n        \"organizations:ListAccounts\",\n        \"config:SelectResourceConfig\",\n        \"config:GetResourceConfigHistory\"\n      ],\n      \"Resource\": \"*\"\n    },\n    {\n      \"Sid\": \"DenyWriteActionsForMCPPilot\",\n      \"Effect\": \"Deny\",\n      \"Action\": [\n        \"securityhub:BatchUpdateFindings\",\n        \"securityhub:BatchImportFindings\",\n        \"securityhub:Update*\",\n        \"securityhub:Delete*\",\n        \"securityhub:Disable*\",\n        \"securityhub:Enable*\",\n        \"securityhub:Create*\",\n        \"securityhub:TagResource\",\n        \"securityhub:UntagResource\",\n        \"iam:*\",\n        \"s3:Put*\",\n        \"s3:Delete*\",\n        \"ec2:AuthorizeSecurityGroupIngress\",\n        \"ec2:AuthorizeSecurityGroupEgress\",\n        \"ec2:RevokeSecurityGroupIngress\",\n        \"ec2:RevokeSecurityGroupEgress\",\n        \"kms:Put*\",\n        \"kms:ScheduleKeyDeletion\",\n        \"config:Put*\",\n        \"config:Delete*\",\n        \"guardduty:Update*\",\n        \"guardduty:Delete*\",\n        \"inspector2:Update*\",\n        \"inspector2:BatchUpdate*\"\n      ],\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nThe explicit deny is not there because the allow statement grants those actions. It does not.\n\nThe explicit deny is there because real environments are messy.\n\nA user may later inherit another permission set, a group policy, or a temporary role that adds write access. Explicit deny reduces the chance that the MCP workflow accidentally gains mutation capability through permission creep.\n\nFor production accounts, pair this with an SCP or permission boundary where possible.\n\nFor production accounts, I would add an organization-level safety net.\n\nExample SCP concept:\n\n```\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"PreventMCPReadOnlyRoleFromMutatingSecurityHub\",\n      \"Effect\": \"Deny\",\n      \"Action\": [\n        \"securityhub:BatchUpdateFindings\",\n        \"securityhub:Update*\",\n        \"securityhub:Delete*\",\n        \"securityhub:Disable*\",\n        \"securityhub:Enable*\",\n        \"securityhub:Create*\"\n      ],\n      \"Resource\": \"*\",\n      \"Condition\": {\n        \"ArnLike\": {\n          \"aws:PrincipalArn\": [\n            \"arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*/AWSReservedSSO_SecMCPReadOnly_*\"\n          ]\n        }\n      }\n    }\n  ]\n}\n```\n\nTest this carefully in a non-production account before applying it broadly.\n\nThe SCP should not block the SOC, security tooling account, CI/CD remediation roles, or incident response break-glass roles.\n\nThe objective is narrow:\n\nThis MCP read-only role must never mutate Security Hub findings or configuration.\n\nInstall or update the AWS CLI, then configure SSO:\n\n```\naws configure sso --profile sec-mcp-readonly\n```\n\nValidate the identity:\n\n```\naws sts get-caller-identity --profile sec-mcp-readonly\n```\n\nExpected output:\n\n```\n{\n  \"UserId\": \"AROAXXXXX:security.engineer@example.com\",\n  \"Account\": \"123456789012\",\n  \"Arn\": \"arn:aws:sts::123456789012:assumed-role/AWSReservedSSO_SecMCPReadOnly_xxxxx/security.engineer@example.com\"\n}\n```\n\nThen test Security Hub read access:\n\n```\naws securityhub get-findings \\\n  --profile sec-mcp-readonly \\\n  --region us-east-1 \\\n  --max-results 5\n```\n\nNow test that write access fails:\n\n```\naws securityhub batch-update-findings \\\n  --profile sec-mcp-readonly \\\n  --region us-east-1 \\\n  --finding-identifiers '[{\"Id\":\"test\",\"ProductArn\":\"arn:aws:securityhub:us-east-1::product/aws/securityhub\"}]' \\\n  --workflow '{\"Status\":\"SUPPRESSED\"}'\n```\n\nExpected result:\n\n```\nAccessDeniedException\n```\n\nKeep that negative-control result as rollout evidence.\n\nIn Claude Code, install the AWS plugin:\n\n```\n/plugin install aws-core@claude-plugins-official\n/reload-plugins\n```\n\nThen validate that the AWS MCP server is visible:\n\n```\n/mcp\n```\n\nFor the pilot, I would configure Claude Code so AWS API calls require approval and script execution is denied or requires explicit human approval.\n\nThe point is not to slow engineers down. The point is to prevent the first rollout from quietly becoming an unapproved automation channel.\n\nFor Codex, AWS documents plugin setup through the Codex plugin marketplace:\n\n```\ncodex plugin marketplace add aws/agent-toolkit-for-aws\n```\n\nThen open Codex and use:\n\n```\n/plugins\n```\n\nInstall the `aws-core`\n\nplugin.\n\nFor the pilot, configure Codex so MCP tools are explicitly approved and write-capable tools are disabled or denied.\n\nThe exact approval configuration may vary by Codex version, so validate against the current Codex configuration reference before publishing your internal runbook.\n\nIf you cannot use the plugin flow, configure the AWS MCP Server directly through the MCP Proxy for AWS.\n\nExample Claude Code configuration:\n\n```\nclaude mcp add-json aws-mcp --scope user \\\n'{\n  \"command\": \"uvx\",\n  \"args\": [\n    \"mcp-proxy-for-aws\",\n    \"https://aws-mcp.us-east-1.api.aws/mcp\",\n    \"--metadata\",\n    \"AWS_REGION=us-east-1\"\n  ],\n  \"env\": {\n    \"AWS_PROFILE\": \"sec-mcp-readonly\"\n  }\n}'\n```\n\nFor Codex, place the MCP server configuration in your Codex config file.\n\nExample concept:\n\n```\n[mcp_servers.aws-mcp]\ncommand = \"uvx\"\nargs = [\n  \"mcp-proxy-for-aws\",\n  \"https://aws-mcp.us-east-1.api.aws/mcp\",\n  \"--metadata\",\n  \"AWS_REGION=us-east-1\"\n]\n\n[mcp_servers.aws-mcp.env]\nAWS_PROFILE = \"sec-mcp-readonly\"\n```\n\nFor multi-account security teams, configure an explicit profile allowlist. Do not let the agent discover or use every AWS profile on the workstation.\n\nExample concept:\n\n```\nAWS_MCP_PROXY_PROFILES=\"sec-mcp-readonly prod-readonly security-readonly\"\n```\n\nThe default profile should be read-only.\n\nThe security posture should be tool-specific.\n\nRecommended pilot posture:\n\n| Tool type | Pilot setting | Rationale |\n|---|---|---|\n| AWS documentation search | Allow | Low risk and high value |\n| AWS read-only API call | Ask / approve | Lets the engineer verify account and region |\n| AWS script execution | Deny or ask | Can create broad data access and complex behavior |\n| Presigned URL generation | Deny | Not needed for Security Hub triage |\n| File write to local project | Allow to approved output folder | Needed for evidence pack |\n| Shell command execution | Ask | Can expose local files or environment variables |\n| Git operations | Ask | Prevents accidental commits or pushes |\n\nA good project rule is:\n\n```\nThis project is a read-only AWS Security Hub triage workflow.\n\nThe agent may:\n- Read Security Hub, GuardDuty, Inspector, Config, CloudTrail, and AWS documentation using the sec-mcp-readonly profile.\n- Write markdown, CSV, and JSON files only under ./output.\n- Draft remediation recommendations.\n\nThe agent must not:\n- Modify AWS resources.\n- Suppress, archive, import, or update Security Hub findings.\n- Read secrets, credentials, environment files, customer PII, or raw sensitive logs.\n- Commit, push, merge, deploy, or approve changes.\n- Run remediation automatically.\nmkdir -p securityhub-mcp-triage/{prompts,filters,output,evidence}\ncd securityhub-mcp-triage\n```\n\nRecommended structure:\n\n```\nsecurityhub-mcp-triage/\n  prompts/\n    securityhub-triage.md\n  filters/\n    securityhub-critical-high.json\n  output/\n  evidence/\n```\n\nKeep this folder separate from application repositories. It should not contain source code, credentials, `.env`\n\nfiles, or customer data.\n\nCreate `filters/securityhub-critical-high.json`\n\n:\n\n```\n{\n  \"WorkflowStatus\": [\n    {\n      \"Value\": \"NEW\",\n      \"Comparison\": \"EQUALS\"\n    },\n    {\n      \"Value\": \"NOTIFIED\",\n      \"Comparison\": \"EQUALS\"\n    }\n  ],\n  \"RecordState\": [\n    {\n      \"Value\": \"ACTIVE\",\n      \"Comparison\": \"EQUALS\"\n    }\n  ],\n  \"SeverityLabel\": [\n    {\n      \"Value\": \"CRITICAL\",\n      \"Comparison\": \"EQUALS\"\n    },\n    {\n      \"Value\": \"HIGH\",\n      \"Comparison\": \"EQUALS\"\n    }\n  ]\n}\n```\n\nOptional CLI validation:\n\n```\naws securityhub get-findings \\\n  --profile sec-mcp-readonly \\\n  --region us-east-1 \\\n  --filters file://filters/securityhub-critical-high.json \\\n  --max-results 25 \\\n  > evidence/securityhub-critical-high-sample.json\n```\n\nThis gives the engineer a known-good baseline before asking the agent to reason over the findings.\n\nCreate `prompts/securityhub-triage.md`\n\n:\n\n```\nYou are supporting a read-only AWS Security Hub triage workflow.\n\nOperating constraints:\n- Use AWS profile: sec-mcp-readonly.\n- Use region: us-east-1 unless findings indicate another region.\n- Read only. Do not modify AWS resources.\n- Do not suppress, archive, import, update, or resolve findings.\n- Do not access secrets, credentials, customer PII, or raw sensitive incident logs.\n- Do not run remediation.\n- Do not commit, push, merge, deploy, or approve changes.\n- Write outputs only under ./output.\n\nTask:\n1. Retrieve active CRITICAL and HIGH Security Hub findings using filters/securityhub-critical-high.json.\n2. Group findings by:\n   - AWS account\n   - Region\n   - Severity\n   - Product/source\n   - Resource type\n   - Control ID or finding type\n3. For each group, explain:\n   - Why it matters\n   - Failure mode\n   - Likely owner\n   - Recommended remediation\n   - Evidence required\n   - Whether it is immediate risk or backlog\n4. Produce the following files:\n   - output/securityhub-executive-summary.md\n   - output/securityhub-technical-findings.md\n   - output/securityhub-remediation-backlog.csv\n   - output/securityhub-evidence-index.md\n5. Include a final section called \"Human review required\" listing anything that must be confirmed manually.\n\nPrioritization rules:\n- Internet exposure in production is immediate.\n- Privileged IAM or access analyzer findings are immediate.\n- Critical exploitable vulnerabilities on internet-facing workloads are immediate.\n- Missing encryption on sensitive data stores is high priority.\n- Missing logging or monitoring is high priority, but may be backlog if compensating controls exist.\n- Anything involving possible data exposure must be escalated to the SOC or incident commander.\n```\n\nThis prompt does three important things:\n\nThat is what makes the workflow repeatable.\n\nOpen Claude Code in the project folder.\n\n```\ncd securityhub-mcp-triage\nclaude\n```\n\nThen run:\n\n```\nUse prompts/securityhub-triage.md and perform the Security Hub triage workflow.\nBefore using any AWS MCP tool, show me the planned tool call, account/profile, region, and purpose.\n```\n\nDuring tool approval, verify:\n\n`sec-mcp-readonly`\n\n.If the agent asks to use a write action, stop the run and fix the permissions or project rules.\n\nIn Codex:\n\n```\ncd securityhub-mcp-triage\ncodex\n```\n\nPrompt:\n\n```\nUse prompts/securityhub-triage.md and produce the required output files.\nUse only the configured AWS MCP server and the sec-mcp-readonly profile.\nAsk before each AWS API tool call.\nDo not run write actions or remediation.\n```\n\nSame review logic applies:\n\nThe workflow should produce four local files.\n\n`output/securityhub-executive-summary.md`\n\nThis file should be leadership-readable.\n\nExample structure:\n\n```\n# Security Hub Executive Summary\n\nDate: 2026-07-16\nAWS profile: sec-mcp-readonly\nRegion: us-east-1\nScope: Active CRITICAL/HIGH findings\n\n## Summary\n\nTotal active CRITICAL/HIGH findings reviewed: 42\n\nImmediate action required: 6\nHigh priority remediation: 18\nBacklog / owner validation: 18\n\n## Key risk themes\n\n1. Public exposure on internet-facing resources\n2. Privileged IAM misconfiguration\n3. Inspector critical vulnerabilities on production EC2\n4. Missing encryption on data stores\n5. Security logging gaps\n\n## Immediate escalation\n\nThe following findings require same-day owner response...\n```\n\n`output/securityhub-technical-findings.md`\n\nThis file should be engineer-readable.\n\nExample:\n\n```\n## Finding group: Public S3 bucket exposure\n\nPriority: Immediate\n\nAffected resources:\n- arn:aws:s3:::example-prod-export-bucket\n\nWhy it matters:\nA public S3 bucket in a production account creates direct data exposure risk.\nIf the bucket contains logs, exports, backups, or customer data, the issue may become a reportable incident.\n\nFailure mode:\nAn attacker or external party can access exposed objects without authentication.\nIf bucket contents include credentials, logs, exports, or regulated data, this can lead to data breach, credential compromise, and compliance exposure.\n\nRequired remediation:\n- Confirm business owner.\n- Validate whether bucket is intentionally public.\n- Enable S3 Block Public Access at account and bucket level unless explicitly approved.\n- Review bucket policy and ACL.\n- Review CloudTrail data events if enabled.\n- Assess object sensitivity.\n- Open incident if sensitive data was exposed.\n\nEvidence required:\n- Security Hub finding JSON.\n- S3 bucket policy export.\n- Public access block configuration.\n- Object sensitivity confirmation from data owner.\n- CloudTrail access review.\n```\n\n`output/securityhub-remediation-backlog.csv`\n\nExample columns:\n\n```\npriority,severity,account,region,resource_type,resource_id,finding_title,recommended_owner,remediation_action,evidence_required,sla,notes\nImmediate,CRITICAL,123456789012,us-east-1,S3,bucket-name,Public bucket exposure,Data Platform,Disable public access and validate exposure,Finding JSON; bucket policy; access review,Same day,Escalate if sensitive data exists\n```\n\n`output/securityhub-evidence-index.md`\n\nExample:\n\n```\n# Evidence Index\n\n## Evidence collected\n\n- Security Hub finding export\n- Finding group summary\n- AWS account and region\n- Resource identifiers\n- Remediation backlog\n- Negative-control test showing write actions fail\n\n## Evidence not collected\n\n- Raw customer logs\n- Secrets\n- PII\n- Full object contents\n```\n\nUse a practical triage model.\n\n| Priority | Criteria | Response expectation |\n|---|---|---|\n| Immediate | Active internet exposure, privileged IAM risk, possible data exposure, exploited vulnerability, production blast radius | Same-day owner response and SOC visibility |\n| High | Security control failure on sensitive or production resources | Remediation ticket with SLA |\n| Medium | Misconfiguration with limited exposure or compensating controls | Backlog with owner and due date |\n| Informational | Hygiene issue, duplicate finding, non-production low impact | Track, tune, or suppress through approved process |\n\nPriority is not only the Security Hub severity label.\n\nSecurity Hub severity matters, but real prioritization should also consider:\n\nThat is where the agent can help, but the human still owns the decision.\n\nKeep these artifacts:\n\n| Evidence | Why it matters |\n|---|---|\n| IAM permission set export | Shows least privilege scope |\n| IAM policy JSON | Shows allowed and denied actions |\n| SCP or permission boundary export | Shows preventive guardrail |\n| AWS CLI identity check | Proves named identity |\n| Security Hub finding export | Shows source evidence |\n| Output files | Shows triage result |\n| Negative-control test | Proves write actions fail |\n| Tool approval log or session transcript | Shows human oversight |\n| Jira tickets | Shows remediation ownership |\n| Slack or incident notes | Shows escalation path |\n\nDo not store:\n\nA safe rollout must include a negative-control test.\n\nTest one prohibited write action in a non-production or controlled environment:\n\n```\naws securityhub batch-update-findings \\\n  --profile sec-mcp-readonly \\\n  --region us-east-1 \\\n  --finding-identifiers '[{\"Id\":\"test\",\"ProductArn\":\"arn:aws:securityhub:us-east-1::product/aws/securityhub\"}]' \\\n  --workflow '{\"Status\":\"SUPPRESSED\"}'\n```\n\nExpected result:\n\n```\nAccessDeniedException\n```\n\nKeep the result as evidence.\n\nIf the command succeeds, the design is not approved.\n\n| Failure mode | What can go wrong | Required control |\n|---|---|---|\n| Agent gains write access | Findings are suppressed or resources are modified | IAM explicit deny, SCP, permission boundary |\n| Prompt injection through finding text | Agent follows malicious instructions embedded in external content | Treat findings as untrusted data, use strict project rules |\n| Excessive data retrieval | Agent pulls sensitive logs or PII into local files | Data minimization, deny secret/PII access, output path controls |\n| Wrong AWS account | Agent queries or reports the wrong account | SSO profile naming, `sts:GetCallerIdentity` , account allowlist |\n| Poor prioritization | Critical exposure is treated as backlog | Human review and explicit prioritization rules |\n| No audit trail | Outputs cannot be defended in audit | Tool logs, CloudTrail, evidence index, ticket linkage |\n| Auto-remediation drift | AI makes changes outside change control | No write access, CI/CD remains release authority |\n| Public or untrusted MCP server | Credentials or data are exposed | Use official/vendor/internal MCP servers only |\n\nFor a single engineer or small pilot, AWS Agent Toolkit plus read-only IAM is enough.\n\nFor enterprise use, evaluate AWS AgentCore Gateway.\n\nThe reason is governance.\n\nAs MCP usage grows, security teams eventually need:\n\nRecommended maturity path:\n\n```\nPilot: AWS Agent Toolkit + AWS MCP Server + read-only IAM profile\nScale: Add centralized governance and gateway controls\nCustom: Build private MCP servers only for internal systems that are not covered\n```\n\nDo not start by building a custom MCP platform unless you already have a clear internal integration gap.\n\nBest first use case.\n\nInput:\n\nOutput:\n\nRisk: low if read-only.\n\nThe agent can help explain:\n\nDo not let the agent disable keys, quarantine instances, or modify policies automatically.\n\nThe agent can group Inspector findings by:\n\nThe output can be a CSV remediation backlog.\n\nDo not let the agent patch systems automatically.\n\nThe agent can summarize:\n\nDo not let the agent change IAM policy.\n\nThe agent can collect read-only evidence for:\n\nThis is useful before audits, risk reviews, and architecture reviews.\n\nI would not frame this as Claude Code versus Codex.\n\nI would use both where they are strongest.\n\n| Tool | Best use | Security posture |\n|---|---|---|\n| Claude Code | Deep reasoning, architecture review, long-form security analysis, runbook drafting | Strong project rules and tool approval |\n| Codex | Code changes, CLI-driven development workflow, reproducible implementation tasks | Sandbox, approval policy, repo controls |\n| AWS MCP Server | AWS documentation and authenticated AWS API access | IAM-enforced read-only first |\n| CI/CD | Tests, scanning, deployment, policy gates | Release authority remains outside the AI tool |\n\nFor security work, the safest split is:\n\n```\nClaude Code: analyze and explain\nCodex: implement controlled code changes\nAWS MCP Server: retrieve AWS context\nCI/CD: validate and release\nHuman owner: approve risk and remediation\n```\n\nThe AI tool can accelerate the workflow, but it should not become the approval authority.\n\nUse this workflow for daily or weekly triage.\n\nConfirm:\n\n`sec-mcp-readonly`\n\n.`./output`\n\n.`aws sts get-caller-identity`\n\n.`prompts/securityhub-triage.md`\n\n.Security Hub:\n\n``` php\nAWS Console -> Security Hub -> Findings\n```\n\nGuardDuty:\n\n``` php\nAWS Console -> GuardDuty -> Findings\n```\n\nInspector:\n\n``` php\nAWS Console -> Inspector -> Findings\n```\n\nCloudTrail:\n\n``` php\nAWS Console -> CloudTrail -> Event history\n```\n\nConfig:\n\n``` php\nAWS Console -> AWS Config -> Resources / Advanced queries\n```\n\nS3 public access:\n\n``` php\nAWS Console -> S3 -> Bucket -> Permissions -> Block Public Access / Bucket policy\n```\n\nManual validation matters because MCP output is an aid, not evidence by itself.\n\nFix in this order:\n\nThe top of the list is about blast radius and business impact, not just severity labels.\n\nEven with read-only IAM and MCP controls, some risk remains.\n\nResidual risks include:\n\nAcceptable residual risk for a pilot:\n\n```\nRead-only triage and evidence drafting with human review.\n```\n\nNot acceptable for a pilot:\n\n```\nAutomated suppression, remediation, policy changes, deployments, or risk acceptance.\nDecision: Approved with conditions.\n\nWe can pilot AWS MCP Server through AWS Agent Toolkit for a read-only Security Hub triage workflow.\n\nApproved scope:\n- Read Security Hub findings.\n- Read limited investigation context from GuardDuty, Inspector, Config, CloudTrail, Organizations, and Access Analyzer.\n- Generate local markdown/CSV/JSON summaries.\n- Draft remediation tickets and Slack summaries.\n\nNot approved:\n- Security Hub suppression or updates.\n- AWS resource changes.\n- IAM changes.\n- Secret or PII access.\n- Automated remediation.\n- AI-approved exception, merge, deploy, or risk acceptance.\n\nRequired controls:\n- Named SSO identity.\n- Dedicated SecMCPReadOnly permission set.\n- Explicit deny for write actions.\n- SCP or permission boundary for production where possible.\n- MCP tool approval enabled.\n- Script execution denied or separately approved.\n- CloudTrail audit visibility.\n- Negative-control test proving write actions fail.\n\nResidual risk is acceptable for a read-only pilot with human review.\n```\n\nStart with a narrow, governed workflow:\n\n```\nUse case: Security Hub triage\nAgent: Claude Code or Codex\nConnector: AWS Agent Toolkit / AWS MCP Server\nAWS identity: SecMCPReadOnly\nPermissions: read-only + explicit deny\nOutput: executive summary, technical findings, remediation backlog, evidence index\nApproval: human review before tickets, suppression, remediation, or risk acceptance\n```\n\nDo not build a custom MCP server first.\n\nDo not give the agent production write access.\n\nDo not let the agent suppress findings or approve exceptions.\n\nGet the read-only triage workflow working, prove the controls, collect evidence, and then decide whether more advanced workflows are justified.\n\nThat is the safe path from AI-assisted security work to production-grade security operations.", "url": "https://wpnews.pro/news/mcp-for-aws-security-engineers-build-a-read-only-security-hub-triage-agent", "canonical_source": "https://dev.to/mike_anderson_d01f52129fb/mcp-for-aws-security-engineers-build-a-read-only-security-hub-triage-agent-1iep", "published_at": "2026-07-16 09:54:32+00:00", "updated_at": "2026-07-16 10:04:22.723056+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure", "developer-tools", "ai-tools"], "entities": ["AWS", "AWS Agent Toolkit", "AWS MCP Server", "Claude Code", "Codex", "Security Hub"], "alternates": {"html": "https://wpnews.pro/news/mcp-for-aws-security-engineers-build-a-read-only-security-hub-triage-agent", "markdown": "https://wpnews.pro/news/mcp-for-aws-security-engineers-build-a-read-only-security-hub-triage-agent.md", "text": "https://wpnews.pro/news/mcp-for-aws-security-engineers-build-a-read-only-security-hub-triage-agent.txt", "jsonld": "https://wpnews.pro/news/mcp-for-aws-security-engineers-build-a-read-only-security-hub-triage-agent.jsonld"}}