Security Questionnaire

How are users authenticated?

OAuth 2.0 Authorization Code flow with PKCE, via Auth0

The plugin uses RFC 8252-recommended OAuth 2.0 Authorization Code with PKCE (Proof Key for Code Exchange) for native desktop applications. The user's system browser is launched to the Auth0 hosted login page; the plugin never sees the user's password. The authorization code is returned to a localhost callback and exchanged for an access token using a per-session PKCE verifier. No client secret is embedded in the binary.

Where are tokens stored on the user's machine?

Access token in memory; refresh token persisted to disk encrypted with Windows DPAPI

The short-lived JWT access token (typically 1 hour TTL) lives in process memory only and is cleared on logout or AutoCAD shutdown. The OAuth refresh token is written to %LOCALAPPDATA%\LeafSolarDesign\.rt and is encrypted at rest using Windows DPAPI (System.Security.Cryptography.ProtectedData) with CurrentUser scope and an application-specific entropy value. This binds the encrypted blob to the same Windows user account on the same machine it cannot be decrypted by another user, by another machine, or by another application impersonating us. The persisted refresh token enables silent re-authentication so the user is not prompted to log in on every AutoCAD launch.

Is multi-factor authentication supported?

Not enabled by default during Early Access; available on request via Auth0

MFA is supported by the underlying Auth0 tenant (TOTP authenticator apps, WebAuthn/FIDO2 security keys, SMS, push) and can be enforced for an Early Access customer's users on request. The plugin does not implement, intercept, or bypass MFA challenges when enabled, the MFA flow happens transparently inside the Auth0 hosted login page in the system browser.

Is SSO supported?

Yes SAML 2.0 and OpenID Connect SSO available via Auth0 enterprise connections

Auth0 supports enterprise SSO including SAML 2.0, OpenID Connect, Active Directory/LDAP federation, and Azure AD/Entra ID. Enterprise SSO is configured per customer at the Auth0 tenant level contact support@leafautomation.ai to set up an SSO connection for a trial or enterprise subscription.

How are sessions managed?

Short-lived JWT access tokens; subscription validity checked from JWT claims at every gated action

Sessions are managed via JWT access tokens issued by Auth0. Each token carries subscription claims (subscription_status, plan_type, trial_ends_at) stamped into the JWT by an Auth0 Post-Login Action. Subscription validity is checked locally from the JWT on every action that requires a license there is no separate license-server round-trip per command. When the access token expires, the plugin uses the encrypted refresh token to silently obtain a new one; if the refresh token is also expired, the user is prompted to log in again.

Are there any hardcoded credentials in the source code?

No client secrets, no third-party API keys

The Auth0 Client ID is embedded in the binary, which is correct per OAuth 2.0 PKCE public clients have no client secret. No third-party API keys are embedded in current shipping builds. A previous build had a Google Maps Geocoding key and an NREL ReOPT key as compile-time constants; both have been removed from source. The Geocoding code path now degrades gracefully (zip-to-coordinate lookup is no-op pending a server-side proxy) and the REOPT command is disabled in shipping builds because the underlying lat/lon plumbing was incorrect.

What data does the application collect?

Identity (email, Auth0 user ID), usage telemetry, optional bug-report attachments, and panel-layout grids submitted to the cloud solver

Five categories: (1) Identity, including email and Auth0 user ID from the authentication token, used for licensing and support correlation. (2) Usage telemetry, including command names, plugin/OS/AutoCAD versions, session id, drawing filename, and exception stack traces (full event catalog available on request). (3) Bug-report submissions, only when the user explicitly opens the bug-report dialog and clicks Submit; the user controls per-attachment what is included (see DWG upload question below). (4) Cloud solver inputs: every time the user runs the Solar String Design Solver (the core panel-stringing automation feature of the product), the panel layout grid for that drawing is sent to our backend so the model can produce a stringing solution; see the AI/ML question below for details. (5) Project location strings (zip code), when the user provides a project zip code in the StringSizer flow, are sent to our backend so it can fetch ASHRAE/NSRDB weather data on the user's behalf; the zip itself is not sent to any third-party service from the plugin. No financial data, no health data, no Social Security numbers, no Controlled Unclassified Information.

Where is data stored locally on the user's machine?

Four locations under %LOCALAPPDATA% and the Windows registry

