Outlook MCP
Outlook MCP

Security

How mailbox credentials are protected, and how one customer is kept away from another.

Last updated 11 September 2026

A service that holds a token to someone's mailbox is holding the keys to their company. This page describes what protects those keys, in enough detail to check rather than to reassure.

Credentials at rest

Microsoft tokens are sealed with envelope encryption. Each record gets its own single-use data key, used once with AES-256-GCM; that data key is itself encrypted under a root key that lives outside the database, in a secret manager. The stored value carries the wrapped data key, a nonce, and an authentication tag.

Three properties follow, and they are the reason for the design:

Every key provider returns a real 32-byte key or refuses to start. There is no path that derives a key from a public value, and no default key.

Keeping customers apart

The organisation is the boundary, and it is enforced in the data layer rather than remembered by each caller. Every query that touches customer data takes an organisation identifier and throws if it is missing, so an untenanted query cannot be written by accident. The identifier comes from the authenticated session or the access key — never from a URL, a header, or anything else the caller controls.

Changing an identifier in a request gets you a 404, not somebody else's mailbox.

Signing in

Access keys

The key your assistant sends is shown once, at creation, and only a hash of it is stored — we cannot show it to you again, and neither can anyone who reaches the database. Revoking a key takes effect on the next request. Keys belong to the organisation, so someone leaving the company does not take them, and removing that person does not break them.

In transit

Everything is HTTPS. The portal is served with a content security policy that permits no third-party scripts and no outbound connections beyond this origin, so a script that somehow reached the page could not send anything anywhere. Framing is refused outright.

What we ask Microsoft for

Only delegated permissions — the service can do what you can do, in the mailboxes you can already reach, and nothing more. There is no application-level permission that would let it read a mailbox you cannot. SharePoint access, which needs an administrator's approval, is off unless you turn it on.

What the service keeps

No message content, ever. See Privacy for exactly what is recorded and for how long.

Operations

Reporting something

If you think you have found a vulnerability, write to security@xogent.ai. Tell us what you found and how to reproduce it. We will acknowledge within two working days and keep you posted until it is closed. Please do not run tests that would degrade the service or reach data that is not yours — we will not pursue anyone acting in good faith within those limits.