MCP for AWS Security Engineers: Build a Read-Only Security Hub Triage Agent

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.

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. The 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. For security teams, that is the right starting point because the enforcement point remains AWS IAM, not the model. The initial operating model should be strict: That 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. This article walks through a practical security workflow: A 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. The agent will be able to: The agent will not be able to: This 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. MCP stands for Model Context Protocol. In 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. A simple mental model: LLM / Agent | | asks for context or tool execution v MCP Client | | speaks MCP v MCP Server | | exposes approved tools and data v AWS / GitHub / Jira / Security Hub / Internal APIs MCP is not the model . MCP is not Claude . MCP is not Codex . MCP is the connector layer that lets an AI tool interact with approved external capabilities in a consistent way. A practical comparison: | Component | What it is | Example | |---|---|---| | AI model | The reasoning engine | Claude, GPT, Nova, Qwen | | Agent client | The user-facing agent tool | Claude Code, Codex, Cursor, Kiro | | MCP server | The tool and data connector | AWS MCP Server, GitHub MCP Server | | Tool | An action exposed by the server | securityhub:GetFindings , documentation search | | Resource | Read-only context exposed by the server | Documentation, metadata, finding details | | IAM / policy | The enforcement layer | AWS role, SCP, permission boundary | The important security point is simple: MCP gives the agent hands. IAM decides what those hands are allowed to touch. An MCP server exposes capabilities to an AI agent. Those capabilities usually fall into three areas: | MCP capability | Meaning | Security impact | |---|---|---| | Tools | Callable functions or actions | Can be read-only or mutating | | Resources | Context or data the model can read | Usually safer, but can expose sensitive data | | Prompts | Reusable task templates | Useful for standardized workflows | That matters because a junior engineer may think, “The model only answers questions.” That assumption is no longer safe once tools are attached. With MCP, the model may be able to: That is why the first security decision is not: Which model should we use? The first security decision is: What tool permissions will this agent have, and where are those permissions enforced? For production security work, the model must never be treated as the control boundary. The control boundary must be: A useful operating model is: php Prompt - Agent loop - MCP tools - External systems - Evidence/output The agent loop is the cycle where the model reasons, requests a tool, receives the result, reasons again, and continues until the task is complete. The harness is everything around that loop: tool permissions, context management, project rules, logs, approval gates, hooks, and safety boundaries. For security work, MCP sits inside the harness. Claude Code / Codex | | project rules, approval mode, permissions v MCP client | | approved tool calls only v AWS MCP Server | | authenticated AWS API access v AWS IAM role / permission set | | read-only Security Hub permissions v AWS Security Hub That distinction is important. The model can recommend. The harness controls. IAM enforces. Security work is context-heavy. A security engineer rarely needs a generic answer. We need the assistant to understand: Without MCP, the engineer manually copies and pastes data into the AI tool. With MCP, the agent can retrieve approved read-only data directly and produce a consistent investigation output. Useful security workflows include: But MCP is not magic. It does not replace security ownership, SOC judgment, IAM design, threat modeling, change control, CI/CD gates, incident commander decisions, or audit evidence review. MCP should reduce manual collection and improve consistency. It should not become an ungoverned SOAR platform. 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. For AWS security work, start with: | Use case | Build your own MCP server? | Recommended path | |---|---|---| | AWS documentation lookup | No | AWS Agent Toolkit / AWS MCP Server | | Security Hub read-only triage | No, initially | AWS MCP Server with read-only IAM | | GuardDuty / Inspector / Macie review | No, initially | AWS MCP Server with scoped read-only permissions | | Jira ticket drafting | Usually no | Vendor MCP server or local draft output | | GitHub repo analysis | Usually no | GitHub MCP or native repo context with repo-scoped permissions | | Internal CMDB enrichment | Maybe | Internal read-only MCP server | | Internal GRC evidence register | Maybe | Private MCP server or API wrapper | | Automated remediation | Not initially | Keep outside MCP until governance is mature | | Security Hub suppression/update | No for junior workflow | Human and SOC-approved process only | Use this priority order for MCP servers: Be careful with random public MCP servers. For a security team, an MCP server is not a harmless browser extension. It is a privileged integration point. A malicious or poorly written MCP server can become: Treat MCP servers like production integrations. AWS Agent Toolkit provides plugins that bundle AWS MCP Server configuration and curated AWS skills for agent workflows. For the workflow in this article, the relevant AWS MCP Server capabilities are: | Capability | Use in this workflow | Initial recommendation | |---|---|---| | Documentation search | Explain Security Hub controls and AWS service behavior | Allow | | AWS API calls | Read Security Hub, GuardDuty, Inspector, Config, and CloudTrail context | Allow only through read-only IAM | | Sandboxed script execution | Run multi-step AWS checks | Disable or require explicit approval at pilot stage | | Presigned URL generation | File transfer support | Disable unless specifically needed | | Long-running task polling | Check status of API/script tasks | Allow only if required | For 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. Security Engineer | | asks question in Claude Code or Codex v Claude Code / Codex | | MCP client v AWS Agent Toolkit / AWS MCP Server | | authenticated request v AWS IAM Identity Center profile: sec-mcp-readonly | | read-only permissions only v AWS Security Hub | | Get / List / Describe / BatchGet only v Local output files | | markdown summary, CSV backlog, JSON evidence v Human review | | Jira / Slack / audit evidence The key design choice is that the agent can read and reason , but it cannot change the environment . This aligns with a production cloud security baseline: least privilege, centralized identity, MFA, guardrails, logging, evidence retention, and clear owner accountability. Use IAM Identity Center if available. Create a permission set: Permission set name: SecMCPReadOnly Session duration: 4 hours Assigned group: SecurityEngineering-MCP-ReadOnly Accounts: security tooling account and selected workload accounts MFA: required through IdP / IAM Identity Center Do not use: Use a named human identity with SSO. The goal is that every MCP-driven AWS API call is attributable to a real engineer. AWS 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. { "Version": "2012-10-17", "Statement": { "Sid": "AllowIdentityCheck", "Effect": "Allow", "Action": "sts:GetCallerIdentity" , "Resource": " " }, { "Sid": "AllowSecurityHubReadOnly", "Effect": "Allow", "Action": "securityhub:Get ", "securityhub:List ", "securityhub:Describe ", "securityhub:BatchGet " , "Resource": " " }, { "Sid": "AllowReadOnlyInvestigationContext", "Effect": "Allow", "Action": "cloudtrail:LookupEvents", "guardduty:GetFindings", "guardduty:ListFindings", "guardduty:ListDetectors", "inspector2:ListFindings", "access-analyzer:ListFindings", "access-analyzer:GetFinding", "organizations:DescribeOrganization", "organizations:ListAccounts", "config:SelectResourceConfig", "config:GetResourceConfigHistory" , "Resource": " " }, { "Sid": "DenyWriteActionsForMCPPilot", "Effect": "Deny", "Action": "securityhub:BatchUpdateFindings", "securityhub:BatchImportFindings", "securityhub:Update ", "securityhub:Delete ", "securityhub:Disable ", "securityhub:Enable ", "securityhub:Create ", "securityhub:TagResource", "securityhub:UntagResource", "iam: ", "s3:Put ", "s3:Delete ", "ec2:AuthorizeSecurityGroupIngress", "ec2:AuthorizeSecurityGroupEgress", "ec2:RevokeSecurityGroupIngress", "ec2:RevokeSecurityGroupEgress", "kms:Put ", "kms:ScheduleKeyDeletion", "config:Put ", "config:Delete ", "guardduty:Update ", "guardduty:Delete ", "inspector2:Update ", "inspector2:BatchUpdate " , "Resource": " " } } The explicit deny is not there because the allow statement grants those actions. It does not. The explicit deny is there because real environments are messy. A 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. For production accounts, pair this with an SCP or permission boundary where possible. For production accounts, I would add an organization-level safety net. Example SCP concept: { "Version": "2012-10-17", "Statement": { "Sid": "PreventMCPReadOnlyRoleFromMutatingSecurityHub", "Effect": "Deny", "Action": "securityhub:BatchUpdateFindings", "securityhub:Update ", "securityhub:Delete ", "securityhub:Disable ", "securityhub:Enable ", "securityhub:Create " , "Resource": " ", "Condition": { "ArnLike": { "aws:PrincipalArn": "arn:aws:iam:: :role/aws-reserved/sso.amazonaws.com/ /AWSReservedSSO SecMCPReadOnly " } } } } Test this carefully in a non-production account before applying it broadly. The SCP should not block the SOC, security tooling account, CI/CD remediation roles, or incident response break-glass roles. The objective is narrow: This MCP read-only role must never mutate Security Hub findings or configuration. Install or update the AWS CLI, then configure SSO: aws configure sso --profile sec-mcp-readonly Validate the identity: aws sts get-caller-identity --profile sec-mcp-readonly Expected output: { "UserId": "AROAXXXXX:security.engineer@example.com", "Account": "123456789012", "Arn": "arn:aws:sts::123456789012:assumed-role/AWSReservedSSO SecMCPReadOnly xxxxx/security.engineer@example.com" } Then test Security Hub read access: aws securityhub get-findings \ --profile sec-mcp-readonly \ --region us-east-1 \ --max-results 5 Now test that write access fails: aws securityhub batch-update-findings \ --profile sec-mcp-readonly \ --region us-east-1 \ --finding-identifiers ' {"Id":"test","ProductArn":"arn:aws:securityhub:us-east-1::product/aws/securityhub"} ' \ --workflow '{"Status":"SUPPRESSED"}' Expected result: AccessDeniedException Keep that negative-control result as rollout evidence. In Claude Code, install the AWS plugin: /plugin install aws-core@claude-plugins-official /reload-plugins Then validate that the AWS MCP server is visible: /mcp For the pilot, I would configure Claude Code so AWS API calls require approval and script execution is denied or requires explicit human approval. The point is not to slow engineers down. The point is to prevent the first rollout from quietly becoming an unapproved automation channel. For Codex, AWS documents plugin setup through the Codex plugin marketplace: codex plugin marketplace add aws/agent-toolkit-for-aws Then open Codex and use: /plugins Install the aws-core plugin. For the pilot, configure Codex so MCP tools are explicitly approved and write-capable tools are disabled or denied. The exact approval configuration may vary by Codex version, so validate against the current Codex configuration reference before publishing your internal runbook. If you cannot use the plugin flow, configure the AWS MCP Server directly through the MCP Proxy for AWS. Example Claude Code configuration: claude mcp add-json aws-mcp --scope user \ '{ "command": "uvx", "args": "mcp-proxy-for-aws", "https://aws-mcp.us-east-1.api.aws/mcp", "--metadata", "AWS REGION=us-east-1" , "env": { "AWS PROFILE": "sec-mcp-readonly" } }' For Codex, place the MCP server configuration in your Codex config file. Example concept: mcp servers.aws-mcp command = "uvx" args = "mcp-proxy-for-aws", "https://aws-mcp.us-east-1.api.aws/mcp", "--metadata", "AWS REGION=us-east-1" mcp servers.aws-mcp.env AWS PROFILE = "sec-mcp-readonly" For multi-account security teams, configure an explicit profile allowlist. Do not let the agent discover or use every AWS profile on the workstation. Example concept: AWS MCP PROXY PROFILES="sec-mcp-readonly prod-readonly security-readonly" The default profile should be read-only. The security posture should be tool-specific. Recommended pilot posture: | Tool type | Pilot setting | Rationale | |---|---|---| | AWS documentation search | Allow | Low risk and high value | | AWS read-only API call | Ask / approve | Lets the engineer verify account and region | | AWS script execution | Deny or ask | Can create broad data access and complex behavior | | Presigned URL generation | Deny | Not needed for Security Hub triage | | File write to local project | Allow to approved output folder | Needed for evidence pack | | Shell command execution | Ask | Can expose local files or environment variables | | Git operations | Ask | Prevents accidental commits or pushes | A good project rule is: This project is a read-only AWS Security Hub triage workflow. The agent may: - Read Security Hub, GuardDuty, Inspector, Config, CloudTrail, and AWS documentation using the sec-mcp-readonly profile. - Write markdown, CSV, and JSON files only under ./output. - Draft remediation recommendations. The agent must not: - Modify AWS resources. - Suppress, archive, import, or update Security Hub findings. - Read secrets, credentials, environment files, customer PII, or raw sensitive logs. - Commit, push, merge, deploy, or approve changes. - Run remediation automatically. mkdir -p securityhub-mcp-triage/{prompts,filters,output,evidence} cd securityhub-mcp-triage Recommended structure: securityhub-mcp-triage/ prompts/ securityhub-triage.md filters/ securityhub-critical-high.json output/ evidence/ Keep this folder separate from application repositories. It should not contain source code, credentials, .env files, or customer data. Create filters/securityhub-critical-high.json : { "WorkflowStatus": { "Value": "NEW", "Comparison": "EQUALS" }, { "Value": "NOTIFIED", "Comparison": "EQUALS" } , "RecordState": { "Value": "ACTIVE", "Comparison": "EQUALS" } , "SeverityLabel": { "Value": "CRITICAL", "Comparison": "EQUALS" }, { "Value": "HIGH", "Comparison": "EQUALS" } } Optional CLI validation: aws securityhub get-findings \ --profile sec-mcp-readonly \ --region us-east-1 \ --filters file://filters/securityhub-critical-high.json \ --max-results 25 \ evidence/securityhub-critical-high-sample.json This gives the engineer a known-good baseline before asking the agent to reason over the findings. Create prompts/securityhub-triage.md : You are supporting a read-only AWS Security Hub triage workflow. Operating constraints: - Use AWS profile: sec-mcp-readonly. - Use region: us-east-1 unless findings indicate another region. - Read only. Do not modify AWS resources. - Do not suppress, archive, import, update, or resolve findings. - Do not access secrets, credentials, customer PII, or raw sensitive incident logs. - Do not run remediation. - Do not commit, push, merge, deploy, or approve changes. - Write outputs only under ./output. Task: 1. Retrieve active CRITICAL and HIGH Security Hub findings using filters/securityhub-critical-high.json. 2. Group findings by: - AWS account - Region - Severity - Product/source - Resource type - Control ID or finding type 3. For each group, explain: - Why it matters - Failure mode - Likely owner - Recommended remediation - Evidence required - Whether it is immediate risk or backlog 4. Produce the following files: - output/securityhub-executive-summary.md - output/securityhub-technical-findings.md - output/securityhub-remediation-backlog.csv - output/securityhub-evidence-index.md 5. Include a final section called "Human review required" listing anything that must be confirmed manually. Prioritization rules: - Internet exposure in production is immediate. - Privileged IAM or access analyzer findings are immediate. - Critical exploitable vulnerabilities on internet-facing workloads are immediate. - Missing encryption on sensitive data stores is high priority. - Missing logging or monitoring is high priority, but may be backlog if compensating controls exist. - Anything involving possible data exposure must be escalated to the SOC or incident commander. This prompt does three important things: That is what makes the workflow repeatable. Open Claude Code in the project folder. cd securityhub-mcp-triage claude Then run: Use prompts/securityhub-triage.md and perform the Security Hub triage workflow. Before using any AWS MCP tool, show me the planned tool call, account/profile, region, and purpose. During tool approval, verify: sec-mcp-readonly .If the agent asks to use a write action, stop the run and fix the permissions or project rules. In Codex: cd securityhub-mcp-triage codex Prompt: Use prompts/securityhub-triage.md and produce the required output files. Use only the configured AWS MCP server and the sec-mcp-readonly profile. Ask before each AWS API tool call. Do not run write actions or remediation. Same review logic applies: The workflow should produce four local files. output/securityhub-executive-summary.md This file should be leadership-readable. Example structure: Security Hub Executive Summary Date: 2026-07-16 AWS profile: sec-mcp-readonly Region: us-east-1 Scope: Active CRITICAL/HIGH findings Summary Total active CRITICAL/HIGH findings reviewed: 42 Immediate action required: 6 High priority remediation: 18 Backlog / owner validation: 18 Key risk themes 1. Public exposure on internet-facing resources 2. Privileged IAM misconfiguration 3. Inspector critical vulnerabilities on production EC2 4. Missing encryption on data stores 5. Security logging gaps Immediate escalation The following findings require same-day owner response... output/securityhub-technical-findings.md This file should be engineer-readable. Example: Finding group: Public S3 bucket exposure Priority: Immediate Affected resources: - arn:aws:s3:::example-prod-export-bucket Why it matters: A public S3 bucket in a production account creates direct data exposure risk. If the bucket contains logs, exports, backups, or customer data, the issue may become a reportable incident. Failure mode: An attacker or external party can access exposed objects without authentication. If bucket contents include credentials, logs, exports, or regulated data, this can lead to data breach, credential compromise, and compliance exposure. Required remediation: - Confirm business owner. - Validate whether bucket is intentionally public. - Enable S3 Block Public Access at account and bucket level unless explicitly approved. - Review bucket policy and ACL. - Review CloudTrail data events if enabled. - Assess object sensitivity. - Open incident if sensitive data was exposed. Evidence required: - Security Hub finding JSON. - S3 bucket policy export. - Public access block configuration. - Object sensitivity confirmation from data owner. - CloudTrail access review. output/securityhub-remediation-backlog.csv Example columns: priority,severity,account,region,resource type,resource id,finding title,recommended owner,remediation action,evidence required,sla,notes Immediate,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 output/securityhub-evidence-index.md Example: Evidence Index Evidence collected - Security Hub finding export - Finding group summary - AWS account and region - Resource identifiers - Remediation backlog - Negative-control test showing write actions fail Evidence not collected - Raw customer logs - Secrets - PII - Full object contents Use a practical triage model. | Priority | Criteria | Response expectation | |---|---|---| | Immediate | Active internet exposure, privileged IAM risk, possible data exposure, exploited vulnerability, production blast radius | Same-day owner response and SOC visibility | | High | Security control failure on sensitive or production resources | Remediation ticket with SLA | | Medium | Misconfiguration with limited exposure or compensating controls | Backlog with owner and due date | | Informational | Hygiene issue, duplicate finding, non-production low impact | Track, tune, or suppress through approved process | Priority is not only the Security Hub severity label. Security Hub severity matters, but real prioritization should also consider: That is where the agent can help, but the human still owns the decision. Keep these artifacts: | Evidence | Why it matters | |---|---| | IAM permission set export | Shows least privilege scope | | IAM policy JSON | Shows allowed and denied actions | | SCP or permission boundary export | Shows preventive guardrail | | AWS CLI identity check | Proves named identity | | Security Hub finding export | Shows source evidence | | Output files | Shows triage result | | Negative-control test | Proves write actions fail | | Tool approval log or session transcript | Shows human oversight | | Jira tickets | Shows remediation ownership | | Slack or incident notes | Shows escalation path | Do not store: A safe rollout must include a negative-control test. Test one prohibited write action in a non-production or controlled environment: aws securityhub batch-update-findings \ --profile sec-mcp-readonly \ --region us-east-1 \ --finding-identifiers ' {"Id":"test","ProductArn":"arn:aws:securityhub:us-east-1::product/aws/securityhub"} ' \ --workflow '{"Status":"SUPPRESSED"}' Expected result: AccessDeniedException Keep the result as evidence. If the command succeeds, the design is not approved. | Failure mode | What can go wrong | Required control | |---|---|---| | Agent gains write access | Findings are suppressed or resources are modified | IAM explicit deny, SCP, permission boundary | | Prompt injection through finding text | Agent follows malicious instructions embedded in external content | Treat findings as untrusted data, use strict project rules | | Excessive data retrieval | Agent pulls sensitive logs or PII into local files | Data minimization, deny secret/PII access, output path controls | | Wrong AWS account | Agent queries or reports the wrong account | SSO profile naming, sts:GetCallerIdentity , account allowlist | | Poor prioritization | Critical exposure is treated as backlog | Human review and explicit prioritization rules | | No audit trail | Outputs cannot be defended in audit | Tool logs, CloudTrail, evidence index, ticket linkage | | Auto-remediation drift | AI makes changes outside change control | No write access, CI/CD remains release authority | | Public or untrusted MCP server | Credentials or data are exposed | Use official/vendor/internal MCP servers only | For a single engineer or small pilot, AWS Agent Toolkit plus read-only IAM is enough. For enterprise use, evaluate AWS AgentCore Gateway. The reason is governance. As MCP usage grows, security teams eventually need: Recommended maturity path: Pilot: AWS Agent Toolkit + AWS MCP Server + read-only IAM profile Scale: Add centralized governance and gateway controls Custom: Build private MCP servers only for internal systems that are not covered Do not start by building a custom MCP platform unless you already have a clear internal integration gap. Best first use case. Input: Output: Risk: low if read-only. The agent can help explain: Do not let the agent disable keys, quarantine instances, or modify policies automatically. The agent can group Inspector findings by: The output can be a CSV remediation backlog. Do not let the agent patch systems automatically. The agent can summarize: Do not let the agent change IAM policy. The agent can collect read-only evidence for: This is useful before audits, risk reviews, and architecture reviews. I would not frame this as Claude Code versus Codex. I would use both where they are strongest. | Tool | Best use | Security posture | |---|---|---| | Claude Code | Deep reasoning, architecture review, long-form security analysis, runbook drafting | Strong project rules and tool approval | | Codex | Code changes, CLI-driven development workflow, reproducible implementation tasks | Sandbox, approval policy, repo controls | | AWS MCP Server | AWS documentation and authenticated AWS API access | IAM-enforced read-only first | | CI/CD | Tests, scanning, deployment, policy gates | Release authority remains outside the AI tool | For security work, the safest split is: Claude Code: analyze and explain Codex: implement controlled code changes AWS MCP Server: retrieve AWS context CI/CD: validate and release Human owner: approve risk and remediation The AI tool can accelerate the workflow, but it should not become the approval authority. Use this workflow for daily or weekly triage. Confirm: sec-mcp-readonly . ./output . aws sts get-caller-identity . prompts/securityhub-triage.md .Security Hub: php AWS Console - Security Hub - Findings GuardDuty: php AWS Console - GuardDuty - Findings Inspector: php AWS Console - Inspector - Findings CloudTrail: php AWS Console - CloudTrail - Event history Config: php AWS Console - AWS Config - Resources / Advanced queries S3 public access: php AWS Console - S3 - Bucket - Permissions - Block Public Access / Bucket policy Manual validation matters because MCP output is an aid, not evidence by itself. Fix in this order: The top of the list is about blast radius and business impact, not just severity labels. Even with read-only IAM and MCP controls, some risk remains. Residual risks include: Acceptable residual risk for a pilot: Read-only triage and evidence drafting with human review. Not acceptable for a pilot: Automated suppression, remediation, policy changes, deployments, or risk acceptance. Decision: Approved with conditions. We can pilot AWS MCP Server through AWS Agent Toolkit for a read-only Security Hub triage workflow. Approved scope: - Read Security Hub findings. - Read limited investigation context from GuardDuty, Inspector, Config, CloudTrail, Organizations, and Access Analyzer. - Generate local markdown/CSV/JSON summaries. - Draft remediation tickets and Slack summaries. Not approved: - Security Hub suppression or updates. - AWS resource changes. - IAM changes. - Secret or PII access. - Automated remediation. - AI-approved exception, merge, deploy, or risk acceptance. Required controls: - Named SSO identity. - Dedicated SecMCPReadOnly permission set. - Explicit deny for write actions. - SCP or permission boundary for production where possible. - MCP tool approval enabled. - Script execution denied or separately approved. - CloudTrail audit visibility. - Negative-control test proving write actions fail. Residual risk is acceptable for a read-only pilot with human review. Start with a narrow, governed workflow: Use case: Security Hub triage Agent: Claude Code or Codex Connector: AWS Agent Toolkit / AWS MCP Server AWS identity: SecMCPReadOnly Permissions: read-only + explicit deny Output: executive summary, technical findings, remediation backlog, evidence index Approval: human review before tickets, suppression, remediation, or risk acceptance Do not build a custom MCP server first. Do not give the agent production write access. Do not let the agent suppress findings or approve exceptions. Get the read-only triage workflow working, prove the controls, collect evidence, and then decide whether more advanced workflows are justified. That is the safe path from AI-assisted security work to production-grade security operations.