Security at LemonLime

This page describes how LemonLime AI Inc.(doing business as “LemonLime,” “we,” “us,” or “our”) protects the data our Customers entrust to us and the security practices behind the Services. It is written for the security, IT, and procurement teams who evaluate LemonLime, and it complements our Privacy Policy and Terms.

LemonLime is a knowledge platform: a Customer connects its authorized tools, LemonLime indexes the Customer’s own content to power search and AI answers, and — where the Customer enables it — LemonLime’s AI agents act in those tools on an authorized user’s behalf. Because the Services sit on top of a company’s most sensitive knowledge and can act within its systems, security and least privilege are foundational to how we build.

Contents

1. Our approach to security
2. Encryption
3. Access control and authentication
4. Application and infrastructure security
5. Vulnerability management and penetration testing
6. Logging, monitoring, and detection
7. Incident response and breach notification
8. Integrations, scopes, and agent actions
9. AI, your data, and model providers
10. Data hosting, retention, and deletion
11. Subprocessors
12. Privacy and compliance
13. Business continuity and disaster recovery
14. Reporting a security issue

1. Our Approach to Security

We design the Services to be secure by default and to follow the principle of least privilege at every layer — in the scopes we request from connected tools, in the access our employees have to Customer data, and in what our AI agents are permitted to do. Our security program is informed by widely recognized frameworks, including SOC 2 and the OWASP Application Security Verification Standard, and we operate a documented set of policies covering access control, secure development, vulnerability management, incident response, vendor management, and data retention.

No security program is perfect, and no system can be guaranteed invulnerable. We focus on defense in depth, rapid detection and response, and continuous improvement, and we are transparent with Customers about how their data is handled.

2. Encryption

2.1 In transit

All data transmitted between you, the Services, and the third-party tools you connect is encrypted using TLS 1.2 or higher. We disable legacy protocols (TLS 1.0 and 1.1) and use HTTP Strict Transport Security on our web properties.

2.2 At rest

Customer Data — including indexed content, derived search embeddings, operational metadata, and backups — is encrypted at rest using AES-256. Encryption keys are managed in a dedicated key-management service, access to keys is controlled separately from access to data, and keys are rotated.

3. Access Control and Authentication

• Multi-factor authentication. MFA is required for employee access to production systems, cloud-provider consoles, administrative tooling, and source-code repositories.
• Least privilege and role-based access. Access to Customer Data and infrastructure is granted on a need-to-know, role-based basis, approved, and reviewed on a recurring schedule; access is revoked promptly upon role change or departure.
• Strong authentication for the Services. We protect authentication surfaces with rate limiting and brute-force protections. We do not use shared or default credentials.
• Restricted human access to Customer content. Our personnel do not access the contents of your Customer Data except where you have authorized it, where necessary to provide support you request, to investigate a security issue or abuse, or to comply with law — and such access is logged.

4. Application and Infrastructure Security

We host the Services on leading cloud infrastructure providers, inheriting their physical and environmental security and certifications. Production environments are logically separated from development and test environments, and we do not use production Customer Data in lower environments.

• Secure development. We follow a documented secure software development lifecycle aligned to OWASP guidance, require peer code review before changes are merged, protect our repositories with MFA, and gate releases through change control.
• Dependency and configuration management. We scan dependencies for known vulnerabilities, manage secrets in a dedicated vault rather than in code, and review security configurations.
• Network controls. Production networks use default-deny boundary controls, with ingress limited to required services and rules reviewed periodically.

5. Vulnerability Management and Penetration Testing

We engage Oneleet, our security and compliance partner, to conduct penetration testing of the Services, and we run regular internal and external vulnerability scanning. Findings are risk-ranked and remediated within target timeframes based on severity (for example, critical issues on an expedited basis), and material findings are retested after remediation.

If you are a security researcher and believe you have found a vulnerability, please see Reporting a security issue below. We appreciate good-faith disclosure and will work with you in good faith.

6. Logging, Monitoring, and Detection

We log security-relevant events across authentication, privileged actions, data access, and — importantly for our agent features — the actions our AI agents take on a user’s behalf. Logs are retained for a defined period, monitored, and used to alert on anomalous or high-risk activity. These records also support audit, investigation, and the Customer-facing activity history described in Section 8.

7. Incident Response and Breach Notification

