Enterprise security questions, answered.

Klarv requests three OAuth scopes: api, refresh_token, and offline_access.

The api scope grants access to the Salesforce Tooling and Metadata APIs for reading automation definitions. The refresh and offline access scopes enable long-lived sessions without requiring repeated logins.

Klarv only performs read operations. We never create, update, or delete any data in your Salesforce org.

These same scopes are used for both production and sandbox orgs.

Klarv primarily uses the Tooling API and Metadata API for automation analysis.

Through the Tooling API, we query: Flows, Validation Rules, Apex Triggers, Assignment Rules, Escalation Rules, and Auto-Response Rules. The Metadata API is used for retrieving scheduled flow path definitions.

For Process Analytics: We also query field history objects (e.g., OpportunityFieldHistory, CaseHistory) to analyze how records transition through stages. This data contains stage values and timestamps, not customer personal information.

We do not query Account, Contact, Lead, or Opportunity record data fields like names, emails, or amounts.

For automation analysis: No. We analyze automation metadata only (Flow definitions, trigger code, validation rules). We extract field names referenced in automations, not field values.

For Process Analytics: We read field history records to analyze stage transitions. This includes record IDs, stage values (e.g., "Closed Won"), and timestamps. We do not read or store customer personal information such as names, contact details, or financial data.

Yes. Revoking access in Salesforce Setup immediately invalidates the OAuth tokens. Any subsequent API calls from Klarv will fail authentication.

You can also disconnect your org directly from within Klarv, which will revoke the token on the Salesforce side and delete all stored data from our systems.

OAuth tokens are encrypted at rest using AES-256-GCM (Galois/Counter Mode) before being stored in our PostgreSQL database.

Each encrypted value includes a randomly generated initialization vector (IV) and authentication tag, ensuring both confidentiality and integrity. Tokens are decrypted in-memory only when needed for API calls and are never persisted in plaintext.

No. OAuth tokens are never logged in plaintext. Our logging infrastructure separates development and production modes, verbose debug logging is suppressed in production environments.

Error handlers log error objects and context, but never include token values. JWT session tokens are stored in HTTP-only cookies and are not exposed to application logs.

Our audit logs (stored in the database) capture: event type, actor type and ID, org ID, IP address, user agent, and contextual metadata. This enables security monitoring and troubleshooting.

Production application logs contain only error messages; no sensitive data, tokens, or customer record information. Development logs are more verbose but are never enabled in production.

OAuth tokens are always encrypted before database storage and are never included in logs. For caching and deduplication, we use SHA-256 hashing for identifiers.

Automation names and field names from your org's metadata may appear in analysis results and logs, but these are configuration metadata – not customer record data.

Database audit logs are retained for operational and security monitoring purposes. Application logs follow our hosting provider's standard retention policies (typically 30 days for Vercel).

Yes, data is strictly isolated per Salesforce org. Every record is linked to a specific org, and all database queries enforce org-level filtering to ensure you only ever see your own data.

Session validation confirms org ownership before any data access. Deleting an org cascades to remove all associated automation data, field references, and analysis results.

Internal administrative access is protected by password plus TOTP-based two-factor authentication. Failed login attempts are rate-limited (5 attempts triggers a 15-minute lockout).

All administrative actions; including logins, logouts, and data modifications – are recorded in the audit log with timestamps, IP addresses, and user agents.

Yes. Administrative access requires both a password and a time-based one-time password (TOTP) code. Both factors must be validated before a session is created.

Klarv is hosted on US-based infrastructure:

• Application hosting: Vercel (US regions)
• Database: Neon (PostgreSQL, US regions)
• AI analysis: Anthropic Claude API (for AI-powered insights)

All subprocessors maintain SOC 2 compliance and follow industry-standard security practices.

Klarv enforces comprehensive security headers including:

• HSTS (HTTP Strict Transport Security)
• Content Security Policy (CSP)
• X-Frame-Options to prevent clickjacking
• Strict referrer policies
• CSRF token validation on mutating endpoints

In the event of a security incident affecting customer data, we commit to notifying affected customers within 72 hours of confirmed impact via the email address associated with their account.

Notifications will include: nature of the incident, data potentially affected, steps we're taking to remediate, and recommended actions for customers.

Yes. For security concerns or to report vulnerabilities, contact us at security@klarv.io.

We welcome responsible disclosure and aim to acknowledge reports within 48 hours. Our security.txt file is available at /.well-known/security.txt.