Security
Your tenant, your keys, your revoke button
Handing a provider access to your Microsoft 365 is the part that should make you uncomfortable. Here is exactly what we ask for, why each permission exists, and how you withdraw consent yourself. Existing tokens may remain valid temporarily; contact our operators to suspend jobs and confirm access has stopped.
Last reviewed September 28, 2026
The Graph permissions we hold
One fixed set of permissions, tenant-wide, the same for everyone
These are application permissions, and application permissions are not limited to particular mailboxes or sites. Once your administrator consents, our application can technically reach every mailbox, calendar and SharePoint site in your tenant — whether or not an automation of yours points at any of them. We point the automations only at what you nominate, but that is our configuration choice, not a boundary Microsoft is enforcing on us. The boundary Microsoft does enforce is an ApplicationAccessPolicy, which you create in your own tenant; it covers Exchange only, and there is no equivalent for SharePoint today.
This is the complete set, and it is the same for every customer — it is not assembled per tenant and buying fewer automations does not shrink it. These are application permissions, so they are tenant-wide rather than limited to the mailboxes and sites you nominate; we point the automations only at those, but that is our configuration, not a boundary Microsoft enforces on us. Microsoft's own consent screen is the authoritative statement of what you are granting.
Mail.ReadWriteRead + writeRead the mail an automation is built to handle, file its attachments, and leave a drafted reply in Drafts. Tenant-wide: it reaches every mailbox in your tenant, not only the one an automation points at.
Invoice filing, expense receipts, lead routing
Mail.SendWriteSend the message an automation composes — a morning brief, a meeting prep note, an acknowledgement. Tenant-wide: it can send as any mailbox in your tenant.
Morning digest, meeting prep, notifications
Calendars.ReadRead onlyRead today's meetings so a brief can list them. Read only — we cannot create, move, or cancel anything in a calendar.
Morning digest, meeting prep
Sites.ReadWrite.AllRead + writeFile documents into the SharePoint library an automation is configured for. This is the broadest permission we hold: it reaches every SharePoint site in your tenant, and there is no per-site restriction on it today.
Invoice filing, expense receipts, document filing
User.Read.AllRead onlyResolve who owns what, so a notification reaches the right person and a filed document is attributed correctly. Read only — we cannot create, change, or disable an account.
Routing, mailbox selection during onboarding
Admin consent
We never hold a standing password to your tenant
Your Microsoft 365 admin consents to a single named ID360 application from inside your own admin center. Its permissions are tenant-wide, not confined to the mailboxes and sites you nominate — we point the automations only at those, but that is our configuration, not a limit Microsoft imposes on us. There is no shared admin account and no password of yours in our hands, and you can withdraw that consent yourself at any time. Blocking the application prevents new access tokens, but existing tokens may remain valid until they expire. Granular delegated administration (GDAP), which adds a hard expiry date to a partner relationship, is created through Microsoft Partner Center. A reseller relationship alone does not grant GDAP access. Our management integration uses the application consent described here.
This is how we work, not a product we ship. We have not built software that manages or reports on delegated relationships — Microsoft's admin center is the system of record, it belongs to you, and it is the place to check what any partner can do in your tenant. During onboarding we agree the roles in writing and you grant them yourself.
How you revoke our access, without us
- 1
Sign in to the Microsoft 365 admin center
admin.microsoft.com, with a Global Administrator account of your own. You never need us present, and you do not need to tell us first.
- 2
Open Identity, Applications, then Enterprise applications
This is where the consent you granted actually lives. Our access is a single named application in your tenant — not a partner relationship — so this list, not Settings > Partner relationships, is the page that controls it.
- 3
Find ImpressionsDirect360 Automations
Open it and you can see exactly which Microsoft Graph permissions your admin consented to. That screen is authoritative; if it ever differs from the list above, believe it and tell us.
- 4
Remove its permissions, or delete the application
Withdraw consent under Permissions, or delete the enterprise application, to remove the authorization you granted. Blocking the application prevents new access tokens, but existing tokens may remain valid until they expire; do not assume an instant cutoff. Your tenant, licences, mail, and files are unaffected, and any file we filed for you stays where it is.
- 5
Contact ID360 operators to suspend jobs and confirm access has stopped
Use the support contacts on /support, especially for a suspected incident. Ask operators to suspend scheduled and in-progress jobs and help confirm access has stopped. This is an operational request, not an automatic effect of withdrawing consent or a guaranteed revocation time.
You do not owe us notice, an explanation, or a support ticket to do this. For job suspension and confirmation that access has stopped, contact our operators through support. Microsoft explains the existing-token caveat in its guidance for blocking application access in your tenant. We do not guarantee an instant cutoff.
Tenant isolation
One customer, one tenant, one set of permissions
Separate by construction
Original mail and files remain in your own Microsoft 365 tenant, whose boundary Microsoft enforces. Extracted operational details, run history, and usage records also live in our Azure PostgreSQL database and can contain personal data. AI steps send prompt content to the provider assigned to that feature.
Per-customer credentials
Every automation authenticates against one tenant with that customer's own consent-issued token. A credential for your tenant opens nothing in anyone else's, and revoking yours affects only you.
Owner-scoped platform data
On the ID360 side, database rules deny by default and scope every record to its owner, with billing and entitlement fields writable only by the server. See the trust page for what backs that.
Data residency
Where each kind of data actually sits
Original mail and files remain in your tenant. Extracted operational records, account data, and private media have separate storage locations. AI and other provider processing follows the provider-specific locations below; it is not universally US-only.
| Data | Where it lives | Notes |
|---|---|---|
| Original Microsoft 365 mail, files, and calendar content | Your own Microsoft 365 tenant | Original mail and files remain in the Microsoft region of your tenant. Automations read and write there, but extracted operational details are stored on our infrastructure and AI steps send prompt content to the provider assigned to that feature. |
| Extracted operational details, run history, and usage records | ID360 Azure PostgreSQL database, United States | These records can contain personal data, including invoice or receipt details, mailbox addresses, message identifiers, classifications, and links to filed documents. They are separate from the original mail and files in your tenant; retention and deletion are described in /privacy. |
| Automation logic and run state | Azure Functions and Logic Apps, United States | The code that orchestrates a workflow, plus the run history Azure keeps for it. |
| ID360 AI inference | Feature-specific providers and processing networks; not universally US-only | The provider catalog lists Google Gemini for the storefront assistant, logo prompts, and content tools; Qwen 3.8 Max through Vercel AI Gateway for website generation/refinement and video planning/editorial processing, requiring zero-data-retention-capable routing; and Higgsfield/Seedance for video visuals. These documented routes do not establish verified live API availability. See /trust/subprocessors for provider-specific locations. |
| Your ID360 account, billing, and saved-project records | Google Cloud / Firebase and Stripe, United States | Account records, subscription state, and saved website projects. Card data stays with Stripe; private video assets and finished drafts use the separate Azure storage below. |
| Private video assets and finished drafts | Azure private media storage, United States | Azure provides video rendering, narration, and private media storage. Storage location does not establish where upstream AI providers process prompts or generate images and clips; those processing networks are not represented as US-only. |
The vendor-by-vendor version, including what data category reaches each one, is on the subprocessors page.
What this page is not claiming
- We hold no security certification — no SOC 2, no ISO 27001, no HIPAA attestation — and we have not been audited by a third party.
- Delegated admin governance is a working practice with a written onboarding record, not tooling we have built. Microsoft's admin center is where it is enforced and reviewed.
- Sign in to view managed automation activity and mailbox creation and removal activity. Coverage is partial, not a complete cross-product audit trail or a record of every access. Contact support for help with records outside these views.
- Nothing here should be read as a review or endorsement of this service by Microsoft.
The full true-today versus roadmap breakdown lives on /trust, and how to report a suspected incident is on /trust/incident-response.
Want the scope list for your workflows?
Bring your requirements to the setup call and we will write down the exact permissions each automation needs before you grant anything.