Effective 15 September 2026
Privacy Policy
Your business data belongs to you. It is not sold, not used to train AI models, and not accessed by me except on your instruction or where necessary to keep the service running — and where that happens, it is recorded in an audit trail that cannot be suppressed. You may export everything, or have it permanently deleted, at any time.
1. Who I am
KesherSuite is operated by Yong Xiancong, an individual sole operator based in Singapore, trading as KesherSuite ("KesherSuite", "I", "me"). I am the data controller for personal data processed through the KesherSuite website and application, and I am the person responsible for data protection compliance, including the functions of a Data Protection Officer under Singapore's Personal Data Protection Act 2012 (PDPA). KesherSuite is not an incorporated company; if that changes, this section will name the company and the effective date above will change.
Contact for any privacy question, request or complaint:xc.keshersuite@gmail.com
2. Scope
This policy covers the KesherSuite marketing website (keshersuite.com) and the KesherSuite application (app.keshersuite.com). It is written to comply with the PDPA and, where it applies to you, the EU and UK General Data Protection Regulation (GDPR).
2.1 Two roles
KesherSuite lets you build applications that hold your own records. Two kinds of personal data are involved, and they are handled differently:
- Account data — your name, email, and how you use the platform. For this I am the controller: I determine why and how it is processed, and this policy governs it.
- Your content — the records you and your team put into the applications you build, which may include personal data about your own customers or staff. For this I am the processor: you determine what is collected and why, I store and process it on your instructions, and it is used for no purpose of my own. You remain responsible for having a lawful basis to collect it and for giving notice to the people it concerns.
3. What I collect
3.1 On account creation
- Your email address and name
- A bcrypt hash of your password. The password itself is not stored and cannot be retrieved
- Your organisation's name and, optionally, profile details you enter
- Where you sign in with Google or Microsoft: your email, name and provider account identifier, received from that provider
- Where you enable two-factor authentication: a TOTP secret and hashed backup codes
3.2 In use of the application
- Your content — the application configurations you build and every record stored in them
- Audit and activity records — who changed what and when, including a correlation identifier per request. This is a security control and is retained deliberately
- Usage metering — counts of AI tokens consumed, rows written, storage used and similar, so that plan limits and billing can be enforced
- Authentication events — sign-ins, sign-in failures, lockouts, password resets and session revocations, with IP address
- Technical logs — request paths, status codes, timing and error traces
3.3 On the website
The marketing site sets no cookies. There are no advertising cookies, no cross-site tracking, and no third-party analytics service. The application sets a session cookie and a CSRF token cookie, both strictly necessary to sign in and stay signed in; the session cookie is HttpOnly and cannot be read by scripts in your browser.
The marketing site measures how its own pages are used. That measurement is first-party and minimal. It records the page, scroll depth, which sections were reached, which links were clicked, approximate time on page as a band rather than a precise figure, the referring site, and the browser's user-agent string.
There is no cookie, no browser storage, and no identifier of any kind, so no two events can be linked to one another. There is no session, no profile, and no means of following a person across the site or recognising them on a later visit. Nothing is shared with a third party, because no third party is involved: the measurements are written to the web server's own logs, which already record every request to the site, and are kept for up to two years to allow period-on-period comparison. Where a browser sends a Global Privacy Control signal, nothing is recorded.
4. Purposes and lawful bases
| Purpose | Data | Lawful basis (GDPR) |
|---|---|---|
| Providing the service you signed up for | Account data, your content | Performance of a contract |
| Authenticating you and keeping accounts secure | Credentials, auth events, IP | Performance of a contract; legitimate interests (security) |
| Detecting and preventing abuse | Auth events, usage metering, IP | Legitimate interests (protecting the service) |
| Enforcing plan limits and billing you | Usage metering, billing details | Performance of a contract; legal obligation (tax records) |
| Service email — verification, password reset, security alerts | Email address | Performance of a contract |
| Answering your support requests | The content of your request | Performance of a contract; legitimate interests |
Under the PDPA, the corresponding bases are the consent you give at signup and the exceptions in the First and Second Schedules covering personal data necessary to provide a service you have requested. Consistent with the PDPA's Retention Limitation Obligation, personal data is not kept for longer than is necessary for the purpose it was collected for, or for a legal or business purpose that still applies. Retention periods are set out in section 7.
5. What I do not do
- Your data is not sold, in any form, to any party.
- Your content is not used to train AI models, by me or by the providers I use. See section 6.
- Your content is not used for advertising and is not shared with advertisers.
- Your content is not read casually. Support personnel, currently myself alone, have no standing access to the records inside your applications. Emergency access to diagnose a fault goes through a break-glass mechanism that requires a written reason, expires automatically after 15 minutes, is re-verified on every request during that window, and writes an audit record that cannot be suppressed.
6. Artificial intelligence
KesherSuite uses large language models to turn a plain-language description into an application configuration, and to power the agents you configure. Some of your data is therefore sent to an AI provider for processing.
- What is sent: the instructions you type, your application's configuration document, and, only where you have explicitly directed an agent at a record or attached a file, the contents of that record or file.
- Where it goes: Anthropic and OpenAI, named in thesubprocessor list.
- Training: I do not use your content to train any model. Both providers state that data submitted through their business APIs is not used to train their models. That commitment is theirs, made in their own terms, which are linked from the subprocessor list.
- Your own provider account: you may connect your own Anthropic or OpenAI account, in which case AI requests are billed to that account and governed by your agreement with that provider rather than mine.
The AI agent does not change your application on its own. It proposes a change in plain language, and a person on your side approves it before anything is applied. This is an architectural property of the system rather than a setting.
7. Where your data is held, and for how long
All application data is hosted on Google Cloud Platform in theasia-southeast1 region (Singapore). Database backups are held in the same region.
Some subprocessors process data outside Singapore — the AI providers, the email provider and the payment processor all operate from the United States. Consistent with the PDPA's Transfer Limitation Obligation, each is bound by contractual terms requiring a standard of protection comparable to the PDPA. Where personal data of individuals in the EU or UK is transferred, those transfers rely on the Standard Contractual Clauses incorporated into each provider's own data processing terms.
| Data | Retention |
|---|---|
| Records you delete inside an application | Held in a recoverable trash for 30 days by default, a period your organisation can change, then permanently purged |
| Your content, while your account is active | Until you delete it or close your account |
| Your content, after a subscription lapses | The account moves through a staged wind-down of approximately 54 days — suspension, a grace period, then preparation of an export — before anything is deleted. You are emailed at each stage and may export at any point |
| Audit and activity records | Retained for the life of the organisation, as a security and compliance control |
| Authentication events | Retained for the life of the organisation |
| Usage metering | Retained for the life of the organisation, for billing history |
| Billing records | Retained after account closure as required by Singapore tax law |
A record deleted inside an application is recoverable during the trash period above and is not removed from the database until it is purged. When an organisation is deleted, the deletion is immediate and complete: the organisation's entire database schema is dropped along with every platform record tied to it, and it cannot be recovered by you or by me.
8. Subprocessors
The third parties that process data on my behalf are listed atkeshersuite.com/subprocessors, which forms part of this policy. That page is updated before a new subprocessor is engaged, and account holders are notified by email.
Services you choose to connect to your applications are not my subprocessors. Where you configure a connector or an outbound endpoint, you are instructing the platform to transfer data to a service you hold your own relationship with, and that transfer is governed by your agreement with that vendor.
9. How data is protected
A fuller technical description is published atapp.keshersuite.com/security. In summary:
- Tenant isolation at two independent layers. Each organisation's records are held in their own separate database schema, and every shared platform table is additionally protected by PostgreSQL Row-Level Security enforced by the database rather than by application code. An adversarial isolation test suite runs against a real database on every merge and blocks release on failure.
- Encryption. All data is encrypted in transit (TLS) and at rest at the storage layer. Fields marked sensitive receive a second, application-level layer of encryption using a per-organisation key wrapped by a Google Cloud KMS key that the service can use but never read. That second layer covers text-shaped fields, which is where identifiers such as passport and bank numbers are held. It does not cover numeric fields, because an encrypted number cannot be totalled, filtered or reported on. Numeric personal data — a salary or an account balance, for example — is protected by role-based field permissions and the audit trail rather than by encryption.
- Passwords are hashed with bcrypt and checked against the HaveIBeenPwned breach corpus using k-anonymity. Only the first five hexadecimal characters of the password's hash leave the server; the password does not.
- Two-factor authentication (TOTP) is available and can be required across an organisation.
- Every change is audited, including administrative and emergency access.
9.1 What is not claimed
KesherSuite holds no SOC 2 report, no ISO 27001 certificate, and no completed third-party penetration test. This is stated plainly because it is material to a purchasing decision and to a security review. No system is perfectly secure, and no representation is made that this one is.
10. Your rights
You may, at any time:
- Access your data, or obtain a copy in a portable format. A full export of every application configuration and every record, as CSV or JSONL, is built into the product
- Correct inaccurate data, in most cases by editing it directly
- Delete your data or your entire organisation, permanently
- Withdraw consent to processing. Because the processing is what delivers the service, withdrawing consent generally means closing the account
- Object to or restrict processing carried out on the basis of legitimate interests
- Complain to a regulator — Singapore's Personal Data Protection Commission, or your local supervisory authority in the EU or UK
Requests go to xc.keshersuite@gmail.comand are answered within 30 days, usually sooner. There is no charge.
If you are an individual whose data is held inside a customer's KesherSuite application — an employee in an HR application, or a contact in a CRM — I am the processor rather than the controller. Direct your request to the organisation that holds your data. A request sent to me instead will be passed to that organisation promptly.
11. Data breaches
A personal data breach is assessed as soon as practicable after it is discovered. Under the PDPA, a breach is notifiable where it results in, or is likely to result in, significant harm to any affected individual, or where it affects 500 or more individuals regardless of harm.
- Where either threshold is met, the Personal Data Protection Commission is notified as soon as practicable and in any case no later than3 calendar days after the assessment concludes that the breach is notifiable.
- Where the significant-harm threshold is met, affected individuals are notified at or before the time the Commission is notified, unless remedial action has made significant harm unlikely.
- Where the GDPR applies to the affected data, the relevant supervisory authority is notified within 72 hours of my becoming aware of the breach.
- Affected organisations are notified without undue delay after containment, and told what happened, what data was involved, what has been done about it, and what action they should take.
12. Children
KesherSuite is a business tool and is not directed at children. Account holders must be at least 18, and personal data is not knowingly collected from anyone under 18 as account data. If you believe a child has provided data, contact me and it will be deleted.
13. Changes to this policy
Where this policy changes materially, account holders are emailed and the effective date above is updated. Continued use of KesherSuite after a change takes effect constitutes acceptance of the revised policy. Previous versions are available on request.
14. Reporting a security vulnerability
Report privately toxc.keshersuite@gmail.com rather than disclosing publicly. The commitments are: acknowledgement within 2 business days, an initial assessment within 5 business days, status updates at least every 7 days until the issue is resolved, and a coordinated disclosure window of 90 days from acknowledgement or until a fix ships, whichever is sooner.
There is no paid bounty. Reporters are credited publicly once a fix ships, at their option. No legal action will be pursued against a researcher who makes a good-faith effort to avoid privacy violations, data destruction and service interruption, who interacts only with data they own or have permission to test, who reports promptly and privately, and who does not exploit a finding beyond what is necessary to demonstrate it.