(a) %LOCALAPPDATA%\LeafSolarDesign\.rt holds the DPAPI-encrypted OAuth refresh token (see Section 1). (b) %LOCALAPPDATA%\LEAFAutomation\BranchPlugin\*.db holds SQLite databases containing publicly available manufacturer equipment specifications (inverter and module datasheets, cable ampacity tables). No PII, no project data, no credentials. (c) HKCU\Software\AEC BIM Tools Ltd\Branch\ holds Windows registry keys with UI preferences and persistent form input/output data from previous runs (last-entered project name, last-used module/inverter selections, dialog dimensions, design defaults). This data is stored unencrypted and is protected by standard Windows NTFS user-account ACLs. It does not include drawings, credentials, or PII beyond what the user has typed into the plugin's own forms. (d) Design data is stored as XData embedded inside the user's own AutoCAD DWG files; the plugin never copies or uploads these files in normal operation.

Is data encrypted at rest?

OAuth refresh token: yes (DPAPI). Equipment databases: no (public data only). Server-side telemetry: yes (Google Cloud default encryption).

At rest on the user's workstation: the OAuth refresh token is DPAPI-encrypted and bound to the Windows user account. The local SQLite equipment databases are not encrypted because they contain only publicly available manufacturer datasheet data no credentials, PII, or customer project data. UI preferences in the registry follow the standard Windows ACL model. At rest on our backend: telemetry events stored in Google Cloud BigQuery and Cloud Logging are encrypted using Google Cloud's default at-rest encryption (AES-256). Backend database storage on the API server is encrypted at the underlying volume level by the hosting provider.

Is data encrypted in transit?

Yes HTTPS / TLS 1.2 or higher for every outbound connection

All external API communications use HTTPS with TLS 1.2 or higher. The plugin does not override .NET's default certificate validation, so connections are validated against the Windows certificate store and the system trust roots. There are no plaintext HTTP endpoints and no certificate-pinning bypasses. Endpoints reached: Auth0 (auth.leafautomation.us.auth0.com), api.leafdesign.ai (license, string sizer, cloud solver, weather data), telemetry-973968415611.us-central1.run.app (Google Cloud Function for telemetry), api.github.com (release update check, version metadata only), and formspree.io (only when the user explicitly submits a bug report).

Does the plugin upload CAD files or drawings?

Not in normal operation. Drawings are only uploaded if the user explicitly opts in via the bug-report dialog.

In normal operation, project files, drawings, geometry, and design data remain on the user's machine. The plugin stores its design metadata as XData inside the user's own DWG files, which the user controls and saves to their own storage. The only way a DWG leaves the user's machine is via the optional bug-report attachment: when a user opens the bug-report dialog, an 'Include drawing' checkbox is shown the checkbox defaults to UNCHECKED and the user must explicitly tick it to attach the current DWG. When attached, the DWG is sent (via HTTPS) along with the bug description to our support inbox. There is a 25 MB size limit. Bug-report DWGs are retained only for the duration of the support case and are not used for any other purpose.

Are panel layouts or design data used to train AI/ML models?

The abstracted panel grid sent to the Solar String Design Solver (and only that) is retained and used to improve future model versions. No project metadata, no customer identifiers, no proprietary content.

The Branch plugin includes a Solar String Design Solver, which is the core panel-stringing automation feature of the product. It is a cloud-based solver. There is no local-only fallback. When the user runs it, the plugin sends an abstracted 2D grid (typically up to 32x32 cells) marking which positions hold panels to our backend. The backend ML model returns an optimized stringing solution. We retain the input grid, the model's intermediate scoring outputs (soft and hard logits), and the final solution, and use this retained data to train and evaluate future versions of the model. The retained grids are geometric data only and are not associated with any customer identifier on the training corpus. We do not retain or transmit the surrounding DWG, the project location, customer name, project name, file path, title-block content, or any identifying metadata. There is no per-account opt-out. A live, public demonstration of the solver is available at https://leafautomation.ai/demo and lets reviewers see the exact 32x32 grid representation that is transmitted; no login is required.

How long is telemetry data retained on the backend?

Indefinitely during Early Access; 90-day rolling window after general availability

Telemetry events are received by a Google Cloud Function in us-central1, written to Google Cloud Logging (1-day default-bucket retention), and sinked into BigQuery (dataset branch_analytics). During the Early Access period telemetry is retained indefinitely so the team can work through the issue and feature backlog. After general availability, a 90-day rolling partition expiration will be applied and tables older than 90 days will be automatically deleted by BigQuery. Customers can request deletion of their identity-keyed telemetry events at any time by emailing support@leafautomation.ai with their account email; we will purge matching rows within 30 days of the request.

Where is data stored geographically?

