Access model
Eigenlaut reaches Google Workspace through a service account with domain-wide delegation. Your super admin authorises that service account’s client ID for exactly three scopes in the Admin console. There is no app to install and no consent screen for your people, and the authorisation stays under your control: you see it and delete it in the same place.
Tokens are short-lived and requested per user and scope. Directory reads run as the administrator who verified your organisation, and each signature is written as the user it belongs to.
The three scopes
Google allows more with each scope than Eigenlaut does. Both are listed here, so you can judge the grant itself.
Directory users, read only
https://www.googleapis.com/auth/admin.directory.user.readonly
- What Google allows
- Read the user accounts of your Workspace directory.
- What Eigenlaut does
- Lists your users and reads the fields signatures use: name, job title, department, phone numbers, work location, custom fields and whether someone is an admin.
Gmail basic settings
https://www.googleapis.com/auth/gmail.settings.basic
- What Google allows
- Manage basic mail settings such as signatures, filters and the vacation responder. It gives no access to messages.
- What Eigenlaut does
- Reads each user’s send-as addresses and changes one field: the signature. It never touches filters, forwarding or any other setting.
Group members, read only
https://www.googleapis.com/auth/admin.directory.group.member.readonly
- What Google allows
- Read the members of groups in your directory.
- What Eigenlaut does
- Reads the members of the groups you use in rules or campaign targets, and only those.
Nothing else: no access to messages or attachments, no Drive or Calendar, and no write access to your directory. Signatures are changed with a patch of the signature field alone, so no other send-as setting is touched.
Tenant isolation
In the hosted edition many organisations delegate to the same service account. What keeps them apart is a rule in the code: Eigenlaut only ever acts as
- the administrator who verified your organisation, and only setup verification can set that address,
- the person signing in, while they verify the connection,
- addresses that your own directory returned when listed as that administrator.
No request can name an arbitrary address to act as. Every database read is bound to the organisation of the signed-in session, never to an id taken from the request, and tests prove that a member of one organisation gets “not found” for another’s templates, runs and members.
Sign-in and roles
- Sign-in with Google only, using the authorisation code flow with PKCE. Accounts without a Workspace domain are refused.
- The session is one cookie,
HttpOnly,Secure,SameSite=Lax, valid for 12 hours. We store only its hash. Every request re-reads your role, so a change applies at once. - Roles: admin (everything), editor (templates, rules, company details, previews, dry runs) and viewer (read only). Live runs, the schedule, members, billing, setup and deleting the organisation are for admins.
- Every write, sign-in and run goes to the audit log, which admins can export as CSV.
What we store
Eigenlaut stores no names, job titles or phone numbers at rest. They are read from your directory while a run works and are not kept afterwards. IP addresses are not stored anywhere; the rate limiter keeps them in memory only.
| Data | Kept for |
|---|---|
| Your organisation: domain, status, settings (company details, branding, schedule), templates, rules and campaigns | Until you delete the organisation, or 30 days after the trial or subscription ended without a new subscription |
| Team members: address, role, last sign-in | Until removed or the organisation is deleted |
| Per run and address: the outcome (updated, unchanged, would update, skipped, failed) | 90 days |
| Runs (who started them, when, totals) | 400 days |
| Audit log of every change, sign-in and run | 400 days |
| Hashes of the signature we wrote and the one Gmail returned (to detect hand edits) | Until the organisation is deleted |
| Organisational unit paths and departments seen at the last run (for the rule editor) | Until the next run or deletion |
| Sign-in sessions (as a hash) | Valid 12 hours, deleted at sign-out or by the next daily purge |
| Sign-in state during the Google login | Valid 10 minutes, deleted on use or by the next daily purge |
| Stripe event ids (so a webhook is processed once) | 30 days |
| Organisations that never finished setup | 30 days |
Expired data is removed by a daily job. Deleting your organisation removes every row that belongs to it at once. In the hosted edition, live updates to Gmail stop when the trial or subscription ends, and the organisation is deleted this way 30 days later unless you subscribe.
Template safety
Signature templates are checked when they are saved. Scripts, frames, forms, embedded objects, styles, SVG, event handlers and javascript: links are rejected, not cleaned up, so nobody with editor rights can plant code in colleagues’ mail. Previews render in a sandboxed frame, never in the dashboard itself. Gmail checks signatures as well.
Subprocessors
- Cloudflare runs the service: the Worker, the D1 database, the queue for sync jobs, and email routing for the contact form.
Stripe handles checkout, subscriptions and invoices in the hosted edition as our own payment provider. It receives billing details only, never Google Workspace data, so it is not a subprocessor of your data (privacy policy).
Google is your own provider: Eigenlaut calls its APIs on your behalf with the scopes above. Self-hosted, everything runs in your own Cloudflare account and there is no billing. The binding list is in the data processing agreement.
Revoking access
In the Admin console, open MenuSecurityAccess and data controlAPI controlsManage Domain Wide Delegation and delete Eigenlaut’s client ID. Google says apps that depend on a deleted client stop working immediately, while new or changed authorisations can take up to 24 hours.
To remove your data as well, an admin deletes the organisation in the dashboard settings. That also cancels the subscription.
Known limits
The hosted edition signs every Google request with one service-account key, kept as an encrypted secret of the Worker and never in the database. Tenant isolation above is what keeps organisations apart, but a leaked key would reach every organisation that delegated to it. The planned upgrade is one service account per organisation, with tokens signed by Google’s IAM API instead of a stored key. Until then, if that risk matters to you, self-hosting gives you a service account of your own.
Reporting a vulnerability
Write to contact@eigenlaut.app with the steps to reproduce. Please give us a reasonable time to fix the issue before you publish it, and do not access other people’s data while testing. Our contact details for researchers are also in security.txt.