Security and Compliance is a shared responsibility between AWS and the customer.
This shared model can help relieve the customer's operational burden as AWS operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates.
The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall. Customers should carefully consider the services they choose as their responsibilities vary depending on the services used, the integration of those services into their IT environment, and applicable laws and regulations. The nature of this shared responsibility also provides the flexibility and customer control that permits the deployment. As shown in the chart below, this differentiation of responsibility is commonly referred to as Security "of" the Cloud versus Security "in" the Cloud.
For more details, please refer to AWS Shared Responsibility Model.
There are three pillars when considering security of LLM applications:
- Security and Privacy of your data;
- Safety; and
- Responsibility.
Amazon Bedrock offers a host of features and controls around these three pillars. For an in-depth description please consult the service page.
We do emphasize some general recommendations:
We recommend you monitor the usage of the service to detect anomalies that might correlate to attack attempts such as Denial-of-service, brute-force attacks or even unintended noisy-neighbor events.
As a suggestion, consider some form of rate limiting to both avoid malicious attacks and also to avoid over-consumption of the service.
LLM applications are subject to novel class of security threats, such as those described in the OWASP Top 10 for LLM Applications.
The security considerations below are not comprehensive and as you move to production we recommend you dive deeper into both the security model of the Amazon Bedrock platform (see details in Amazon Bedrock Security) and security model for LLMs in general, such as those described by OWASP.
This manipulates a large language model (LLM) through crafty inputs, causing unintended actions by the LLM. Direct injections overwrite system prompts, while indirect ones manipulate inputs from external sources.
As a recommendation you can apply guardrails to the inputs to LLM.
This sample uses Anthropic Claude models which have been shown by some benchmarks to be more robust against this type of attack.
Jailbreaking is the class of attacks that attempt to subvert safety filters built into the LLMs themselves.
There is a subtle difference between Prompt Injection and Jailbreaking. See details here.
LLMs may inadvertently reveal confidential data in its responses, leading to unauthorized data access, privacy violations, and security breaches. It is crucial to implement data sanitization and strict user policies to mitigate this.
It should be noted that this sample does not allow users to directly interact with the LLM, however, malicious users may employ subversive attacks, such as purposefuly including text in JIRA tickets to confound the models. Even though we find this highly unlikely, it is important to point out this vulnerability.
Systems or people overly depending on LLMs without oversight may face misinformation, miscommunication, legal issues, and security vulnerabilities due to incorrect or inappropriate content generated by LLMs.
This risk is inherent to all LLM applications. As a mitigation we suggest that you use this sample as an assistant to a human, in order to increase productivity, but with some overseeing of the content generated.
Guardrails for Amazon Bedrock provides additional customizable safeguards on top of the native protections of FMs, delivering safety protections that is among the best in the industry by:
For speed, in this sample, we did not use Guardrails for Amazon Bedrock. You should evaluate if this is a necessary safeguard by weighing against your security posture.
Consider enabling model invocation logging and set alerts to ensure adherence to any responsible AI policies.
Model invocation logging is disabled by default. See Model Invocation Logging for details.
AWS has a series of best practices and guidelines around IAM.
In this sample, we used the default AWSLambdaBasicExecutionRole AWS Managed Policy to facilitate development. AWS Managed Policies don't grant least privileges in order to cover common use cases. The best practice it to write a custom policy with only the permissions needed by the task. More information at: Use AWS Defined Policies.
In this sample, some policies use wildcards to specify resources to expedite development. The best practice is to create policies that grant least privileges. For more information refer to: Grant Least Privilege
AWS Config is a service that maintains a configuration history of your AWS resources and evaluates the configuration against best practices and your internal policies. You can use this information for operational troubleshooting, audit, and compliance use cases.
You should consider enabling AWS Config all regions in your account.
For more details on AWS Config best practices, please refer to the AWS Config best practices blog post.
You automatically have access to the CloudTrail Event history when you create your AWS account. The Event history provides a viewable, searchable, downloadable, and immutable record of the past 90 days of recorded management events in an AWS Region.
We recommend that you create a trail or a CloudTrail Lake event data store for your resources extending past 90 days:
- Enable DynamoDB data plane logging
- Enable API logging
In Amazon CloudWatch, you can create your own metrics and alarms. While this project does not implement any metrics, we recommend that you go over the list of recommended CloudWatch alarms and set up the metrics that make sense for your own use case.
When using CloudWatch, consider configuring appropriate log retention periods and using IAM policies to control access to logs and metrics. You may want to consider enabling encryption at rest for CloudWatch log groups using AWS KMS. Be mindful that sensitive data should not be logged or should be properly redacted in log entries.
AWS X-Ray helps developers analyze and debug production applications. X-Ray encrypts traces at rest by default using AWS managed keys.
You should configure sampling rates to balance observability with performance and cost considerations. We recommend controlling access to X-Ray service maps and trace data using IAM policies, and being cautious about including sensitive information in trace annotations and metadata.
This project uses AWS Managed keys to encrypt resources. While this reduces the administrative burden of managing encryption keys, please consider using a Customer Managed Key (CMK) if you are subject to corporate or regulatory policies that require complete control in terms of creation, rotation, deletion as well as the access control and usage policy of encryption keys.
For more information on how to create an manage your keys, refer to AWS Key Management Service concepts.
Amazon S3 provides a number of security features to consider as you develop and implement your own security policies. The following best practices are general guidelines and don't represent a complete security solution. Because these best practices might not be appropriate or sufficient for your environment, treat them as helpful considerations rather than prescriptions.
For an in-depth description of best practices around S3, please refer to Security Best Practices for Amazon S3. At a minimum, we recommend that you:
- Ensure that your Amazon S3 buckets use the correct policies and are not publicly accessible;
- Implement least privilege access;
- Consider encryption at-rest (on disk);
- Enforce encryption in-transit by restricting access using secure transport (TLS);
- Enable object versioning when applicable; and
- Enable cross-region replication as a disaster recovery strategy;
- Consider if the data stored in the buckets warrants enabling MFA delete.
We implement encryption at rest with AWS KMS Customer Managed Keys. You may want to consider implementing client-side encryption to further protect sensitive data.
For an in-depth description of best practices around DynamoDB, please refer to DynamoDB security best practices.
Logging can become verbose in prod and too many logs can make analysis difficult. Logging can also disclose data. For further AWS-recommended best practices, see Logging best practices.
This application includes logging for debugging and monitoring. Exercise caution with log levels to avoid exposing sensitive information such as customer data, PII, authentication credentials, or business-sensitive RFP content. Use INFO or higher log levels in production, and reserve DEBUG for development environments only. Review log statements to ensure sensitive data is not inadvertently logged.
This project uses AWS Lambda provided runtimes.
Lambda's standard deprecation policy is to deprecate a runtime when any major component of the runtime reaches the end of community long-term support (LTS) and security updates are no longer available. Most usually, this is the language runtime, though in some cases, a runtime can be deprecated because the operating system (OS) reaches end of LTS.
After a runtime is deprecated, AWS may no longer apply security patches or updates to that runtime, and functions using that runtime are no longer eligible for technical support. Such deprecated runtimes are provided 'as-is', without any warranties, and may contain bugs, errors, defects, or other vulnerabilities.
You should periodically review and update each AWS Lambda function runtime making sure that it is in the list of supported runtimes.
When configuring IAM execution roles for Lambda functions, we recommend following the principle of least privilege. You should also consider encrypting sensitive environment variables using AWS KMS where applicable.
You should periodically run security and vulnerability scans for the code, dependencies and images in your Lambda functions and Lambda layers.
You can use tools like AWS Inspector or choose your own scanning tool.
For scanning this sample, we used ASH - The Automated Security Helper. The security helper tool was created to help you reduce the probability of a security violation in a new code, infrastructure or IAM configuration by providing a fast and easy tool to conduct preliminary security check as early as possible within your development process.
This sample uses a third-party MCP server (@negokaz/excel-mcp-server from npm) for Excel file processing capabilities. This MCP server is MIT licensed and runs isolated within the same runtime as the answering agent without external network connections or additional permissions.
The MIT license is compatible with this Apache 2.0 licensed sample. Since the MCP server operates in an isolated environment within the agent runtime, it does not introduce additional security considerations beyond standard dependency management practices.
This sample processes RFP documents and company information that may be sensitive. Consider implementing a data classification approach that distinguishes between different sensitivity levels of your data.
When deploying AI systems for business processes like RFP response generation, be aware that LLMs may reflect biases present in their training data. We recommend testing your system with diverse RFP types and formats to identify potential biases, and implementing human oversight for generated responses before submission.
This is a development sample with some acknowledged security shortcuts to facilitate demonstration and development. For instance, Bedrock Guardrails are not implemented, IAM policies use wildcards for convenience, CORS configurations allow localhost origins for local development, and input validation is kept basic for sample purposes.
These limitations are acceptable for demonstration purposes but would require remediation if moving to production use.