We maintain a documented incident-response plan with defined roles, severity levels, and communication procedures, and we review and exercise it. In the event of a security incident affecting Customer Data, we will investigate, contain, and remediate, and we will notify affected Customers without undue delay and consistent with our contractual and legal obligations — including, where the GDPR applies, notification within 72 hours of becoming aware of a reportable personal-data breach. Where an integration partner requires direct notification of incidents involving its platform data, we will provide it.

8. Integrations, Scopes, and Agent Actions

8.1 Least-privilege scopes

When you connect a tool, LemonLime requests only the OAuth scopes needed for the capabilities you enable: read scopes to index your content for search and answers, and write or action scopes only for the agent capabilities you engage.

8.2 Permission-aware access

LemonLime respects the access controls of the source tool. Search results and answers surface only content the asking user is already permitted to see, and agent actions are limited to what that user is already permitted to do. We do not use the Services to grant a user access — or the ability to act — beyond their existing permissions in the connected tool, and one Customer’s data is never used to serve another.

8.3 Agent actions

Where a Customer enables agent capabilities, LemonLime can perform actions an authorized user requests in a connected tool — for example, drafting and sending an email, creating or updating a calendar event, posting a message, creating and uploading files, or updating a record. These actions:

• are taken on the authenticated user’s behalf, within the permissions that user granted;
• are constrained to what the user requests and never exceed the user’s instructions;
• are audit-logged, so administrators can review what was done, when, and on whose behalf;
• are subject to confirmation or human review for higher-impact operations, where configured by the Customer; and
• can be scoped and disabled by administrators at any time, including limiting which tools, channels, or actions agents may use.

8.4 Credential and token security

OAuth access and refresh tokens are stored encrypted in isolated credential storage, scoped to the relevant Customer, never written to logs, and revoked when an integration is disconnected.

9. AI, Your Data, and Model Providers

• No training on your data. LemonLime does not train, fine-tune, or improve any model — our own, shared, or foundational — on Customer Data, in identifiable, de-identified, or aggregated form.
• You choose the model. Customers may choose to select which third-party model provider powers their agents and can change it. We route Customer Data only to providers via respective commercial or API tiers configured not to train on inputs, and we maintain the current list of model subprocessors in our Privacy Policy.
• Minimized, just-in-time. When generating an answer or performing an action, we send only the relevant content needed to a model provider at the time of the request. Where a provider offers a zero-retention option, we make this available for Customers with sensitive sources and data.
• Slack (for applicable Customers). Consistent with Slack’s API Terms, content from Slack is accessed in real time to serve a request and is never persistently stored or indexed.
• Responsible, accountable AI. AI output can be imperfect; we cite sources so it can be verified, we keep humans in control of consequential actions (Section 8.3), and we log agent activity so it is reviewable.

10. Data Hosting, Retention, and Deletion

We host and process Customer Data on the cloud infrastructure described in Section 4. Each Customer’s data is logically isolated from every other Customer’s.

We retain indexed content only while the relevant integration and account remain active. When you disconnect an integration or close your account, we no longer access the associated source content, derived embeddings, and caches from our active systems, and purge copies from encrypted backups on our standard rotation. You may also request access to, correction of, or deletion of your data as described in our Privacy Policy. (Because we do not persistently store Slack content, there is no Slack message or file data to remove on uninstall — only access tokens and any transient operational data.)

11. Subprocessors

We use a limited set of vetted subprocessors — including cloud hosting providers, intelligence model providers, and operational tooling — each engaged under data-protection terms and assessed through our vendor-management process. The current list, and the categories of data each may process, is maintained in our Privacy Policy.

12. Privacy and Compliance

Our handling of personal information is described in our Privacy Policy, which addresses the GDPR, the CCPA/CPRA, and other applicable laws, including data-subject rights and international-transfer safeguards. We are completing a SOC 2 examination with the support of Oneleet, and we will make our current report available to Customers and prospective Customers under NDA when it is issued. For Customers who require it, we offer a Data Processing Addendum.

13. Business Continuity and Disaster Recovery

We maintain documented business-continuity and disaster-recovery plans, including automated, encrypted backups and a defined restore strategy, and we review and test our recovery procedures.

14. Reporting a Security Issue

We welcome reports from Customers and security researchers. If you believe you have found a vulnerability or have a security concern, please contact us — we aim to acknowledge reports promptly and to work with reporters in good faith. Please do not publicly disclose an issue before we have had a reasonable opportunity to address it.