c3.2 Use a least-privilege service role for the knowledge base
Give the Bedrock knowledge base a dedicated service role scoped to only the models, S3 sources, vector store, and keys it needs.
Implementation guidance
How to implement on AWS
Create a custom knowledge base service role with a trust relationship for Amazon Bedrock, granting only access to the required models, S3 data sources, vector database, and KMS keys. Set data-access and network-access policies on the OpenSearch Serverless collection.
Why the knowledge base needs a scoped role
A Bedrock knowledge base assumes an IAM service role to do its job: call the embeddings model, read source documents from S3, and read/write the vector store (e.g. OpenSearch Serverless). That role touches your source data and your retrieval index, so it should be dedicated to this one knowledge base and scoped to exactly the model, buckets, and collection it uses — not a broad role shared across knowledge bases.
Trust only Bedrock, guarded against confused deputy
The trust policy lets the Bedrock service principal assume the role, constrained to your account and (ideally) the specific knowledge base ARN:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "bedrock.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "aws:SourceAccount": "111122223333" },
"ArnLike": {
"aws:SourceArn": "arn:aws:bedrock:us-east-1:111122223333:knowledge-base/*"
}
}
}
]
}
Grant only the three things the KB touches
Embeddings model, S3 sources, and the vector store — each scoped to specific resources:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InvokeEmbeddingsModel",
"Effect": "Allow",
"Action": "bedrock:InvokeModel",
"Resource": "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v2:0"
},
{
"Sid": "ReadSourceDocuments",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": [
"arn:aws:s3:::my-kb-sources",
"arn:aws:s3:::my-kb-sources/*"
]
},
{
"Sid": "AccessVectorStore",
"Effect": "Allow",
"Action": "aoss:APIAccessAll",
"Resource": "arn:aws:aoss:us-east-1:111122223333:collection/<collection-id>"
}
]
}
Match the vector store's own policies
For OpenSearch Serverless, IAM is only half of it — the collection also has a data access policy that must grant this same role read/write on the index. Scope the embeddings statement to the single embeddings model ARN, and the S3 statement to only the source bucket(s) this knowledge base ingests, so the role cannot read unrelated data.
Naming note: replace the account id, Region, bucket, collection id, and embeddings model ARN. Use one role per knowledge base rather than a shared role.
Acceptance criteria
The KB uses a dedicated least-privilege role; data-access and network policies restrict the collection; no broad wildcard permissions.
Practical implementation
How this control is implemented in each reference architecture:
A dedicated knowledge base service role in the Generative AI account is scoped to only its models, S3 sources, vector store, and keys, with OpenSearch data- and network-access policies restricting the collection.
- Create a custom KB service role with a trust relationship for Amazon Bedrock, granting access only to the required models, S3 data sources, vector database, KMS keys, and any data-source credentials held in AWS Secrets Manager.
- Set data-access and network-access policies on the OpenSearch Serverless collection so only the KB role can query/write it.
- Add a permissions boundary so the KB role cannot be escalated beyond its sources and keys.
How to validate: The KB uses a dedicated role; OpenSearch data/network policies restrict the collection; IAM Access Analyzer shows no wildcard permissions.
Avoid: Giving the KB role broad S3 or Bedrock access 'to be safe'. Scope it to the exact sources, collection, and keys it uses.
A dedicated KB role in the account is scoped to its sources, collection, and keys, with OpenSearch access policies restricting the collection.
- Create a custom knowledge base service role scoped to only the required models, S3 sources, vector store, KMS keys, and data-source credentials in AWS Secrets Manager.
- Apply data-access and network-access policies on the OpenSearch Serverless collection restricting it to the KB role.
- Attach a permissions boundary to cap the role's reach.
How to validate: The KB role is dedicated and least-privilege; collection access is restricted; no wildcard permissions.
Avoid: Reusing the application runtime role for the knowledge base. Give the KB its own scoped role separate from the app and admin roles.
Threats addressed
- An over-permissive KB role reaching data beyond its sources.
- Unauthorized changes to knowledge base configuration.
AWS services
Pricing
The role and policies are free. You pay for embedding generation (per token), the vector store (OpenSearch Serverless OCUs or your chosen store), S3 storage for sources, and retrieval/generation at query time; scoping the role adds no cost. See Create a service role for Amazon Bedrock Knowledge Bases.
Framework mappings
OWASP GenAI/LLM Top 10 (2026)
- LLM02 Sensitive Information Disclosure
NIST AI Risk Management Framework (AI 100-1)
- MANAGE.1 AI risks are prioritized, responded to and managed
AWS Well-Architected Generative AI Lens (Security)
- GENSEC01-BP03 Implement least privilege access to data stores
Learning resources
References
- AWS SRA for AI — Capability 3, Identity and access management
AI Security Maturity Model