great news! the business is delighted by the scalability and resilience demonstrated by this proof-of-concept and alignment with cloud-native strategy. the busi

great news! the business is delighted by the scalability and resilience demonstrated by this proof-of-concept and alignment with cloud-native strategy. the business has decided to use this as the platform to deliver the new "hello $customer_firstname $customer_lastname" product to production. since we'll be executing brainfuck programs containing customer PII, the design may need a few standard technical enhancements to implement an acceptable level of controls to reduce the risk of customer data breaches. each edge in the design must use transport layer security (either using built-in service capability or, preferably, by addition of a service mesh to the architecture). use of plaintext database passwords in deployment configuration is unacceptable. fresh secrets need to be generated and the deployment configuration needs to be modified to read secrets from our existing secret management platform. please follow least privilege principles and define minimal roles & access to secrets for each service in the cluster. since the brainfuck machine will be processing workloads for multiple customers, in addition to coarse-grain service-level access control it will also need to enforce finer-grain access controls to restrict which parties can read from or write to which ranges of brainfuck memory cells containing information of distinct customers. this must follow our established standard by adding authentication and authorisation to each service based on stateless access tokens. please update the design to integrate with the existing token issuer.