The Pathix security posture is shaped by four architectural commitments. Each one narrows the surface that the platform introduces into your environment, and each one is enforced in code, not just policy.
Pathix is delivered as an ARM/Bicep template you deploy into your own Azure subscription. The vendor maintains no production infrastructure that processes customer data.
The metadata-only boundary is enforced at the SDK wrapper, the database schema and code review. Pathix has no generic Retrieve method, no value/content/data column, and no path for record bodies to enter the system.
No long-lived secrets, client passwords or API keys are required for the platform to operate. Service-to-service auth uses system-assigned Managed Identity bound to the Container App.
AI features run only against an AI provider you configure (Azure OpenAI, OpenAI or Anthropic). The vendor never proxies, brokers or stores AI provider credentials. AI-proposed edges are labelled AI-derived and never override a deterministic finding.
Pathix is delivered as a Bicep template that provisions a single set of Azure resources in a region you choose. The vendor has no production database, file storage or compute that processes customer data.
The metadata-only commitment is the foundation of the rest of the compliance posture. It is enforced through three independent architectural layers, not policy alone.
All Dataverse calls route through one internal wrapper class with a deliberately constrained method surface (GetEntityMetadata, GetSecurityRoles, GetWorkflowDefinitions). No generic Retrieve. No raw organization service. No other component may reference the Dataverse SDK directly, and an architectural fitness test in CI enforces this at build time: a violation blocks the merge.
The Pathix relational schema contains no generic value, content or data columns. Customer-authored content like workflow XAML and form JavaScript is processed in memory during a scan and is not persisted. Derived structural outputs are stored. Raw bodies are not.
Every change touching Dataverse ingestion is reviewed against an explicit checklist: does this introduce a new path for record data, expose values in logs/errors/telemetry, or surface customer record contents in the UI?
End-user authentication uses Microsoft Entra ID via OAuth 2.0 with PKCE. Service-to-service authentication to Dataverse uses a system-assigned Managed Identity. The required Dataverse privileges ship as a single managed solution containing one role: Pathix Scanner.
Microsoft Entra ID via MSAL · OAuth 2.0 Authorization Code with PKCE. MFA, conditional access and identity protection apply transparently from your tenant.
System-assigned Managed Identity bound to the Container App. No client secrets, no certificates, no connection strings carrying credentials.
Authorization is enforced at the API layer. The UI reflects but does not enforce decisions. Provisioning, role changes and auth events are emitted to your Application Insights.
Every privilege the Pathix Scanner role requests, exactly as it ships and as published in the security whitepaper. All 31 are Read, all at Organization scope, and all on configuration and metadata entities: plugin and SDK registration, automation, the security model, solutions, and table, column and relationship metadata. Not one grants read on a business-data table like account or contact. The metadata-only boundary, made concrete.
Read-only, Organization scope, packaged in a single managed solution. The full table with scope and operation columns is in the security whitepaper, Appendix A.1.
Pathix delegates all cryptographic operations to Azure platform services. Customer-Managed Keys are supported via Azure SQL and Key Vault configuration; Pathix imposes no constraints on that choice.
TLS 1.2+ on all communication. Cipher suites restricted to Azure default policy. Applies to Dataverse, Entra ID, Azure SQL, Key Vault, and any AI provider.
Azure SQL Transparent Data Encryption · Microsoft-managed keys (CMK supported). Key Vault HSMs are FIPS 140-2 Level 2 validated at the Azure platform level.
License key and integration secrets in Azure Key Vault. Access gated by Managed Identity and Azure RBAC. Never written to config files, env vars or logs.
Azure-managed TLS endpoint. Optional VNet restriction, Front Door / App Gateway with WAF, or private endpoint only, all at the Azure infrastructure layer.
Pathix is C# (.NET 10) and TypeScript. The codebase enforces nullable reference types, treat-warnings-as-errors and TypeScript strict mode across every project, with security-relevant analyzers in the CI gate.
AI can extend coverage by surfacing writers and readers that static parsing alone cannot resolve, for example custom code paths, dynamic field references and external integrations. Every dependency surfaced this way carries an AI-derived confidence level so reviewers can tell at a glance which edges came from deterministic analysis and which came from a model.
AI features require a customer-configured provider, Azure OpenAI, OpenAI or Anthropic. The vendor never proxies, brokers or stores AI provider credentials.
Deterministic analysis runs at full fidelity without AI. With AI enabled, the platform also surfaces AI-derived writers and readers that static parsing alone cannot resolve.
Any writer or reader sourced from an AI sweep is tagged with an AI-derived confidence level in the trace, so reviewers can separate model-derived edges from deterministic ones.
In 1.0, Pathix transmits no telemetry by default: license validation is offline by default, error reporting is customer-initiated, and usage telemetry is not yet collected. The posture below covers three categories, each governed by a distinct policy. The complete catalog of every event Pathix is capable of emitting is generated from source code, so the documentation cannot drift from implementation.
Validated locally by a cryptographic signature check with no network call by default. Optional online validation, for renewal hints only, sends a minimal entitlement payload (license token, tenant identifier, version, timestamp) and no usage, customer, or findings data.
Not collected in Pathix 1.0. Planned post-1.0 as opt-in mandatory: feature identifiers, scan durations, bucketed counts, error classes. Never names or record data.
The customer generates a local log export and emails it to support; nothing is transmitted automatically. An opt-in, default-off sanitized flow is planned post-1.0.
Compliance posture is determined principally by two factors: the metadata-only boundary and customer-hosted deployment. These two architectural commitments dramatically narrow the regulatory scope of the platform itself, while preserving your ability to satisfy regulatory requirements in your broader environment.
Because Pathix is customer-hosted, the responsibility model differs from a typical SaaS engagement. The matrix below clarifies the division.
Suspected vulnerabilities reach security@pathix.app. Reports are acknowledged within two business days and triaged within five. Critical findings ship patched releases within fifteen calendar days of validated discovery.
New runtime dependencies require explicit approval. The full set is enumerated in source-controlled package manifests with automated vulnerability scanning. A complete CycloneDX SBOM is generated for every release and is available on request, typically as part of an evaluation.
Pathix runs in your subscription, so incidents are first your incident under your IR procedures. The vendor coordinates on disclosure-attributable findings: validation, software remediation, and cross-customer notification when relevant.
Bring your security questionnaire. We will answer it against the actual code paths and the Bicep template.