FAQ: Security & Compliance

Do you support compliance standards?

Yes. Veriprompt supports configurable checks for HIPAA, SOC2, GDPR, FINRA, and more depending on plan.

How do you prevent prompt injection?

The security layer scans inputs and can block suspicious content before execution. See Security DMZ Layer for details.

Is my personal data encrypted?

Yes. All personally identifiable information (PII) is encrypted at rest in the database using AES-256-GCM authenticated encryption. This includes:

• User data: email, first name, last name, display name, job title
• Company data: email, phone, address, city, postal code, country, tax ID, VAT number, billing email, billing address

Each field is individually encrypted with a unique salt and initialization vector. Email lookups use a separate HMAC-SHA256 hash so that login and search work without decrypting every row.

Are prompts and logs encrypted?

Prompt payloads processed through the AI Gateway are encrypted in transit (TLS) and can be encrypted at rest using Zero-Knowledge Encryption. When enabled, prompts are encrypted client-side before transmission — Veriprompt never sees the plaintext. See the Zero-Knowledge Encryption guide for setup instructions and the API reference for endpoint details.

Can I bring my own provider keys?

Yes. BYOK (Bring Your Own Key) is supported. Your API keys are stored encrypted and never leave your tenant boundary. See BYOK for setup instructions.

How is the encryption key managed?

The encryption key (DATABASE_ENCRYPTION_KEY) is a 256-bit secret set as an environment variable. It is never stored in the database or committed to source control. All encryption and decryption happens server-side in memory.

Can I request data deletion?

Yes. Veriprompt supports GDPR-compliant data erasure. Contact your account administrator or use the admin panel to trigger participant data deletion. Encrypted PII is permanently destroyed when deleted.

Do you support Multi-Factor Authentication (MFA)?

Yes. VeriPrompt supports TOTP-based two-factor authentication (the same standard used by Google, GitHub, and AWS). You can enable it in your profile settings using any authenticator app — Google Authenticator, Authy, Microsoft Authenticator, 1Password, or Bitwarden.

When MFA is enabled, you will need to enter a 6-digit code from your authenticator app after your password each time you sign in. See the Multi-Factor Authentication guide for setup instructions.

What if I lose access to my authenticator app?

Contact your company administrator — they can disable MFA on your account from the admin panel. If you are a solo account owner, contact VeriPrompt support. We recommend using an authenticator app with cloud backup (like Authy or 1Password) to avoid lockouts.

Can my company require MFA for all users?

Company-level MFA enforcement is on our roadmap. Currently, MFA is enabled on a per-user basis. We recommend that all admin and account owner accounts enable MFA.

Do you support enterprise single sign-on?

Yes. Enterprise SSO supports OpenID Connect and SAML 2.0 connectors per company, with DNS-verified email domains for sign-in discovery, identity-provider group → role mapping, and SCIM 2.0 provisioning for automatic joiner/leaver handling. Microsoft Entra ID and Okta are both documented end to end. See the Enterprise SSO guide.

SSO is a package feature and is off unless it is explicitly enabled on your plan.

Does MFA apply to SSO logins?

No — and this is deliberate. SSO logins never enter Veriprompt's password or TOTP code paths, so multi-factor enforcement for SSO users is your identity provider's responsibility (Conditional Access in Entra, sign-on policies in Okta). Veriprompt's own TOTP MFA continues to apply to password sign-in. Turn on IdP-side MFA before you enforce SSO, otherwise you are weakening your posture compared with password + Veriprompt TOTP.

What happens if our identity provider is compromised?

Veriprompt support can force-disable every SSO connector for your company. New SSO logins stop immediately, existing SSO sessions end within about five minutes, and everyone falls back to password sign-in. Re-enabling is your own deliberate action once the identity provider is fixed. Account owners are never subject to SSO enforcement, and enforcement can only be switched on while an owner still has a working password — so a password path into your tenant always exists.

Are login attempts protected against brute force?

Yes. Login attempts are rate-limited to 5 per email address per 15 minutes. Exceeding this limit blocks further attempts for 15 minutes. This protects against automated credential-stuffing and brute-force attacks.

How long do sessions last?

Sessions expire after 8 hours of inactivity. Each user is limited to 2 concurrent active sessions. Expired sessions are automatically cleaned up. If you need to invalidate all sessions immediately (e.g. after a security incident), contact your account administrator.

What security headers does Veriprompt set?

Every response from Veriprompt includes industry-standard security headers:

Header	Purpose
X-Content-Type-Options: nosniff	Prevents MIME-type sniffing
X-Frame-Options: DENY	Blocks clickjacking via iframes
X-XSS-Protection: 1; mode=block	Browser XSS filter
Referrer-Policy: strict-origin-when-cross-origin	Controls referrer information leakage
Permissions-Policy	Disables camera, microphone, geolocation access
Strict-Transport-Security	Enforces HTTPS-only connections (API)

Is there an audit trail?

Yes. Significant security events are recorded to an immutable audit log, including:

• Successful and failed login attempts
• Password changes
• API key creation and deletion
• Admin impersonation sessions (start and all actions)
• Data exports (analytics, prompts)
• Role and permission changes

Audit logs are accessible to Account Owners, Admins, and Security Custodians in the admin panel. Governance and access-review screens can also open filtered audit or prompt-log drill-downs with the relevant user, API key, routing policy, and date window preselected.

How are API tokens generated?

All API tokens and session secrets are generated using cryptographically secure random bytes (crypto.randomBytes) — never Math.random(). Tokens are hashed before storage; the raw value is shown only once at creation time.