Protecting engineering IP

Security & Trust

Last updated October 26, 2026

Pre-release security review. This page describes the intended control model, not a certification or audit report. Contractual commitments apply only when recorded in a signed security schedule and must be validated before launch.

Customer boundaryTenant, identity and authorization context travel with design, verification and learning workflows.

Deployment choiceManaged, private-cloud and controlled local deployments assign responsibilities differently.

Reviewable operationPrivileged actions, partner access and AI approvals are designed to leave an audit trail.

Start with your security requirements.

Before sharing confidential designs or technology material, agree the deployment boundary, permitted processing, operator access and assurance required by your organization. Architecture intent is not a substitute for checking the selected release and environment.

Validate for the selected deployment: Tenant and resource authorization; transport and storage encryption; model endpoints and outbound connections; support access; audit coverage; data retention and deletion; backup restoration and patch responsibility.
AI data-use policy: The architecture specifies local inference and no customer-data training by default. Confirm model-provider retention, prompt logging, approved data use and any exceptions in configuration and the signed agreement. Self-hosting alone does not establish those protections.
Disconnected operation: Qualify the complete runtime without external services, including model artifacts, licensing, authentication dependencies and telemetry. Agree controlled update delivery, vulnerability response and backup procedures before claiming an air-gapped deployment.
Architecture evolution: A more isolated Technology Vault and license-aware retrieval controls are part of the target architecture. They are not represented here as universally available or verified. Planned controls must not be relied on for current customer requirements.

Discuss an enterprise security review. Provide high-level requirements only; do not submit designs, PDK files, credentials or confidential security documentation through the public enquiry form.

1. Security control model

Wafercad is designed around tenant isolation, least-privilege authorization, private service boundaries, auditable workflows and deployment-specific controls. Security requirements apply across browser clients, APIs, databases, queues, workers, storage, deterministic engines and AI services rather than stopping at the web interface.

The Order Form and security schedule define the deployed architecture, covered services, support boundary and any customer-specific requirements. This page does not claim a certification or make every control applicable to every deployment.

2. Identity, authorization and administration

Access is designed to use authenticated identities, tenant context, role-based authorization and scoped entitlements. Privileged platform administration is separated from organization and institution administration. Sensitive actions should require current authorization and generate an attributable audit event.

Authorized Channel Partner access is disabled unless included in the service arrangement and approved by the customer. When enabled, it should use named accounts, a bounded support role, time or purpose limitations where practical, and auditable activity. Shared support credentials are not an acceptable default.

3. Data protection

Hosted deployments are designed to protect data in transit and at rest using current cryptographic protocols and managed key controls. Exact algorithms, key ownership, customer-managed-key options and residency are deployment- and contract-specific. Database, object storage, backup and message-service access should remain on private service networks unless an approved interface requires otherwise.

Tenant identifiers and authorization checks are carried through service calls and data access. Secrets must be held in approved secret-management systems rather than source code or images. Production access is limited to authorized operational purposes and subject to logging and review.

4. Customer PDK and technology data

Customer-provided PDKs, rule decks, models, DRM material and related technology files are treated as confidential Customer Content. They may be accepted only when the customer has the right to provide and use them in the selected environment. Handling is governed by the NDA, service agreement, DPA where personal data is involved, and any customer-specific security schedule.

Access should be restricted to the authorized tenant, services and personnel; use for another customer, publication or redistribution is prohibited. Support or translation work may require separately approved, logged access. Processing a customer-supplied PDK does not represent foundry endorsement, redistribution permission, silicon qualification or signoff status.

5. Logging, audit and operational telemetry

Security logs, traces, metrics and durable audit records support incident detection, reliability, usage governance and review of privileged activity. Telemetry is designed to use bounded identifiers and operational attributes rather than full design payloads, source files, credentials or unnecessary personal data.

Access to platform-wide observability is restricted to authorized platform operators. Customer-facing audit data and retention are defined by edition and contract. Collection levels may differ for managed and customer-controlled deployments.

6. Secure development and vulnerability management

Engineering practices are intended to include peer review, automated testing, dependency and container-image checks, controlled build provenance, secret scanning, environment separation, change review and reproducible deployment definitions. Findings are prioritized by exploitability, data exposure and service impact, with remediation targets defined by internal policy or contract.

Third-party components and infrastructure remain subject to their own security advisories and support lifecycles. Releases and patches are qualified before promotion, proportionate to urgency and risk.

7. AI-service boundaries

AI features use the same tenant, role, entitlement and resource authorization as the underlying engineering service. Retrieval is intended to return only sources the requesting user may access. Model gateways receive the minimum context needed for the feature and are configured according to the agreed hosting and retention model.

AI output cannot directly perform an engineering mutation merely by producing text. Supported changes use typed proposals, deterministic validation, explicit authorization and audit records. Model responses remain non-authoritative; deterministic engines and approved engineering processes control technical results.

8. Detection and incident response

Operational monitoring is designed to surface authentication anomalies, service failures, export problems and control degradation. The incident process should cover triage, containment, investigation, recovery, evidence preservation, corrective action and post-incident review.

Customers are notified of a confirmed security incident affecting their data in the timeframe and manner required by the signed agreement and applicable law. Notices should include known scope, likely consequences, containment and recommended customer action as information becomes available.

9. Backup, recovery and continuity

Backup scope, location, encryption, retention, restoration testing and recovery targets are defined by deployment and service tier. Customers remain responsible for exports or backups assigned to them in customer-controlled deployments. A backup is not treated as verified until its restoration path has been tested.

10. Shared responsibility by deployment

Managed service: Wafercad operates the application and contracted infrastructure; the customer manages its users, role assignments, endpoints, content, PDK rights and approved integrations.
Private cloud: Responsibilities for cloud accounts, networks, keys, cluster operations and application support are allocated in the architecture and security schedule.
Controlled local or dark-site deployment: The customer generally controls facilities, hardware, network, identity integration, backups and physical access; Wafercad responsibilities are limited to the contracted software and support boundary.

11. Assurance and customer review

Subject to confidentiality and availability, contracted customers may request architecture information, security questionnaires, relevant test summaries or other assurance material. Any audit, penetration test or control-report rights must be stated in the agreement. No certification should be inferred unless Wafercad publishes the exact scope, auditor and validity period.

12. Responsible disclosure

Use the Wafercad contact form, identify the request as a security report, and do not include exploit code, credentials or customer data in the first message. We will provide a controlled follow-up channel. Researchers must avoid privacy violations, service disruption, destructive testing and access beyond what is necessary to demonstrate the issue.