Single-use email codes
Sign-in uses a six-digit email code rather than a reusable password. Codes expire, repeated failures are limited, and authentication responses avoid revealing whether an account exists.
Clear protections, without vague assurances.
See how Emelyn protects account access and workspace boundaries, approaches data handling, and gives you a direct route to report a concern.
Account access has a narrow, inspectable security model.
The controls are designed to make sign-in, sessions, workspace context, and permission checks explicit rather than hidden behind a general security claim.
Protected browser sessions
Production session tokens use Secure, HttpOnly cookies rather than local storage. State-changing requests are checked against CSRF protection.
Visible session control
Signed-in users can review meaningful device and activity context for active sessions and revoke another session without exposing its raw token.
Server-enforced workspace boundaries
The backend resolves the signed-in user's sole active organization membership and its workspace. It checks that relationship rather than trusting a workspace selection from session state, a URL, or browser-only settings.
Use the information needed for the workflow—nothing more by implication.
The privacy notice remains the controlling public explanation of information collection, use, sharing, retention, and individual choices.
Workflow content
Emelyn may process sources, topics, brand guidance, instructions, drafts, edits, approvals, and publishing context that you provide or authorize for the service.
Analytics boundaries
Optional analytics require a visitor choice. Message bodies, passwords, access tokens, private drafts, and payment details are excluded from product analytics.
Sharing and retention
We do not sell personal information or share private workflow content for unrelated targeted advertising. Retention depends on the purpose, account relationship, security and backup cycles, disputes, and legal requirements. Customer-specific commitments belong in written terms.
Connected services
Access should be explainable before it is granted.
Emelyn's connected-service standard is to explain required permissions, what the service can read or change, token handling, reconnection behavior, limits, failure states, and how to disconnect it. Do not send passwords or access tokens through the contact form or support email.
A security page should make limitations easier to find.
- Account controls cannot protect a compromised email inbox, device, browser, or social account outside Emelyn.
- Connected platforms apply their own permissions, policies, review systems, availability, and enforcement decisions.
- Do not submit regulated or location-restricted data until the relevant safeguards and terms have been confirmed.
- No service can guarantee absolute security; suspected compromise should be reported promptly.
Tell us if an account or workflow may be compromised.
Email from an address we can reasonably verify and avoid placing secrets or sensitive content in the first message.