Mike Anderson

Posted on Jul 16

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

#aws #cybersecurity #mcp #devsecops

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

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:

Read-only first.
No production write authority.
No access to secrets.
No raw customer PII or sensitive incident logs in prompt context.
No automatic remediation.
No AI-approved suppression, exception, merge, deploy, or risk acceptance.
Human review and CI/CD remain the release authority.

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.

What we are building

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:

Read AWS Security Hub findings.
Group findings by account, severity, product, resource, and control.
Explain why a finding matters.
Draft remediation tickets.
Draft a Slack-ready summary.
Produce local markdown, CSV, and JSON evidence files.

The agent will not be able to:

Suppress findings.
Archive findings.
Mark findings resolved.
Disable Security Hub standards.
Modify IAM, S3, EC2, KMS, GuardDuty, Inspector, or Config.
Deploy remediation.
Run destructive scripts.
Approve risk acceptance.

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.

What is MCP?

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.

What an MCP server actually does

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:

Query Security Hub findings.
Search AWS documentation.
Call AWS APIs.
Read repository files.
Read Jira tickets.
Read internal runbooks.
Generate remediation plans.
In poorly controlled environments, call write APIs.

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:

IAM.
SCPs.
Permission boundaries.
SSO permission sets.
MCP tool allowlists.
Claude Code or Codex approval modes.
Audit logs.
Human approval.

Where MCP fits in the agent architecture

A useful operating model is:

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.

Why MCP is useful for cybersecurity work

Security work is context-heavy.

A security engineer rarely needs a generic answer. We need the assistant to understand:

Which AWS account is affected.
Which Security Hub control failed.
Whether the finding is active, archived, suppressed, or resolved.
Whether the source is Security Hub CSPM, GuardDuty, Inspector, Macie, Config, or another product.
Whether the affected resource is public-facing.
Whether the account is production, shared services, security tooling, or sandbox.
What remediation is appropriate.
What evidence should be retained.
What should be fixed immediately versus tracked in backlog.

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:

Security Hub triage.
GuardDuty finding explanation.
Inspector vulnerability prioritization.
CloudTrail event review.
IAM access review support.
AWS documentation lookup.
Control evidence preparation.
Remediation backlog drafting.
Incident timeline drafting.
Cloud security review preparation.

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.

Should security teams build their own MCP server?

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:

AWS Agent Toolkit for AWS.
AWS MCP Server.
A dedicated read-only AWS profile or IAM Identity Center permission set.
Claude Code or Codex MCP configuration.
A controlled Security Hub triage workflow.

Decision table

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

Trusted source order

Use this priority order for MCP servers:

Official vendor documentation.
Official AWS Agent Toolkit / AWS MCP Server.
Official MCP Registry where appropriate.
Vendor-maintained GitHub repositories.
Your internal private registry for internal 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:

A credential theft path.
A data exfiltration path.
A prompt-injection bridge.
A hidden write-action path.
A supply chain risk.

Treat MCP servers like production integrations.

AWS Agent Toolkit: what it gives you

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.

Target architecture

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.

Step 1: Create the AWS read-only identity

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:

An administrator role.
A shared access key.
A personal long-lived IAM user.
A generic service account that hides the human operator.

Use a named human identity with SSO. The goal is that every MCP-driven AWS API call is attributable to a real engineer.

Step 2: Attach a scoped read-only IAM policy

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.

IAM policy: Security Hub MCP read-only

{
  "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": "*"
    }
  ]
}

Why include the explicit deny?

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.

Step 3: Add an optional SCP for production accounts

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.

Step 4: Configure AWS CLI and SSO profile

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.

Step 5: Install AWS Agent Toolkit for Claude Code

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.

Step 6: Install AWS Agent Toolkit for Codex

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.

Step 7: Direct MCP configuration if plugin install is not available

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.

Step 8: Configure tool approval and safety settings

The security posture should be tool-specific.

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

Step 9: Create the local project folder

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.

Step 10: Create the Security Hub filter

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.

Step 11: Create the agent prompt

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:

It defines the job.
It defines the boundaries.
It defines the output format.

That is what makes the workflow repeatable.

Step 12: Run the workflow in Claude Code

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:

AWS profile is sec-mcp-readonly.
Region is expected.
API action is read-only.
No script execution is being requested unless explicitly approved.
No write, update, delete, suppress, or remediation action is requested.

If the agent asks to use a write action, stop the run and fix the permissions or project rules.

Step 13: Run the workflow in Codex

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:

Confirm profile.
Confirm region.
Confirm read-only API action.
Confirm output path.
Deny script execution unless this has already been approved for the pilot.

Expected outputs

The workflow should produce four local files.

1. `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...

2. `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.

3. `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

4. `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

How to prioritize findings

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:

Production versus non-production.
Public exposure.
Data sensitivity.
Exploitability.
Privilege impact.
Lateral movement potential.
Compensating controls.
Asset owner.
Existing exception status.

That is where the agent can help, but the human still owns the decision.

Evidence required for audit

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:

Raw customer data.
Secrets.
Access keys.
Sensitive logs copied unnecessarily.
Full data object contents.
Anything that creates a new evidence-handling problem.

Negative control test: prove write actions fail

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 modes and required controls

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

Where AWS AgentCore Gateway fits

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:

Central tool registration.
Central authentication.
Fine-grained access control.
Tool observability.
Network control.
Credential management.
Private connectivity.
SCP enforcement.
Standardized approval patterns.

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.

