# Bedrock Agent Attack Surface Guide

Use this reference for Amazon Bedrock agents, AgentCore, Guardrails, Knowledge Bases, action groups, memory, tool/MCP integrations, prompt-injection defenses, PII handling, encryption, logging, and least-privilege review.

## What people get wrong

The lazy story is:

> Guardrails plus IAM makes a Bedrock agent safe.

Wrong. Agent risk comes from composition: prompt instructions, retrieved data, memory, tool schemas, action-group permissions, logging, and downstream APIs interact in ways a single control cannot prove safe.

Common bad assumptions:

- Guardrails are an authorization boundary.
- Knowledge Base retrieval is safe if the S3/OpenSearch source is trusted.
- Action groups are safe because Lambda has IAM.
- Memory improves UX without creating poisoning or retention risk.
- Tool descriptions cannot leak sensitive implementation details.
- Model access availability proves agent production readiness.

## Bedrock-agent failure modes

- Prompt injection causes tool calls, data exfiltration, or policy bypass through retrieved context.
- Knowledge Base metadata filters do not enforce user-level authorization.
- Action group Lambda role can mutate or read resources beyond the agent use case.
- Guardrails block output but not downstream side effects already triggered by tools.
- Logs/traces capture prompts, PII, retrieved documents, credentials, or tool payloads.
- Memory or session state stores sensitive data without retention, deletion, or tenant boundary controls.

## Minimum safe workflow

1. Identify agent, model, Region, users, data classification, tools/action groups, knowledge sources, memory, and output channels.
2. Map trust boundaries: user prompt, system prompt, retrieved context, tool schema, Lambda/action group, downstream API, and logs.
3. Review Guardrails as defense-in-depth, not authorization; check denied topics, sensitive information filters, contextual grounding, and intervention telemetry.
4. Verify least privilege for action groups, service roles, knowledge base data sources, KMS keys, and logging destinations.
5. Define adversarial evals: prompt injection, data leakage, unauthorized retrieval, unsafe tool call, refusal, and jailbreak cases.
6. Require observability with redaction: guardrail interventions, tool calls, model errors, token/cost, latency, and audit events.
7. Do not approve production release without eval evidence, rollback/fallback, and owner signoff.

## Verification targets

- Bedrock agent configuration, model, aliases/versions, Guardrails, prompts, orchestration, and action group schemas
- Knowledge Base data source, sync status, metadata filters, vector store access, S3/KMS policies, and tenant/data boundaries
- action group Lambda/API permissions, IAM trust, resource policies, network access, and side-effect controls
- AgentCore runtime/gateway/memory/tool integration boundaries where applicable
- CloudWatch/CloudTrail logs, GenAI observability, prompt/tool redaction, retention, and alerting
- eval suite for injection, leakage, unsafe tool invocation, grounding, PII handling, and cost/latency thresholds

## When to push back

Push back if the user asks to:

- treat Guardrails as a complete security boundary
- allow agent tools to mutate production without approval gates
- use broad Bedrock, Lambda, S3, or KMS permissions
- skip adversarial prompt and retrieval evals
- log raw prompts, retrieved documents, or tool payloads broadly
- claim agent safety from documentation or service availability alone

# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/bedrock/latest/userguide/security-best-practice-agents.html
- https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-injection.html
- https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html
- https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-how.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, or operational state. Prefer AWS managed MCP read-only evidence through the user's configured read-only AWS profile, read-only AWS CLI evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- Bedrock prompt-injection guidance says Guardrails can detect prompt attacks, but customers still need application controls such as input validation, guardrail association, and safer prompt design.
- Bedrock CloudTrail guidance covers Bedrock API activity; logging proves calls occurred, not whether an agent decision was safe.

Sampled live evidence:
- Read-only regional availability sampling reported `isAvailableIn` for Amazon Bedrock in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.

Review implications:
- Guardrails and prompt-injection controls reduce risk; they do not prove a specific agent, action group, knowledge base, or tool integration is safe.
- Require evidence for IAM scope, data-source boundaries, logging, model/tool invocation paths, memory retention, PII handling, and kill-switch behavior before production readiness claims.

# Safety checklist

Use this reference before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.

## Non-negotiables

- Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
- Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
- Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting actions.
- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
- Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.

## Stress checks

- What can expose data?
- What can escalate privilege?
- What can break production or block rollback?
- What can create unbounded cost?
- What compliance or audit evidence is missing?
- What rollback or validation path is unproven?

## Evidence labels

Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live AWS state.

# Workflow and output contract

Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.

## Review domains

Check these areas before giving a verdict:
- Agent architecture: model, prompts, orchestration, action groups, Lambda/tools, knowledge bases, memory, guardrails, and data stores
- Threat model: prompt injection, prompt leakage, tool abuse, data exfiltration, memory poisoning, unsafe retrieval, and overbroad IAM
- Guardrail coverage: what input/output sections are evaluated, policy types, blocked messages, tests, and cost/latency impact
- Security evidence: IAM, KMS, logging, CloudTrail, application telemetry, PII handling, evals, and rollback/disable path

## Safe workflow

1. **Frame scope**
   - Workload/account/Region/environment:
   - Business criticality and owner:
   - Data classification and compliance driver:
   - Required outcome:
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
   - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - What can expose data?
   - What can escalate privilege?
   - What can break production or block rollback?
   - What can create unbounded cost?
   - What evidence is missing?
4. **Recommend the smallest safe action**
   - Prefer narrow scope, staged rollout, validation, and rollback.
   - If the safest action is to stop and gather evidence, say that plainly.

## Output contract

Return this structure:
```markdown
# AWS Bedrock Agent Security Governor: <scope>
## Executive verdict
- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```