United States Google Cloud us-central1 (Iowa) for telemetry; Cloudflare-fronted Namecheap US hosting for the API

Telemetry is processed and stored exclusively in Google Cloud's us-central1 region (Council Bluffs, Iowa). The api.leafdesign.ai backend is hosted on Namecheap (United States) and is fronted by Cloudflare for TLS termination and DDoS protection Cloudflare's edge network is global but our origin and at-rest data are in the US. Auth0 identity records are stored in Auth0's US tenant region. No customer data is processed or stored in EU, APAC, or any other geography.

What external services does the plugin connect to?

Five destinations, all over HTTPS

(1) Auth0 (leafautomation.us.auth0.com) for user authentication and token refresh. (2) api.leafdesign.ai for license validation, the StringSizer cloud calculation, the Solar String Design Solver, the inverter-placement function, the geocoding proxy, and ASHRAE/NSRDB weather data fetching. All cloud-side calculation features front through this single API gateway. (3) Google Cloud Function in us-central1 (us-central1-branch-api-466316.cloudfunctions.net) for usage telemetry. (4) api.github.com for the startup release-version check (returns release metadata only; no user data sent in the request). (5) formspree.io only when the user explicitly submits a bug report; carries the user-typed bug description and any user-selected attachments.

What firewall rules are required to use the plugin?

Outbound HTTPS (TCP 443) to a small list of hostnames; no inbound ports

Required outbound HTTPS: • *.auth0.com (authentication) • api.leafdesign.ai (Leaf Automation backend API) • us-central1-branch-api-466316.cloudfunctions.net (telemetry) • *.run.app (Google Cloud Run, hosting our Cloud Functions) • api.github.com (release update check) • formspree.io (user-initiated bug reports only) No inbound ports are required. The plugin uses a transient localhost callback on a high port (8080) only during the OAuth login flow for the few seconds Auth0 needs to redirect back; this listener is bound to 127.0.0.1 only and is closed immediately after the code exchange.

Are TLS certificates properly validated?

Yes default .NET validation against the Windows certificate store; no custom bypasses

The plugin does not register a ServerCertificateValidationCallback, does not call ServicePointManager.ServerCertificateValidationCallback, does not implement certificate pinning, and does not allow self-signed or expired certificates. All certificate validation uses the Windows certificate store via .NET's default behavior.

Is all network traffic encrypted?

Yes every outbound connection uses HTTPS / TLS 1.2 or higher

There are no HTTP-only endpoints in the codebase. The minimum negotiated TLS version is enforced via the .NET / Windows TLS stack defaults; on supported Windows versions this is TLS 1.2 or higher.

Does the plugin make any peer-to-peer or local-network connections?

No

The plugin does not open any sockets to LAN devices, does not perform service discovery, does not use mDNS/Bonjour/UPnP, and does not listen on any non-loopback interface.

How are third-party dependencies managed?

NuGet packages with explicit version pinning; manual review before updates

The project uses NuGet packages with explicit version specifications in each .csproj file. Dependency updates are reviewed manually before integration. Vulnerability scanning via dotnet-list-package and GitHub Dependabot alerts is in progress for the CI/CD pipeline.

How is user input validated?

Parameterized SQL, trusted file-path sources, safe JSON deserialization

All SQL queries against the local SQLite databases use parameterized queries (SqlCommand.Parameters.AddWithValue) no string concatenation of user input into SQL. File paths come only from trusted sources (Environment.GetFolderPath, OpenFileDialog/SaveFileDialog, Path.GetTempPath) no user-provided strings concatenated into filesystem paths. JSON deserialization (Newtonsoft.Json) is performed without TypeNameHandling enabled, which prevents deserialization-of-untrusted-data exploits.

Can the plugin access files outside its working directory?

Only files the user explicitly selects via OS dialogs, plus its own per-user data directory

The plugin reads/writes to: %LOCALAPPDATA%\LeafSolarDesign and %LOCALAPPDATA%\LEAFAutomation (its own per-user data), %TEMP% (transient files), files the user explicitly opens via AutoCAD's own file dialogs, and the currently open DWG. It does not enumerate the filesystem outside these locations and does not use user-supplied strings as path components.

How is the software distributed and signed?

Signed DLLs delivered via Leaf Automation portal during Early Access; Autodesk App Store distribution planned

Plugin DLLs are code-signed using a SafeNet hardware token before distribution. The build pipeline produces signed assemblies for AutoCAD versions 2018 through 2026 and packages them in a unified bundle. During Early Access, users download the bundle directly from the Leaf Automation portal and install it into AutoCAD's ApplicationPlugins folder. Distribution via the Autodesk App Store is planned for general availability.

