Eight Attack Vectors Found in AWS Bedrock — AI Infrastructure Is the New Frontline

XM Cyber researchers have mapped eight validated attack paths inside AWS Bedrock that let adversaries hijack AI agents, poison prompts, steal knowledge bases, and degrade safety guardrails — all without touching the model itself.

🔍 Why This Matters

AWS Bedrock is Amazon's flagship platform for building AI-powered applications. It connects foundation models directly to enterprise data — Salesforce instances, SharePoint libraries, Lambda functions, S3 buckets. That connectivity is what makes it powerful, and what makes it a target.

When an AI agent can query your CRM, trigger serverless functions, or pull from a knowledge base, it becomes a node in your infrastructure with permissions, reachability, and paths to critical assets. XM Cyber's threat research team has now proven that a single over-privileged identity is enough to compromise the entire AI stack.

⚡ The Eight Attack Vectors

1. Model Invocation Log Attacks

Bedrock logs every model interaction for compliance. Attackers can redirect logs to attacker-controlled S3 buckets using bedrock:PutModelInvocationLoggingConfiguration, silently capturing every prompt. A second variant uses s3:DeleteObject to scrub evidence of jailbreaking activity.

2. Knowledge Base Data Source Attacks

RAG-connected data sources (S3, Salesforce, SharePoint, Confluence) are directly reachable. An attacker with s3:GetObject access can bypass the model entirely and pull raw enterprise data. Worse: stolen credentials can enable lateral movement into Active Directory.

3. Knowledge Base Data Store Attacks

Vector databases like Pinecone and Redis Enterprise Cloud store indexed knowledge. Exposed credentials in StorageConfiguration give attackers full administrative access to vector indices and all structured data in Aurora or Redshift.

4. Direct Agent Attacks

With bedrock:UpdateAgent permissions, attackers can rewrite an agent's base prompt to leak internal instructions and tool schemas. Combined with bedrock:CreateAgentActionGroup, they attach malicious executors to legitimate agents — enabling unauthorized database modifications under cover of normal AI workflows.

5. Indirect Agent Attacks

Instead of targeting the agent config, attackers target supporting Lambda functions. Using lambda:UpdateFunctionCode or lambda:PublishLayer, they inject malicious code into the tool calls agents rely on — exfiltrating data or manipulating responses invisibly.

6. Flow Injection Attacks

Bedrock Flows define multi-step AI workflows. Attackers with bedrock:UpdateFlow can inject sidecar S3 or Lambda nodes, routing sensitive inputs to attacker endpoints without breaking application logic. They can also modify condition nodes to bypass authorization checks.

7. Guardrail Degradation

Guardrails filter toxic content, block prompt injection, and redact PII. An attacker with bedrock:UpdateGuardrail can systematically lower thresholds, making models vulnerable to manipulation. With bedrock:DeleteGuardrail, defenses vanish entirely.

8. Managed Prompt Poisoning

Bedrock Prompt Management centralizes templates across applications. Attackers with bedrock:UpdatePrompt can modify templates in-flight — injecting instructions like "ignore safety rules" or "include attacker backlinks." Changes don't trigger redeployment, making detection extremely difficult.

🎯 Key Insight: The Model Is Not the Target

All eight vectors share a common pattern: attackers target the permissions, configurations, and integrations surrounding the model — not the model itself. Traditional AI security focused on prompt injection and jailbreaking misses the real attack surface: IAM policies, data source configurations, and the infrastructure connecting AI to enterprise systems.

🛡️ Immediate Actions for Security Teams

1. Audit Bedrock IAM policies — Apply least-privilege to all bedrock:*, lambda:*, and s3:* permissions tied to AI workloads
2. Monitor log configuration changes — Alert on any PutModelInvocationLoggingConfiguration calls
3. Encrypt and rotate credentials — All data source and data store credentials should use AWS Secrets Manager with automatic rotation
4. Lock down agent configurations — Restrict UpdateAgent and CreateAgentActionGroup to CI/CD pipelines only
5. Version-control prompts — Treat managed prompts like code: require review, approval, and audit trails for changes
6. Map your AI attack surface — Use exposure management to identify all paths from AI workloads to critical assets
7. Test guardrail resilience — Regularly verify that guardrails cannot be weakened through configuration changes

📊 NIS2 and DORA Implications

For EU organizations, these findings have direct regulatory impact. NIS2 requires supply chain risk management and incident reporting for significant events. AI infrastructure compromise — especially through third-party cloud services — falls squarely within scope. DORA's ICT risk management framework demands that financial entities map and test all digital operational dependencies, including AI-powered automation.

Organizations using AWS Bedrock in production should document these attack vectors in their risk assessments and validate controls as part of their NIS2 compliance program.