Secure Deployment
This topic describes how data is handled, processed, and protected in a customer-hosted Codebeamer AI deployment.
Customer-hosted deployment data handling and processing
In customer-hosted deployment, the runtime components are deployed entirely within the customer’s Azure tenant/subscription and are designed to be stateless.
High-level summary of data processing, usage, and storage
◦ All inference requests are processed inside the customer environment, using customer AKS + customer Azure OpenAI.
◦ PTC does not operate or access a hosted runtime for customer-hosted deployments. The t runtime components do not send prompts, responses, customer content, or runtime telemetry back to PTC.
◦ Runtime components are designed to be stateless.
▪ Application logs, traces, and spans are sent to the OTel collector and exported only to customer-configured observability platforms. The service is designed not to intentionally log prompts, personally identifiable information (PII), full responses, or other sensitive customer content. However, limited sensitive data may still appear in exception or debug scenarios. Customers must treat observability data as sensitive and enforce RBAC, encryption, and retention controls on all monitoring tools and storage.
▪ The service does not persist customer prompts or responses during normal operation.
Data processing
A customer-hosted deployment processes the following data types in memory to deliver requested features:
◦ Customer-provided inputs received from the Codebeamer AI plugin.
◦ PTC engineered prompts and system instructions used to perform the requested AI operation.
◦ Generated LLM responses returned by the customer’s Azure OpenAI endpoint and then returned to the calling service.
Data usage
◦ Prompts, inputs, and responses are used only to fulfill the active request and return results to the calling product or plugin.
◦ Operational logs, metrics, and traces are used within the customer environment for monitoring, troubleshooting, audit, and incident response.
Data storage
◦ No customer prompts and responses are stored by Codebeamer AI service as part of normal operation. Any persistence is driven by customer-side operational tooling and configuration.
◦ Customer controlled monitoring may retain logs based on customer configuration and retention settings.
◦ Azure OpenAI data handling behavior is governed by Microsoft’s published policies
Secure deployment baseline
Infrastructure as Code (IaC)
All Azure resources are deployed using Terraform (IaC), ensuring consistent, repeatable, and auditable deployments. Terraform also enforces least-privilege access and configures security controls alongside resources, reducing manual changes, preventing configuration drift.
Security controls delivered via Terraform
Terraform enforces the following security controls:
◦ AKS access uses Entra ID RBAC. Azure Network Policies control pod-to-pod traffic, permitting only approved connections with default deny posture. The AKS server allowed IP list restricts API calls to approved sources.
◦ Network Security Groups (NSGs) on the AKS VNet permit only approved IP ranges, reducing attack surface and blocking unsolicited traffic.
◦ Workload access from AKS pods to Azure resources uses managed identities to avoid secrets.
◦ Azure OpenAI is reachable only through a private endpoint inside the VNet. Name resolution is via private DNS to a private IP, preventing public DNS exposure.
◦ Public network access to Azure OpenAI is disabled. All traffic stays on the Azure backbone for private connectivity.
◦ Service calls to OpenAI use a user-assigned managed identity within the defined trust boundary. This enables fine-grained access control and rotation-free auth.
◦ Network isolation is enforced end to end, with no public exposure of Azure OpenAI endpoints. Egress is constrained to private links only.
◦ We strongly recommend customers configure authorized IP ranges for the AKS API server and whitelist egress IPs for the Codebeamer AI plugin using Terraform
Container image security
Container image is built to run as a non-root user.
Security Scanning of PTC artifacts
We recommend that customers enforce mandatory pre-consumption security scanning for all delivered artifacts, including IaC templates, container images, and Helm charts. Customers must block consumption when unresolved critical or high vulnerabilities exist and require approved exceptions for temporary risk acceptance.
It is recommended to enable runtime security scanning across all infrastructure deployed via IaC, as well as within Azure Kubernetes Service (AKS) clusters, to ensure continuous threat detection and compliance beyond build-time checks.
We also recommend retaining scan evidence, SBOMs, and artifact signatures for each release to support traceability, compliance, and secure operations.
Operational Security Guidelines
The solution includes Infrastructure as Code and a provided container image archive. These assets deliver a secure baseline for provisioning and runtime. Consumers are responsible for configuring their own service exposure controls to meet organizational and regulatory requirements. Typical external exposure patterns involve an ingress or gateway layer with TLS termination and HTTP security features and may include WAF-class protections aligned to OWASP guidance, authentication, rate limiting, and traffic filtering. Where a full WAF is not deployed, gateway-level controls can provide partial coverage but are not a complete substitute.
To operate securely, deployments typically include least-privilege access controls, network segmentation, restricted ingress, and controlled egress, for example, IP whitelisting combined with identity-based validation. These platform measures are implemented by consumers in alignment with their organizational policies.
Customers must follow best security practices when configuring additional tools such as Grafana, Prometheus, Aspire, Zipkin, or any other tool that are configured as exporters in OTEL configurations.
The storage account needed for this solution is completely customer-managed and provisioned as a prerequisite. PTC strongly recommends customers to follow security best practices, including secure network policies and access controls. For example, default network access rule for storage account must be set to deny.
Customer is responsible for completing all prerequisite resources before deployment, including identity access, network restrictions, and secret management, in alignment with organizational and Azure security best practices. Use least privilege RBAC, enable monitoring and logging, and enforce secure configurations to maintain a compliant and production-ready environment. For example, private access, encryption, and regular credential rotation.
This solution enables VNet flow logs. For deeper monitoring, customer can enable diagnostic settings and traffic analytics, following best practices to capture enriched telemetry, security insights, and additional operational context.
For more information, refer the following links.