Any AWS principal that can call bedrock:InvokeModel can spend money, read whatever an agent or knowledge base can reach, and, by default, leave no record of what it asked. Amazon Bedrock is governed by ordinary IAM, but it adds its own moving parts: service roles that agents and knowledge bases assume, a bearer-token API key type, guardrails that only apply when a request names them, and model access that switches itself on at first use. This guide explains how identity and access work across Bedrock models, Agents, AgentCore and Knowledge Bases, which settings to change first, and what to log and alert on. It is for cloud security engineers and AI platform owners. General AWS account controls are covered in the AWS Security Guide and policy mechanics in the AWS IAM Policies and Roles Guide; this page stays on what is specific to Bedrock.
Key takeaways
- Model access is not an entitlement gate any more. Most serverless models enable on first invocation, so the only reliable control is an explicit deny on bedrock:InvokeModel (SCP or IAM) for models you have not approved.
- Agents and knowledge bases act through their own roles. Their service roles decide what data and tools a prompt can reach, so scope them to specific resources and protect the trust policy with aws:SourceAccount and aws:SourceArn.
- Guardrails are opt-in per request. Use the bedrock:GuardrailIdentifier condition key, or account and organisation enforced guardrails, to make them mandatory rather than advisory.
- Prompt logging is off by default. Turn on model invocation logging and the CloudTrail data events for agents, knowledge bases and guardrails, and alert when anyone reads or changes the logging configuration.
- Bedrock API keys are credentials, not configuration. Block long-term keys with bedrock:bearerTokenType, cap their age, and prefer roles and short-term keys in production.
How identity and access work in Amazon Bedrock
Actions use the bedrock: prefix (and bedrock-mantle: for the Mantle endpoint), resources are ARNs such as arn:aws:bedrock:region::foundation-model/model-id, ...:agent/AGENT-ID and ...:knowledge-base/KB-ID, and ABAC works through aws:ResourceTag, aws:RequestTag and aws:TagKeys. Bedrock supports resource-based policies only for guardrails and guardrail inference profiles, and it uses service roles but no service-linked roles. Some actions touch several resources at once: AssociateAgentKnowledgeBase needs permission on both the agent and the knowledge base.
| Identity | What it is in Bedrock | Main risk | Primary control |
|---|---|---|---|
| Human users and admins | Federated roles calling the console, bedrock and bedrock-agent APIs | Broad bedrock:* grants that include model enablement, logging changes and agent edits | Separate builder, operator and logging-admin roles; deny logging changes outside the security role |
| Application roles | Lambda, ECS, EKS or EC2 roles calling bedrock-runtime | Invoke on foundation-model/*, any Region | Allow only approved model ARNs and inference profiles; require a guardrail |
| Agent service role | Role Bedrock assumes to run an agent | Reaching every bucket, knowledge base and model in the account | Trust policy pinned to agent IDs; resource-scoped InvokeModel, s3:GetObject and Retrieve |
| Knowledge base service role | Role Bedrock assumes to ingest and embed data | Reading more source data than the use case needs | Bucket and prefix scoping with aws:ResourceAccount; KMS kms:ViaService conditions |
| Action group Lambda functions | Tools an agent calls | Function role with write access to production systems | Resource-based policy limited to the agent ARN; least privilege on the function role |
| Bedrock API keys | Bearer tokens, short-term or long-term (an IAM user with a service-specific credential) | Leaked token used from anywhere until expiry | Deny bedrock:CallWithBearerToken or allow only SHORT_TERM |
| AgentCore workload identities | Agent identities in the AgentCore Identity directory | Outbound OAuth tokens and API keys used beyond their purpose | Token vault, scoped credential providers, inbound JWT authorizers |
Model access and entitlements
Bedrock no longer uses a manual model-access request for most serverless models. The first InvokeModel or Converse call to a third-party model starts an AWS Marketplace subscription in the background, which needs aws-marketplace:Subscribe, aws-marketplace:Unsubscribe and aws-marketplace:ViewSubscriptions on the caller, plus a one-time Anthropic use case form (PutUseCaseForModelAccess) for Anthropic models. Four consequences matter for security:
- Deny Subscribe is not enough: AWS documents that denying
aws-marketplace:Subscribedoes not stop the first invocation. Block unapproved models with a deny onbedrock:InvokeModelfor their foundation-model ARNs, ideally as an SCP. See the AWS Organizations and SCPs Guide. - Subscriptions cross Regions: a subscription in one Region makes the model available in every supported Region, so Region-restriction SCPs must cover Bedrock too.
- Agreement deletion is not revocation: deleting an agreement does not block access because the next invocation recreates it. Pair it with a deny.
- The first call accepts the EULA: block first if licence terms need review.
Admin roles and privileged access
In Bedrock the privileged actions are not only IAM changes. A small set of API calls changes what is logged, which models exist in the account, what an agent can do and which data a knowledge base exposes. Treat the principals that hold them as privileged and put them behind just-in-time elevation. See the Cloud PAM and CIEM Guide.
| Privileged action | Why it is sensitive | Who should hold it |
|---|---|---|
PutModelInvocationLoggingConfiguration, DeleteModelInvocationLoggingConfiguration | Turns prompt and response logging off or redirects it | Security logging role only; deny everyone else by SCP |
PutUseCaseForModelAccess, CreateFoundationModelAgreement, aws-marketplace:Subscribe | Enables new models and accepts terms; used in LLMjacking campaigns | Platform team, through change control |
CreateAgent, UpdateAgent, action group and alias changes | Changes tools, instructions and the role an agent uses | Agent builders in non-production; pipeline role in production |
CreateDataSource, UpdateDataSource, StartIngestionJob | These do not pass a role, so anyone who can manage a data source can ingest whatever the knowledge base role can read, then query it | Data owners and the deployment pipeline |
| Guardrail create, update, delete and resource policy changes | Weakens or removes the safety layer for every caller that relies on it | AI governance or security team |
iam:PassRole for Bedrock service roles | Lets a builder attach a more powerful role to an agent or job | Scoped to named Bedrock roles with iam:PassedToService |
iam:CreateServiceSpecificCredential | Creates long-term Bedrock API keys | Nobody in production; cap with iam:ServiceSpecificCredentialAgeDays elsewhere |
Keep the broad managed AmazonBedrockFullAccess policy out of production application and builder roles; write scoped policies following the AWS IAM Policies and Roles Guide.
Integrations, API tokens and service accounts
Bedrock API keys
- Short-term keys: last up to 12 hours (or the session length if shorter) and inherit the permissions of the principal that generated them.
- Long-term keys: create an IAM user with a service-specific credential, work only in the Region where they were generated, and last until a configured expiry. AWS positions them for exploration. Treat them as static secrets. See the LLMjacking Guide.
- Controls: deny
bedrock:CallWithBearerToken(andbedrock-mantle:CallWithBearerToken) where keys are not needed, or allow onlybedrock:bearerTokenType=SHORT_TERM. Long-term keys are deactivated, reset or deleted through the service-specific credential APIs; a short-term key is killed by invalidating its session or denyingCallWithBearerToken. - Logging: calls made with keys appear in CloudTrail, but the key itself is not logged, so attribute activity by principal ARN.
Agent service roles and action groups
- Trust policy: allow
bedrock.amazonaws.comto assume the role only withaws:SourceAccountset to your account andAWS:SourceArnmatching the agent ARN. AWS advises replacing theagent/*wildcard with specific agent IDs once they exist; this is the confused-deputy protection. - Permissions:
bedrock:InvokeModelon the orchestration model (plus inference profile actions if used),s3:GetObjecton the OpenAPI schema object only,bedrock:Retrieveon associated knowledge bases,bedrock:ApplyGuardrailon the guardrail, andbedrock:InvokeAgentonly on named collaborator aliases for multi-agent setups. - Lambda tools: each action group function needs a resource-based policy allowing
lambda:InvokeFunctionfrombedrock.amazonaws.com, scoped by the same source conditions. The function's own execution role is where real-world write access lives, so review it as a non-human identity. See the Serverless Security Guide. - User confirmation: for actions that change state, enable user confirmation on the action. The agent then returns control to the application with the planned call, and the action runs only after a CONFIRM. AWS notes that agents can follow instructions embedded in API or knowledge base responses, which is exactly the excessive agency risk in OWASP LLM06:2025. See the Agentic AI Security Guide.
Knowledge base roles
The knowledge base role needs bedrock:InvokeModel on the embedding model, s3:ListBucket and s3:GetObject on the source (conditioned on aws:ResourceAccount), aoss:APIAccessAll on the OpenSearch Serverless collection, and secretsmanager:GetSecretValue only for third-party vector stores. Scope S3 to the exact prefixes, because everything the role can read becomes retrievable by anyone with bedrock:Retrieve on that knowledge base. IAM grants Retrieve per knowledge base, not per document: separate data with different classification levels into separate knowledge bases, and control Retrieve and RetrieveAndGenerate per caller.
AgentCore Identity
AgentCore hosts agents and tools through services including Runtime, Gateway (APIs and Lambda functions exposed as MCP-compatible tools), Memory and Policy. AgentCore Identity gives each agent a workload identity in a directory (ARN form arn:aws:bedrock-agentcore:region:account:workload-identity/directory/default/workload-identity/agent-name), supports inbound JWT authorizers, and keeps outbound OAuth 2.0 tokens, client credentials and API keys in a token vault encrypted with AWS KMS. Credential providers support machine-to-machine (2LO, client credentials) and user-delegated (3LO, authorization code) flows. Prefer 3LO where the agent acts for a user, scope 2LO credentials per tool, and review Gateway targets as tool permissions. See the MCP Security Guide and the Agentic AI Identity Guide.
Choosing a credential pattern
| Caller | Use | Avoid |
|---|---|---|
| Workload in AWS (Lambda, ECS, EKS, EC2) | Its IAM role with SigV4 | Any API key |
| Workload outside AWS | IAM Roles Anywhere or OIDC federation to a role. See the Cloud Workload Identity Guide | IAM user access keys, long-term Bedrock keys |
| Tool that only accepts a bearer token | Short-term Bedrock API key refreshed by the token generator | Long-term key in an environment file |
| Developer experimentation in a sandbox account | Long-term key with a short age limit, sandbox SCP and budget | Keys created in production accounts |
| Agent calling third-party SaaS | AgentCore Identity credential provider with 3LO where a user is present | Shared admin API key embedded in agent code |
For small teams with one or two Bedrock applications, application roles, a mandatory guardrail and invocation logging cover most of the risk. Large organisations with many accounts should add the SCP model allow-list, organisation-level guardrail enforcement and central log aggregation, and run agents through a pipeline role rather than console edits.
Logging and detection
Two logs are needed and they record different things. CloudTrail records who called which API; model invocation logging records the prompts and responses.
| Source | What it records | Default | Setting |
|---|---|---|---|
| CloudTrail management events | InvokeModel, InvokeModelWithResponseStream, Converse, ConverseStream and all control plane calls such as CreateAgent | On in trails | Organisation trail; filter on eventType = AwsApiCall when counting streamed calls |
| CloudTrail data events | InvokeAgent (AWS::Bedrock::AgentAlias), InvokeInlineAgent, Retrieve and RetrieveAndGenerate (AWS::Bedrock::KnowledgeBase), InvokeFlow, ApplyGuardrail (AWS::Bedrock::Guardrail), async invokes | Off | Advanced event selectors per resource type; extra cost |
| Model invocation logging | Request and response bodies, modelId, identity.arn, requestMetadata, input and output token counts for text, image, embedding and video | Off | S3 and/or CloudWatch Logs in the same account and Region; bodies over 100 KB go to S3 |
Two gaps to plan for: invocation logging captures calls through the bedrock-runtime endpoint only and does not currently capture bedrock-mantle,, and the logs contain the prompts themselves: encrypt the destination with a customer managed KMS key and restrict reads to an investigations role.
Detections worth building
- Logging tampering: any
GetModelInvocationLoggingConfiguration,PutModelInvocationLoggingConfigurationorDeleteModelInvocationLoggingConfigurationoutside the security role. Attackers in the LLMjacking campaigns queried the logging configuration before using stolen keys. This maps to ATT&CK T1685 Disable or Modify Tools. - First-time model enablement:
PutUseCaseForModelAccess,CreateFoundationModelAgreementor a newmodelIdfor a principal, which researchers saw attackers call before invoking models. - Invocation anomalies: token volume per principal well above baseline, invocations from new Regions or source IPs and principals with no Bedrock history (ATT&CK T1496.004 Cloud Service Hijacking, ATLAS AML.T0034 Cost Harvesting).
- Agent and data changes:
UpdateAgent, new data sources and ingestion jobs outside the pipeline role. - Guardrail hits: spikes in prompt attack or sensitive information interventions per application, which signal probing (ATLAS AML.T0051 LLM Prompt Injection).
- Key creation:
CreateServiceSpecificCredentialfor Bedrock in any production account.
Metrics
- Percentage of accounts using Bedrock with invocation logging enabled (target 100).
- Percentage of production inference roles that carry a
bedrock:GuardrailIdentifiercondition or are covered by an enforced guardrail. - Number of active long-term Bedrock API keys, and maximum key age.
- Agent and knowledge base service roles with wildcard trust or wildcard S3 resources (target 0).
- Bedrock spend per principal against budget, and time from anomaly alert to key or session revocation.
Hardening baseline
| Area | Baseline setting |
|---|---|
| Model allow-list | SCP denying bedrock:InvokeModel (which also governs Converse) except approved foundation-model and inference profile ARNs, and Regions |
| Guardrails | Content filters including Prompt Attack, denied topics, sensitive information filters (block or mask PII, custom regex), contextual grounding checks for RAG; versioned, not DRAFT, in production |
| Guardrail enforcement | Allow plus explicit Deny on bedrock:GuardrailIdentifier for direct inference roles; account or organisation enforced guardrails, which need a guardrail resource-based policy |
| Network | Interface endpoints for bedrock-runtime, bedrock-agent-runtime and others used, with an endpoint policy narrower than the default full access; aws:SourceVpce conditions on application roles; VPC config for customisation and batch jobs |
| Encryption | Customer managed keys for agents (customerEncryptionKeyArn), custom models (customModelKmsKeyId), knowledge base ingestion (kmsKeyArn), vector stores, evaluation jobs and log destinations |
| API keys | Deny CallWithBearerToken or allow SHORT_TERM only; cap long-term key age |
| Service roles | One role per agent or knowledge base, source conditions pinned to the resource ID, no shared policies |
| Agents | Guardrail associated, user confirmation on state-changing actions, clear system prompt stating scope, pre-processing prompt where suitable |
Two documented caveats: guardrail input tags let a caller exclude parts of the prompt from evaluation (the response is still checked), and a role restricted with bedrock:GuardrailIdentifier will get access denied on InvokeAgent and RetrieveAndGenerate, because those make internal model calls without the guardrail; give agent and RAG callers separate roles and associate the guardrail with the agent instead. See the AI Guardrails and AI Firewalls Guide and the Prompt Injection Guide.
Rolling it out
- Inventory: list accounts and Regions with Bedrock CloudTrail activity, the models invoked, the principals calling them, every agent, knowledge base and guardrail, and any service-specific credentials.
- Turn on visibility first: enable invocation logging and data event selectors, and deploy the logging-tamper and model-enablement alerts.
- Audit before you deny: run the model allow-list and API key SCPs against two weeks of CloudTrail to find callers that would break; use IAM Access Analyzer policy generation to draft least-privilege application policies.
- Pilot: apply SCPs to a sandbox OU, then one production OU; apply guardrail enforcement to one application role.
- Tighten service roles: replace wildcard source ARNs with agent and knowledge base IDs, and split shared roles.
- Roll back: keep each SCP as a separate policy so it can be detached quickly, and revert guardrails to the previous version.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | Threat reference |
|---|---|---|---|
| Model and role least privilege | AC-6, AC-3 | PR.AA-05 | OWASP LLM06:2025 Excessive Agency |
| API keys and service credentials | IA-5, AC-2 | PR.AA-01 | ATT&CK T1552.001, T1078.004 |
| Invocation logging and CloudTrail | AU-2, AU-12 | PR.PS-04, DE.CM-09 | ATT&CK T1685 |
| Spend and abuse monitoring | AU-12 | DE.CM-09 | ATT&CK T1496.004; ATLAS AML.T0034; OWASP LLM10:2025 |
| Guardrails and input handling | AC-3 | PR.AA-05 | ATLAS AML.T0051; OWASP LLM01:2025 |
| Private endpoints | SC-7 | PR.IR-01 | ATLAS AML.T0040 |
| Encryption of agents, models, logs | SC-12, SC-28 | PR.AA-01 | OWASP LLM02:2025 |
Common misconfigurations
- Relying on denied Marketplace subscriptions: teams deny
aws-marketplace:Subscribeand assume models are blocked, but first-use invocation still enables them. Deny the invoke. - Logging never enabled: invocation logging is off by default, so incident responders have token bills but no prompts. In the LLMjacking campaigns stolen AWS credentials were used to run Bedrock models at the victim's expense, and attackers checked logging before starting.
- Wildcard service role trust: trust policies left at
agent/*orknowledge-base/*, or one role shared by every agent, so any new agent inherits all data access. - Static keys for convenience: long-term Bedrock keys or IAM user access keys in notebooks and environment files. Leaked AWS keys are tested within minutes; the AWS crypto-mining campaign shows how fast stolen IAM credentials are used.
- Guardrail named in code, not in policy: a developer removes the guardrail parameter and nothing fails. Enforce with the condition key or enforced guardrails.
- One knowledge base for all documents: HR, finance and public content ingested together, so every caller of
Retrievecan reach all of it, and data source managers can add any bucket the role can read.
Practitioner checklist
- Enable model invocation logging and CloudTrail data events for agent aliases, knowledge bases and guardrails in every Bedrock account and Region.
- Alert on any read or change of the invocation logging configuration and on model enablement calls.
- Deploy an SCP allow-list for approved model ARNs and Regions; do not rely on Marketplace denies.
- Block or restrict Bedrock API keys with bedrock:CallWithBearerToken and bedrock:bearerTokenType, and cap long-term key age.
- Pin every agent and knowledge base service role trust policy to the specific resource ID with aws:SourceAccount and aws:SourceArn.
- Scope knowledge base roles to exact S3 prefixes and split knowledge bases by data classification.
- Make guardrails mandatory through bedrock:GuardrailIdentifier or enforced guardrails, using versioned guardrails in production.
- Enable user confirmation on agent actions that change data or send messages.
- Use interface endpoints with restrictive endpoint policies, customer managed KMS keys, and Bedrock spend alarms per account.
Standards and references
- AWS: How Amazon Bedrock works with IAM
- AWS: Monitor model invocation using CloudWatch Logs and Amazon S3
- AWS: Enforce the use of a specific guardrail in model inference requests
- AWS: Amazon Bedrock API keys
- AWS: Access Amazon Bedrock foundation models
- AWS: Amazon Bedrock AgentCore Identity
- OWASP: Top 10 for LLM Applications 2025
- MITRE ATLAS: Cost Harvesting
Related NHI Mgmt Group resources: AWS Security Guide · AWS IAM Policies and Roles Guide · LLMjacking Guide · AI Security Posture Management (AI-SPM) Guide · MITRE ATLAS Guide