Security Policy

ClaraOP uses technical and organisational safeguards designed to protect account, business, financial and integration data.

This page provides an overview of the security controls currently used by ClaraOP. It is intended to describe our current security practices and should be read together with our Privacy Policy.

For security questions, contact: support@claraop.com

ClaraOP's security approach is based on:

• limiting access to information according to role and operational need;
• protecting sensitive credentials and financial information;
• encrypting sensitive information where appropriate;
• minimizing the amount of Gmail data retained;
• separating secrets from application code and browser-accessible content;
• revoking credentials when integrations are disconnected;
• logging sensitive administrative access;
• maintaining controls around account deletion and data retention.

No internet-based service can guarantee absolute security.

ClaraOP uses HTTPS for communication between users and the Service.

Sensitive information transmitted between ClaraOP and third-party services is sent over encrypted network connections supported by those providers.

HTTP traffic is redirected or restricted in favor of secure HTTPS connections where supported by the deployed infrastructure.

ClaraOP applies additional protection to sensitive information stored by the application.

Financial information

Sensitive bank and payout information is stored using application-layer authenticated encryption.

Plaintext bank account information is not intended to remain in normal application records after encryption.

Where business records need to display financial details, ClaraOP may retain masked values such as the last four digits rather than the complete account information.

Google OAuth credentials

Google OAuth access and refresh tokens used to maintain Gmail connections are stored encrypted at rest.

Google OAuth client secrets and other application secrets are stored server-side and are not stored in Gmail connection database records or exposed to the browser.

ClaraOP applies authentication controls intended to reduce unauthorized account access.

These include:

• password hashing rather than plaintext password storage;
• authenticated session tokens;
• login rate limiting;
• account and role checks on protected API operations;
• server-side storage of application credentials.

Users are responsible for keeping their passwords and account credentials confidential.

ClaraOP uses role-based access controls to limit what different users can see and do.

Roles may include:

• agency administrators;
• managers;
• creators;
• system administrators.

Permissions vary by role and by the organisation, creator or operational area to which the user has access.

For example, creator users do not receive unrestricted access to other creators' financial or operational information.

Administrative functionality is separately restricted.

When a user connects Gmail:

• ClaraOP requests only read-only Gmail access required for its Email Intake functionality;
• ClaraOP does not request permission to modify, compose or send Gmail messages;
• Google access and refresh tokens are stored encrypted;
• Google credentials remain server-side;
• raw Gmail message bodies and Gmail snippets are not persisted in ClaraOP's application database after processing;
• Gmail access can be disconnected through ClaraOP's integration controls.

When Gmail is disconnected, ClaraOP requests revocation of the Google authorization, removes stored authorization credentials associated with the connection and stops future Gmail access through that connection.

Users may also revoke ClaraOP directly through their Google Account security settings.

Structured campaign records that were previously created from Gmail information are not necessarily deleted merely because Gmail is disconnected. Those records can be managed separately or removed through account deletion in accordance with the Privacy Policy.

ClaraOP is designed to minimize the amount of Gmail content retained.

Gmail search and filtering are used to identify potential brand-deal communications.

Where message content is required for classification, it is processed temporarily and is not persisted as a raw email body after processing.

ClaraOP may retain limited information necessary to operate the Service, such as:

• sender;
• subject;
• message and thread identifiers;
• date;
• extracted campaign information.

ClaraOP does not persist Gmail snippets.

Gmail content used for campaign classification is processed on the backend rather than in the user's browser.

Relevant content may pass through ClaraOP's infrastructure and AI-processing providers, including Emergent and Anthropic, solely to provide the requested classification and extraction functionality.

API keys and AI-service credentials are maintained server-side and are not exposed through ClaraOP's frontend.

ClaraOP does not authorize Google Workspace API data to be used to train generalized or non-personalized AI or machine-learning models.

More information about AI processing is available in our Privacy Policy.

Production data access is restricted according to operational need.

System-administrator support sessions are time-limited and Gmail-derived content is hidden by default.

Where access to Gmail-derived information is required, ClaraOP requires an authorized reason such as:

• user-requested support;
• a security investigation; or
• a legal or compliance obligation.