Practical AWS security use cases for MCP agents

Security Hub triage

Best first use case.

Input:

Security Hub findings.
Account context.
Severity.
Resource metadata.
AWS documentation.

Output:

Executive summary.
Technical findings.
Remediation backlog.
Evidence index.

Risk: low if read-only.

GuardDuty investigation support

The agent can help explain:

Finding type.
Likely attack path.
Affected principal.
Source IP.
First and last seen timestamps.
Recommended containment steps.

Do not let the agent disable keys, quarantine instances, or modify policies automatically.

Inspector vulnerability prioritization

The agent can group Inspector findings by:

Public exposure.
Exploit availability.
Package.
Workload owner.
Production impact.
Patch SLA.

The output can be a CSV remediation backlog.

Do not let the agent patch systems automatically.

IAM access review assistant

The agent can summarize:

Unused access.
High-risk permissions.
External trust relationships.
Access Analyzer findings.
Privileged roles.
Service accounts with broad permissions.

Do not let the agent change IAM policy.

Cloud security review evidence pack

The agent can collect read-only evidence for:

CloudTrail.
Config.
GuardDuty.
Security Hub.
Inspector.
S3 Block Public Access.
Encryption configuration.
Account inventory.

This is useful before audits, risk reviews, and architecture reviews.

Claude Code vs Codex: how I would use both

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.

Junior engineer runbook

Use this workflow for daily or weekly triage.

Before starting

Confirm:

You are using sec-mcp-readonly.
MFA is active.
You are in the correct AWS account and region.
The MCP server is the approved AWS MCP Server.
Output will be written only to ./output.
No customer PII, secrets, or raw sensitive logs will be collected.
Tool approvals are enabled.
Write actions are denied.

Daily triage workflow

Run aws sts get-caller-identity.
Run a small Security Hub read test.
Start Claude Code or Codex in the project folder.
Load prompts/securityhub-triage.md.
Approve only read-only AWS API calls.
Review generated output files.
Validate immediate-risk findings manually in the AWS Console.
Create Jira tickets for owners.
Escalate possible data exposure to SOC or the incident commander.
Store the evidence index with the ticket.

AWS Console paths for manual validation

Security Hub:

AWS Console -> Security Hub -> Findings

GuardDuty:

AWS Console -> GuardDuty -> Findings

Inspector:

AWS Console -> Inspector -> Findings

CloudTrail:

AWS Console -> CloudTrail -> Event history

Config:

AWS Console -> AWS Config -> Resources / Advanced queries

S3 public access:

AWS Console -> S3 -> Bucket -> Permissions -> Block Public Access / Bucket policy

Manual validation matters because MCP output is an aid, not evidence by itself.

What to fix first

Fix in this order:

Public exposure of production resources.
Possible sensitive data exposure.
Privileged IAM misconfiguration.
Active GuardDuty findings.
Critical exploitable vulnerabilities on internet-facing workloads.
Disabled or missing logging in production.
Missing encryption on sensitive stores.
Repeated control failures with no owner.
Non-production hygiene issues.
Informational findings and duplicates.

The top of the list is about blast radius and business impact, not just severity labels.

Residual risk

Even with read-only IAM and MCP controls, some risk remains.

Residual risks include:

The agent may misinterpret a finding.
The agent may over-prioritize or under-prioritize business impact.
Prompt injection may appear in finding text, ticket text, or documentation.
Local output files may contain sensitive metadata.
Engineers may approve unsafe tool calls.
AWS permissions may drift over time.
MCP server behavior and client capabilities may change with version updates.

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.

Final Slack-ready wording

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.

Final recommendation

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.

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

What we are building

What is MCP?

What an MCP server actually does

Where MCP fits in the agent architecture

Why MCP is useful for cybersecurity work

Should security teams build their own MCP server?

Decision table

Trusted source order

AWS Agent Toolkit: what it gives you

Target architecture

Step 1: Create the AWS read-only identity

Step 2: Attach a scoped read-only IAM policy

IAM policy: Security Hub MCP read-only

Why include the explicit deny?

Step 3: Add an optional SCP for production accounts

Step 4: Configure AWS CLI and SSO profile

Step 5: Install AWS Agent Toolkit for Claude Code

Step 6: Install AWS Agent Toolkit for Codex

Step 7: Direct MCP configuration if plugin install is not available

Step 8: Configure tool approval and safety settings

Step 9: Create the local project folder

Step 10: Create the Security Hub filter

Step 11: Create the agent prompt

Step 12: Run the workflow in Claude Code

Step 13: Run the workflow in Codex

Expected outputs

1. output/securityhub-executive-summary.md

2. output/securityhub-technical-findings.md

3. output/securityhub-remediation-backlog.csv

4. output/securityhub-evidence-index.md

How to prioritize findings

Evidence required for audit

Negative control test: prove write actions fail

Failure modes and required controls

Where AWS AgentCore Gateway fits

Practical AWS security use cases for MCP agents

Security Hub triage

GuardDuty investigation support

Inspector vulnerability prioritization

IAM access review assistant

Cloud security review evidence pack

Claude Code vs Codex: how I would use both

Junior engineer runbook

Before starting

Daily triage workflow

AWS Console paths for manual validation

What to fix first

Residual risk

Final Slack-ready wording

Final recommendation

1. `output/securityhub-executive-summary.md`

2. `output/securityhub-technical-findings.md`

3. `output/securityhub-remediation-backlog.csv`

4. `output/securityhub-evidence-index.md`