Amazon Bedrock Penetration Testing

IAM decides what an agent’s execution role, its action-group Lambda functions and its knowledge base connection can each reach, and every one of those roles is something your team configures, not something Bedrock decides for you.

Why Bedrock security depends on the roles and rules your team configures

An Amazon Bedrock agent decides which action group to invoke and what parameters to send it, and Amazon Bedrock’s own documentation is explicit that the agent passes the API or function it predicts, together with the parameters it derives from the session, straight to your Lambda function. That same guidance tells you to attach a resource-based policy to the Lambda function so the Bedrock service principal can invoke it, but nothing in that pattern limits what the function does once it is called. The agent’s own execution role is a service role scoped by a trust policy tied to your account and, ideally, a specific agent ARN, with identity-based permissions covering the base model, the S3 objects holding your action group schemas, and any knowledge base or guardrail the agent uses.

Knowledge base retrieval is authorised separately, through the bedrock:Retrieve and bedrock:RetrieveAndGenerate actions scoped to a specific knowledge base by its ARN, and AWS’s documentation on querying a knowledge base describes metadata filtering as a way to improve the relevance of a response. Whether a metadata filter is actually built to stop one customer’s query pulling back another customer’s documents is a decision your application makes; Bedrock does not enforce that separation for you automatically. The same ingestion path carries indirect prompt injection: a document, ticket or web page pulled into a knowledge base can carry instructions the model treats as trusted context once retrieved, which OWASP’s Top 10 for LLM Applications catalogues under LLM01: Prompt Injection alongside the direct kind, where a user simply types the attack at the agent.

Guardrails evaluates the prompt going in and the completion coming out against the content filters, denied topics, word filters, sensitive information filters, contextual grounding checks and Automated Reasoning checks you configure, but that evaluation stops at the model call. It does not extend to what an action group’s Lambda function does with the parameters it receives. Model invocation logging, which can record the full request and response for calls made through the Converse and InvokeModel APIs, is disabled by default, so unless your team has switched it on there is no CloudWatch or S3 record of what a model was asked or what it returned. We check what your guardrail configuration actually blocks against what you believe it blocks, and whether logging would give you anything useful during an incident.