Sensitive administrative access is recorded in ClaraOP's audit logs.

ClaraOP does not permit routine employee access to Gmail content.

ClaraOP records security-relevant and sensitive administrative activity where appropriate.

This includes certain actions involving:

• administrative support sessions;
• access to Gmail-derived information during authorized support activity;
• account and security operations;
• other sensitive administrative actions.

Audit logs are used for security investigation, operational support and accountability.

We do not claim that every individual read or every application action is logged.

ClaraOP may use analytics on its public, logged-out website pages.

Analytics are not loaded on authenticated ClaraOP application pages in a manner that collects Gmail-derived content.

Gmail content and Gmail-derived information are not intentionally sent to public-site analytics services.

ClaraOP applies retention controls to sensitive payout information.

Sensitive account-identifying payout information may be removed after it is no longer required for the relevant payout workflow.

Scheduled processes are used to apply retention rules to qualifying payout records.

Business-level records that are required for accounting, tax, operational or legal purposes may be retained after sensitive bank details have been removed.

The exact retention period applicable to information is described in the Privacy Policy and may depend on legal and operational requirements.

Account deletion is not merely a change to an account-status flag.

Once account deletion is confirmed, ClaraOP removes applicable account and personal data as part of the deletion process.

Depending on the type of account, this may include:

• Gmail connections;
• stored Google authorization credentials;
• Gmail-derived records;
• campaigns and campaign source information;
• account and membership information;
• other associated operational data.

Certain invoices, transaction records or similar information may be retained where required for tax, accounting, fraud-prevention or other lawful purposes.

Where such information is retained, Gmail-specific identifiers or links are removed where they are no longer necessary.

See the Privacy Policy for more detail.

Application credentials and encryption keys are maintained as server-side environment secrets.

They are not intended to be:

• stored in source-control repositories;
• exposed to browser-side JavaScript;
• returned in application APIs;
• written into user-facing application logs.

ClaraOP may rotate credentials where required for security or operational reasons.

ClaraOP maintains separate development/preview and production environments.

Production and preview use separate data environments, and production credentials are managed separately from development credentials where applicable.

Testing and development activities should not require production user credentials unless specifically necessary and authorized.

ClaraOP investigates suspected security incidents affecting the Service.

Depending on the nature of an incident, response activities may include:

• containing affected systems;
• revoking or rotating credentials;
• investigating affected accounts or data;
• remediating the underlying issue;
• notifying affected users where appropriate or legally required;
• notifying applicable regulators where required by law.

Notification timing depends on the nature of the incident and applicable legal requirements.

If you believe you have identified a security vulnerability in ClaraOP, please report it to: support@claraop.com

Please include:

• a description of the issue;
• steps to reproduce it where available;
• the affected page, endpoint or feature;
• any supporting screenshots or technical details;
• a contact address for follow-up.

Please avoid accessing, modifying or downloading data belonging to other users while investigating a suspected issue.

ClaraOP will review good-faith vulnerability reports and take appropriate action based on the severity and validity of the issue.

ClaraOP relies on third-party infrastructure and service providers to operate parts of the Service.

These may include:

• Emergent for application infrastructure and related services;
• Google for Gmail and OAuth functionality;
• Anthropic for AI processing;
• Resend for transactional email delivery;
• other providers described in the Privacy Policy.

Security of these services also depends on the controls maintained by those providers.

ClaraOP aims to use third-party services only where they are reasonably necessary to provide the Service.

ClaraOP's security and privacy controls are designed to support responsible handling of personal and business information.

ClaraOP is not currently representing that it holds certifications such as SOC 2 or ISO 27001 unless expressly stated otherwise.

Compliance obligations may vary depending on the user's jurisdiction, organisation and use of ClaraOP.

Customers remain responsible for determining whether ClaraOP meets any specific regulatory, contractual or internal security requirements applicable to their organisation.

We may update this Security Policy as ClaraOP's infrastructure, features and security practices evolve.

The most recent revision date will be displayed at the top of this page.

For security questions or vulnerability reports:

ClaraOP

Email: support@claraop.com

Website: claraop.com