Leysa

Security

Last updated 30 September 2026

Leysa makes changes in your Microsoft 365 organisation, so it's built to make the safe path the default. This page describes how, in plain terms. Found a problem? Email security@leysa.ai.

What Leysa can do in your tenant

  • Leysa connects through an app a Global Administrator approves in Microsoft's own consent screen. You can see and remove it at any time in the Microsoft Entra admin centre → Enterprise applications.
  • Leysa asks only to read your directory. Every change it makes is scoped to what an automation needs: people, groups, teams, licences, mailboxes and guest invitations.
  • For mailbox, password and MFA tasks, an administrator also assigns Leysa two roles (Exchange Administrator and Authentication Administrator). Neither can change a Global Administrator or any other administrator.
  • You can assign those two roles by hand, or let Leysa assign them during setup. If you choose that, Leysa acts using the administrator's own sign-in at that moment, and can't change roles on its own, before or after. The permission that allows it stays listed under Enterprise applications → Permissions, and you can remove it whenever you like; the two roles stay assigned.
  • Microsoft 365 hides people's names in its usage reports by default. An administrator can switch names back on from Leysa, the same way: signed in as themselves, for that one change. Leysa doesn't match the hidden codes back to people itself, because that setting is your organisation's privacy choice.
  • Leysa refuses to change any account that holds an admin role: no password or MFA resets, profile changes, offboarding, forwarding or mailbox access. It checks every role, including ones held through a group, and stops if it can't check.

Who can do what in Leysa

  • Three roles: Owner, Admin and Operator. Operators only see and use the areas the Owner gives them.
  • The Owner chooses which automations need approval. Nobody can approve their own request unless they're the workspace's only Admin, and those are labelled in Activity.
  • Every run records who requested it, who approved it, when, and what happened at each step. Activity can be exported as a spreadsheet.
  • Removing someone from the workspace ends their access within minutes and cancels their pending requests; their history stays in the audit trail.

Your service desk

  • Connecting a service desk is optional, and only an admin can do it. Leysa works with Jira Service Management, Halo, Freshservice and ServiceNow.
  • Leysa only reads tickets, to find the one you pick and show its number, title and status, and adds notes to the tickets you link. It doesn't change a ticket's status, assignee or anything else.
  • Its notes are internal: an internal comment in Jira, a private note in Halo and Freshservice, and a work note in ServiceNow. The requester doesn't see them. Whether your own agents are told about new notes is up to your service desk's notification settings.
  • A note says what happened at each step, who asked and who approved. It never contains a password or a password link, only that a link was sent and to whom.
  • Leysa keeps only the ticket number with each request. Titles and statuses are read from your service desk when they're shown, not stored.
  • How Leysa signs in: to Jira as a service account you create in Atlassian Administration, allowed only to read tickets and add comments, so its notes appear under the service account's name, not a person's; to Halo through an API application you create, allowed only to read and edit tickets; to Freshservice as an integration user you create; to ServiceNow through an OAuth client you create, acting as a user you create for Leysa, which you can limit to ServiceNow's Table API. The sign-in details are encrypted with AES-256-GCM before they're stored.
  • Disconnecting in Leysa deletes those details straight away. To remove Leysa's access on your service desk's side too: in Atlassian, revoke the service account's credential or delete the service account; in Halo, delete the API application; in Freshservice, deactivate the integration user; in ServiceNow, deactivate Leysa's OAuth client or its user.

Passwords

  • Leysa generates temporary passwords itself. Nobody types or sees one.
  • The password is delivered through a one-time link that works once and expires (at most 7 days). Only the person who ran the automation, or the colleague it was emailed to, can get the link.
  • Links only go to people inside your organisation, never to outside email addresses.

Data protection

  • All traffic uses HTTPS. Microsoft 365 access tokens and temporary passwords are encrypted with AES-256-GCM before they're stored; the database itself is encrypted at rest by our database provider.
  • Data is stored and processed in Sydney, Australia. A few supporting services (email delivery, error reports and the AI assistant) run in Japan and the United States.
  • Sign-in links are stored only as one-way hashes, so a copy of the database can't be used to sign in. Password-link addresses are stored encrypted and wiped as soon as the link is opened or expires.
  • Sessions end after 30 minutes of inactivity (with a warning), and always after 12 hours.
  • Error reports have names, email addresses and IDs removed before they leave our servers.

Your controls

  • Disconnect Microsoft 365 at any time from the Integrations page, and remove the Leysa app from your tenant.
  • Disconnect your service desk at any time from the Integrations page.
  • The Owner can delete the whole workspace and its data in Settings → Profile.
  • When you connect Microsoft 365, Leysa switches on people's names in Microsoft's usage reports, so reports show people rather than codes. You can hide them again in the Microsoft 365 admin centre, and Leysa won't change it back.