Trust center

Cortee is built on trust and transparency to protect your data. Here you’ll find how we secure it, and how we handle it.

Security controls

Last scanned 5 hours ago.

A person writes these controls and keeps them up to date. Agents check them against evidence. The mark on the right means that check passed. If you want to see detailed evidence for each security control, please contact us at security@cortee.ai. We may share it with you after a signed NDA.

AI Governance

  • No training on customer data

    Customer notes and pages are not added to a training set, a fine-tune, or examples used to rewrite prompts. They are used only for the job the customer submitted. The provider that runs the model is under the same rule, and its contract forbids training and fine-tuning on that content.

  • Inference only on an explicit request

    A model runs only when a person asks for it. They submit a note, upload an attachment, search, or change a page's language or tone. No model runs on a schedule.

  • Only the context a request needs

    A request sends the note and the page that note is meant to change. The rest of the workspace is not included.

  • User permissions

    The model acts with the signed-in user's authentication. Before a write, the product runs the same authorization it uses when that person edits the page themselves. A prompt cannot skip that check or open a record the user cannot open.

  • Prompt injection

    The product keeps an automated suite of prompt-injection attacks and runs it against the prompts. On a live request, one model drafts the edit the user asked for, and a second model checks that the edit is safe to apply. The edit is applied only when that check passes.

  • Tested prompt and model changes

    A new prompt or a new model does not ship until the automated tests have run. The tests have to show that accuracy and performance held or improved, and the injection suite has to pass. A change that fails either one stays off the product.

  • Versioned prompts and models

    Prompts, models, and model settings are kept in version control. Any of them can be put back to an earlier version within a short time.

  • Temperature set to 0

    Generations that decide something use temperature 0. Classifying a note, detecting the page language, extracting claims, assigning claims, and applying an instruction all send temperature 0, so the model is not asked to sample among alternatives for those decisions.

  • AI provider review

    Before customer data goes to a new AI provider, the contract is read for two things. It has to forbid training and fine-tuning on customer content. It also has to say whether the provider keeps prompts after the request, and for how long.

  • Decision trace

    Each action stores the path the model took, step by step, from the request to the edit. That record does not include the note or the page. The recorded decision is what gets applied, so the edit matches the trace.

Encryption and key management

  • Encryption in transit

    Data is encrypted with TLS 1.2 or newer on the way between a client and the application, between the application and the database, and between the application and the model provider. That stops the data from being read or changed while it is on the way.

  • Encryption at rest

    Customer data in database tables and static attachments, and the backups of both, is encrypted at rest with keys managed in the account that runs the product. Those keys are not issued one per customer.

  • Key access restricted

    Privileged access to those encryption keys is limited to authorized people, and only for the work that needs the key.

  • Encryption audit trail

    Encryption operations are logged. The log covers key generation, key access, and administrative actions on critical production systems.

  • Password hashing

    Clerk, the authentication provider, hashes customer passwords with bcrypt. Bcrypt is a one-way hash, and each hash has its own salt, so two identical passwords do not produce the same hash.

Access control and authentication

  • Signed third-party events

    Events from Clerk and Paddle are accepted only when their signature checks. Both use HMAC-SHA256 and a constant-time compare, and both reject a timestamp older or newer than five minutes. Clerk signs the event id, the timestamp, and the raw body. Paddle signs the timestamp and the raw body. A request that fails the check is rejected before any organization or subscription record is touched.

  • Public APIs and customer data

    The public catalog does not carry a person's access token. Its IAM policy cannot read or write customer data. It can read the plan catalog and nothing in the database.

  • Organization scoped access

    A request that reads or writes a customer's pages, notes, or attachments carries that person's access token. The token assumes an organization-level IAM policy, and the policy allows only the operation that endpoint needs for that organization. A request cannot read data that belongs to another organization.

  • Logical isolation

    Every database table is partitioned by organization. Pages, notes, claims, and attachments use that organization's partition. Organization, subscription, and entitlement rows use the organization id as their partition key. An IAM policy allows a request to touch only its own partition, so organizations are separated in the data and in the policy.

  • Least privilege

    Each microservice has its own IAM policies. The signed-in person assumes those policies through their access token, scoped to their organization. That microservice can reach only the tables and operations it needs, and only inside that organization's partition.

  • Single Sign On

    All users may log in using their Google and GitHub credentials as an SSO provider.

  • Multi-factor authentication

    Two-step verification is available on every plan. A person can use an authenticator app (TOTP), a passkey with biometrics, or a one-time code sent by email. Requiring it for a workspace is done by contacting customer support.

  • Sign-in sessions

    A person can see where they signed in, when they signed in, and which computers they used. They can also see which of those sessions are still active, and they can sign out of all sessions themselves.

  • Role-based access

    Every organization can assign Admin or Member in a team space. View-Only is available on specific plans. Admins manage payments, the subscription, invoices, organization details, and members. They can also do everything a member can do. Members create, update, and delete pages, including notes and attachments. View-only members can read pages, references, and attachments, and they can search. They cannot change anything.

  • Automated user provisioning

    Enterprise customers can request SCIM. It creates and removes users and groups from their identity provider. A person removed through SCIM loses access within 60 seconds.

Incidents and recovery

  • Backups

    Point-in-time recovery is available for database tables.

  • Infrastructure as code

    Infrastructure is created from code. In a disaster it can be deployed again in a new location.

  • Disaster recovery plan

    A disaster recovery plan says how critical systems keep running and how data is restored.

  • Breach notification

    Within 72 hours after Cortee becomes aware of a security breach, the affected customer is notified. The incident is published on the security page under Updates.

  • Incident response plan

    An incident response plan says how an incident is handled.

  • Post-incident review

    After an incident, the review records what has to change so the same incident does not happen again.

  • Practiced recovery

    Recovery and incident response are practiced.

Secure development

  • Infrastructure changes

    Application code and infrastructure changes are kept apart. Infrastructure is planned, reviewed, and applied by a person. No AI system plans, reviews, or applies an infrastructure change.

  • Agents do not change infrastructure

    Agents do not create infrastructure and do not change IAM policies, unless a person has defined the change and reviewed it.

  • Vulnerability audits

    A vulnerability audit runs on every deploy and once a day. Dependencies are scanned automatically. The application is scanned by reviewing every change before it reaches production. Every finding is reviewed. A deploy cannot go out while the code has a vulnerability.

  • Reporting vulnerabilities

    Anyone may report a vulnerability they have found by sending it to security@cortee.ai. Reports are processed manually. High and critical vulnerabilities are answered within a short time.

  • Secure coding training

    Developers have to take OWASP secure coding training.

Network and infrastructure security

  • Abuse monitoring

    Monitoring is in place to detect abusive behavior and attacks.

  • Malware detection

    Customer-uploaded attachments are scanned for malware. An attachment cannot be viewed, downloaded, or modified until that threat assessment is done. Until then, no language model, no internal system, and no user can access the uploaded data.

Change management

  • Pre-production testing

    Changes are tested in pre-production before they reach production.

  • Automated and agentic testing

    Changes go through automated testing and agentic testing.

  • Environment segregation

    Environments are segregated from each other. Production data is never copied into testing.

  • Human review

    A change does not ship until a person has reviewed it.

  • Rollback

    Every change can be rolled back.