Terms & Conditions
By deploying PAM-Pro, you acknowledge the absolute constraints of true Zero-Knowledge infrastructure. Our security model relies on strict separation of duties and geometric isolation. Please read the following operational liabilities carefully.
Irrevocable Data Loss - Two-Component Key Architecture
PAM-Pro enforces strict cryptographic isolation via a two-component key model. Your vault encryption depends on two independent elements that must both remain intact:
- 1.Your Vault Key (Tenant Root Secret - TRS): Entered by your administrator during setup. This is the customer-held component. Huntoso does not retain a copy outside your dedicated Key Vault. You are solely responsible for backing this up externally.
- 2.Your Dedicated Azure Key Vault: Contains the server-generated Tenant Root Key (TRK) stored only as AES-256-GCM ciphertext. This is protected by Huntoso's 99.9% infrastructure SLA under normal operations, but Customer-initiated deletion constitutes an irrecoverable loss event.
Neither component alone is sufficient for vault access. Huntoso engineers have no standing access to your Key Vault - any access would require an explicit, auditable role assignment visible in Azure Activity Logs.
WARNING: If your Vault Key (TRS) is lost, or your dedicated Azure Key Vault is deleted and purged, your vault is permanently and irrecoverably inaccessible. No Huntoso intervention, court order, or technical effort can restore it. Additionally, rotating the Tenant Root Key (TRK) via settings triggers a mandatory tenant-wide credential reset - all managed passwords are immediately invalidated and re-rotated.
Zero Out-of-Band Disasters (Microsoft SLA Reliance)
To maintain absolute identity sovereignty, PAM-Pro integrates exclusively with your sovereign Microsoft Entra ID tenant. We deliberately do not store local "Break-Glass" credentials on Huntoso infrastructure.
Consequently, if Microsoft Entra ID experiences a global outage or your tenant becomes inaccessible, PAM-Pro access is entirely suspended. The identity of your secrets remains with you, and your uptime SLA is strictly bound to Microsoft's availability.
Audit Log Retention and Immutability
PAM-Pro stores all privileged access audit logs in your dedicated Azure Storage account - isolated from all other customers. Each customer's audit trail is entirely separate and subject only to that customer's own access controls.
Customers can enable WORM (Write Once, Read Many) immutability via the Setup Wizard Scoreboard. Once an immutability policy is locked, no party - including Huntoso and Microsoft - can delete or modify audit log blobs within the retention period. This is enforced at the Azure Storage service layer, independent of PAM-Pro application logic.
Note: while a WORM retention policy is active, account closure will not result in deletion of retained audit data until the policy expires. Huntoso assumes no liability for historical logs beyond the rolling retention window, and customers are responsible for configuring retention to meet their compliance obligations.
Per-Customer Data Isolation
Every PAM-Pro customer receives dedicated, isolated Azure infrastructure. Your managed account credentials are stored in a Key Vault that belongs exclusively to your deployment. Azure RBAC is enforced at the vault boundary - no other customer's identity has any access path to your Key Vault or Storage Account.
Account secret names in your Key Vault are derived via HMAC-SHA256 keyed on your Tenant Root Key - account usernames and UPNs are never stored as readable labels. An attacker with Key Vault access cannot determine which secret belongs to which account without also holding the decrypted TRK.
Architecture note: PAM-Pro limits each shared compute instance to a maximum of 15 customer deployments. A compute-level breach affects at most 15 customers - not the entire platform population. This is a deliberate blast-radius containment design.
Mandatory Disclosure Repository
The following disclosures are mandatory components of the Huntoso onboarding flow. All stakeholders must acknowledge these constraints prior to vault provisioning.