Does the plugin run with elevated privileges?

No runs entirely in the user's AutoCAD session with the user's privileges

The plugin loads as an in-process .NET assembly inside AutoCAD and inherits the privileges of the AutoCAD process typically a non-elevated user session. It does not request UAC elevation, does not write to %PROGRAMFILES% or %WINDIR% at runtime, does not modify HKEY_LOCAL_MACHINE registry keys, and does not install any Windows services or scheduled tasks.

What security certifications does Leaf Automation hold?

None directly. We rely on certified subprocessors.

Leaf Automation is a small ISV and does not currently hold SOC 2, ISO 27001, or any other formal security certification. We rely on certified subprocessors for all sensitive infrastructure: Auth0 (SOC 2 Type II, ISO 27001, GDPR), Google Cloud Platform (SOC 1/2/3, ISO 27001, ISO 27017, ISO 27018, FedRAMP, HIPAA-eligible), Neon (SOC 2 Type II), Cloudflare (SOC 2 Type II, ISO 27001), Namecheap (SOC 2 hosting), Vercel (SOC 2 Type II, ISO 27001), Formspree (SOC 2 Type II), and Stripe (PCI DSS Level 1, SOC 1/2 Type II) named as the payment processor in our EULA and planned for general availability; there is no live Stripe integration during the Early Access trial period. Customer projects requiring direct vendor certification at the ISV level are not a fit for Branch in its current Early Access phase.

Is Branch suitable for handling Controlled Unclassified Information (CUI)?

No

Branch is commercial drafting automation software for solar PV layout and is not designed, built, or assessed against CMMC, NIST SP 800-171, or any other CUI handling standard. Customers whose projects contain CUI should not use Branch on those projects. If you are not sure whether your projects contain CUI, please consult your organization's compliance team before starting a trial.

When was the last security review?

April 2026 full source-code audit producing this document

The current security review (April 2026) was a complete code-level audit of all network egress, data persistence, authentication, and third-party dependencies in the plugin. Findings drove a hardening pass that included: encrypting the OAuth refresh token at rest with Windows DPAPI, removing two hardcoded third-party API keys from source, disabling a feature with broken geographic-coordinate handling, adding a registry-controlled telemetry opt-out, and changing the bug-report drawing-attachment default to opt-in. The page you are reading is rewritten directly from the post-audit source code.

Is there a vulnerability disclosure process?

Yes support@leafautomation.ai

Security issues can be reported to support@leafautomation.ai. We acknowledge receipt within 2 business days and provide a remediation timeline within 5 business days. We do not currently offer a paid bug bounty but we credit reporters in release notes (with permission).

What is the breach notification commitment?

Without undue delay after we confirm an incident affecting customer data

Leaf Automation is a small ISV operated by a single principal developer. We do not maintain a 24/7 SOC. In the event of a confirmed security incident affecting customer identity or telemetry data, we will notify affected customers via email without undue delay after confirming the incident, typically within a small number of business days. Notifications include the nature of the incident, the categories of data affected, the actions we have taken, and recommended steps for the customer. Customers requiring a contractually binding shorter notification window should contact support@leafautomation.ai.

What is the patch cadence for security updates?

Critical: immediately. High: within 14 days. Medium/Low: next regular release.

Critical-severity issues are addressed in an out-of-band hotfix release. High-severity issues are addressed in the next scheduled release within 14 days. Medium and low severity issues are bundled into the next regular product release. The plugin's built-in update checker notifies users when a new release is available.

Who owns customer data and the design outputs the plugin produces?

The customer. Section 4.2 of the Branch EULA addresses this directly.

As between Leaf Automation and the customer, the customer retains all right, title, and interest in (a) the AutoCAD drawings, design files, and project data the customer uses with the plugin (Customer Input), and (b) the design outputs the plugin generates from Customer Input (Customer Output). Leaf Automation claims no ownership of either, and uses Customer Input only to operate the plugin for the customer's benefit, to provide support, and for the limited training-data uses described in our privacy policy. See Section 4.2 of the EULA at https://leafautomation.ai/eula for the full text.

Is Leaf Automation the engineer of record for designs the plugin produces?

No. Branch is drafting automation, not engineering. Section 3 of the EULA addresses this directly.

