NecoSift by necolo · Private Gmail gateway
Privacy Policy
This policy describes data handling by NecoSift by necolo, a private Gmail gateway operated by necolo at sift.necolo.xyz.
Operator and contact
The operator is necolo. For privacy questions, access concerns, or data deletion requests, contact necolo through the channel used to invite you. This service does not offer public account registration.
Google data we access and why
Owner sign-in uses Google identity permissions (openid and email). We store the Google account identifier and email address to identify the owner and connected mailboxes.
Connecting Gmail separately requests https://www.googleapis.com/auth/gmail.readonly. This broad permission allows the gateway to read Gmail labels, message metadata (including headers such as sender, recipients, subject and date), message bodies, and attachments. It does not grant Gmail write access.
We use this access to provide owner-configured, label-scoped message search and reading to authorized Agents. Attachment access requires an additional local grant. The gateway enforces label restrictions; the Google permission itself is not label-scoped. The console displays configuration and audit information, not message body or attachment previews.
If optional mail events are enabled, Google Gmail change notifications and history identifiers help discover new work within existing grants. Events do not expand an Agent's mail permissions.
Storage, credentials, and request processing
The configured Turso/libSQL database stores owner and mailbox identifiers and email addresses, encrypted Google access and refresh tokens, Agent configuration, label grants, credential hashes, OAuth/session records, and audit metadata. Audit records can include message, attachment-part and label identifiers, request identifiers, timestamps, decisions, byte counts, and server-side delivery status.
Google tokens are encrypted using AES-256-GCM. Owner session tokens and Agent bearer credentials are stored as hashes. Webhook configuration includes the receiver URL and an encrypted signing secret. Encryption and hashing reduce specific risks; they do not eliminate risks from a compromised host, operator account, or authorized recipient.
Mail event records store message/history identifiers, subscription and delivery metadata, processing state, and expiry information. The application's database is not a message-body or attachment archive. However, bodies and attachments pass through server memory and response transport when requested, and full Gmail responses may include content while permissions are checked. Requests to Gmail and mail API responses use no-store caching directives; this is not a promise that data never exists in buffers, client caches, hosting logs, or provider backups. Hosting and receiver settings affect those copies.
Necessary browser cookies support sign-in, session security, OAuth flows, and language preference.
Providers and owner-selected recipients
Google provides identity, Gmail, and, when configured, Pub/Sub notifications. Vercel, when used to host this instance, processes web requests and runtime data; Turso, when used for the configured database, processes stored records. Provider infrastructure, operational logs, and backups are subject to the owner's deployment configuration and the providers' terms and policies.
The owner chooses Agent clients and any webhook receiver. An authorized Agent can receive mailbox information, labels, message metadata, bodies, and permitted attachments. A webhook wake notification contains a delivery identifier and timestamp (or a verification challenge), not a message body; the Agent retrieves authorized content separately.
Review each recipient's privacy and AI-provider settings before granting access. Agents may forward or retain received data under their own policies. Revocation cannot retrieve or delete copies already delivered to them.
Google API Limited Use
NecoSift by necolo's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
This gateway uses Google data to provide the user-facing access and event features described here, not to sell data, serve advertisements, or train generalized AI models. It has no generalized AI training feature. This commitment does not represent the policies of independent Agents or model providers selected by the owner; the owner must select recipients and uses consistent with the permissions and applicable Google policies. This page does not claim Google verification or certification.
Retention and deletion limits
Audit queries are limited to the most recent 90 days. Cleanup removes older audit records and their associated item identifiers, and removes expired temporary session/OAuth records according to their expiry rules. Physical deletion depends on maintenance execution and successful batches; it is not guaranteed at the exact expiry time.
Mail event work normally expires after 7 days. Completed or suppressed items are eligible for cleanup after the retention conditions are met; expired event tombstones are kept for a further 7 days. Event cleanup depends on worker execution and can be delayed. This is not a 7-day or 90-day deletion promise for all stored data.
Owner, mailbox and Agent configuration and some credential/grant history remain until the instance owner removes them through instance administration. Disconnecting is not full account deletion. Ask the owner to arrange deletion of remaining records and explain any hosting logs or backups; database cleanup does not guarantee deletion from provider backups or third-party recipients.
Your controls and Google revocation
The owner can change label grants, pause or revoke Agent access, and disconnect a mailbox in the owner console. Local disconnection clears stored Google token ciphertexts and associated label grants, stops mailbox event subscriptions, and blocks future gateway access to that mailbox. Mailbox identity and audit records can remain.
The gateway also attempts Google authorization revocation and reports its result separately. A local disconnect does not guarantee successful Google revocation. Review or revoke access directly in Google Account third-party connections, especially if revocation is pending or failed. Revoking an Agent credential alone does not revoke Google authorization.
Policy updates
The owner may update this policy as the instance changes. Check the date above and contact the owner if the described handling does not match your expectations. See also the Terms of Service.