Section 3 of the EULA states that the plugin is "intended solely for use by qualified engineering professionals" and requires that "ALL OUTPUTS MUST BE INDEPENDENTLY VERIFIED BY A LICENSED PROFESSIONAL ENGINEER BEFORE USE IN ANY PROJECT." Branch is drafting automation, not engineering. Leaf Automation does not produce stamped, permit-ready, or otherwise certified electrical designs, makes no representations as to the correctness, code-compliance, or constructibility of any output the plugin generates, and is not the Engineer of Record for any project on which Branch is used. The Licensee is solely responsible for ensuring all designs comply with applicable codes and standards (including NEC Article 690), obtaining required PE stamps and certifications, conducting on-site verification, and making all final engineering decisions. All liability for the resulting design sits with the human EOR.

What personal information is collected?

Email, name, Auth0 user identifier, Windows machine name

From Auth0 authentication: email address, full name (if the user provided it during signup), and the Auth0-issued user identifier (the JWT 'sub' claim). From telemetry: Windows machine name (collected once at session start), Windows username (used as a fallback identifier only when the user is not authenticated), session id (a per-session GUID), and the filename of the currently open drawing. From bug reports (only when the user submits one): the user's email address (if the 'include contact info' checkbox is checked, which is the default but can be unchecked) and any text the user types into the bug-description field. No financial information, no health information, no Social Security numbers, no government identifiers.

Is there a privacy policy?

Yes at leafautomation.ai/privacy

The full privacy policy covers data collection, use, retention, deletion rights, and the role of subprocessors. The privacy policy is the authoritative customer-facing document; this questionnaire summarizes the technical implementation details that the privacy policy references.

Can users opt out of telemetry?

Not during the Early Access trial period. Three configurable modes will be exposed at general availability.

Telemetry collection is mandatory during the Early Access trial period and is not user-configurable. The plugin source code supports three privacy modes (Full, Errors, Off) controlled by the Windows registry value HKCU\Software\AEC BIM Tools Ltd\Branch\TelemetryMode, but during Early Access the runtime is fixed at Full and the registry value is not honored. At general availability the three modes will be exposed in the plugin settings UI: "Full" (all events sent with full diagnostic detail), "Errors" (only command-execution events, exceptions, errors, and lifecycle events), and "Off" (every event call site still fires so license use can be confirmed for billing, but the payload is stripped to just event type, irreversible SHA256 hash of the user id, session id, and plugin version; message body, drawing filename, OS version, AutoCAD version, command name, stack traces, and custom properties are all dropped).

Can customers request deletion of their data?

Yes by emailing support@leafautomation.ai

Customers can request deletion of their account at any time, including deletion of trial data after a trial ends. Deletion requests cover: the Auth0 identity record, any telemetry events keyed to the user id within the active 90-day BigQuery retention window, and any bug-report submissions associated with the account. Deletion is processed within 30 days of a verified request. Backups containing residual data are aged out under their own retention schedule and are inaccessible to operational systems.

What happens to customer data at the end of a trial?

Retained until the customer requests deletion, then deleted within 30 days

At the end of an Early Access trial, customer data is retained until the customer either converts to a paid subscription or requests deletion. We do not auto-delete trial data on trial expiry this gives customers a window to export anything they need. Customers can request deletion at any time during or after the trial via support@leafautomation.ai.

Is data shared with third parties?

Only with subprocessors required to deliver the service

Customer data is shared only with these subprocessors, in each case for a single specific operational purpose: Auth0 (identity, MFA, SSO), Google Cloud Platform (telemetry storage and analytics in us-central1, and the Branch API gateway for all cloud-side calculation features including the Solar String Design Solver, k-means clustering, inverter placement, geocoding proxy, and ASHRAE/NSRDB weather lookups), Neon (serverless Postgres for EULA acceptance records and license/subscription state), Cloudflare (TLS termination and DDoS protection in front of api.leafdesign.ai), Namecheap (US-based hosting of api.leafdesign.ai origin), Vercel (marketing website hosting), and Formspree (relay of optional bug-report submissions to our support inbox). No customer data is sold, rented, shared with advertisers, or shared with any other third party. Aggregated, deidentified usage statistics may be referenced in marketing materials, but never with any individual customer identifiable.

Who at Leaf Automation can access customer data?

The principal developer and founder. Access is logged at the cloud-provider level.

Leaf Automation currently operates as a single-developer ISV. The principal developer is the only person with admin access to the Auth0 tenant, the GCP telemetry project, the BigQuery dataset, and the Formspree bug-report inbox. All admin access events are logged by the underlying providers (Auth0 audit logs, GCP Cloud Audit Logs) and retained per their respective policies.