● Data access, in plain terms

Our connectors only ever read. On every platform.

It's the first question every IT and security team asks. The answer is the same for Microsoft, Google, AWS, Oracle, Salesforce, Snowflake and every other system you connect: every Tasirio connector is read‑only, reads the security model — not your content — and can be revoked in one click. On Microsoft 365 / Entra and Microsoft Fabric we go one step further and fail closed: the connector inspects the permissions it was actually granted and refuses to run if any of them can write.

Tasirio writes only where you asked it to, and never to the configuration, permissions or records it reads: your credential into a key vault, and — only when you turn them on — ticketing, SIEM/SOAR forwarding and alert webhooks. Connect Jira, ServiceNow, Zendesk or Syncro and we'll open a ticket for a finding, move it to done, or add a comment. Connect a SIEM or SOAR endpoint and we forward our findings to it; add an alert webhook or Slack channel and we post alerts there. Nothing is sent to any of them until you connect it. (A Slack incoming webhook chosen as the ticketing destination receives a message about the finding; nothing is updated or commented there afterwards.) When you point Tasirio at your own cloud vault, it writes a test secret named tasirio-access-probe there to prove it can reach the vault, reads it back, then asks your vault to delete it; if the delete fails, cannot be asked, or the check stops before it, the test secret stays in your vault. Where your own cloud vault sits in a cloud account you have connected for governance, that vault is an exception: Tasirio reads it and also writes your connector credentials and the test secret into it, and can ask the vault to delete them; they are the only objects it writes there, and they can then appear among the secrets it reads there. Software you run yourself is also an exception, in four places. On a Windows DNS server, the installer of the Shadow-AI DNS collector turns on DNS debug logging if it is off, keeps your previous settings and puts them back when you uninstall; run it with -NoAutoEnableDnsLog and it leaves your DNS settings alone. And the setup scripts we give you for Microsoft 365, Microsoft Fabric, Azure and Business Central make the changes in your Microsoft tenant or Azure subscription that each one describes: they add Tasirio's application there (for Business Central, an app registration with a client secret) and grant it the consent, roles or group membership it needs to read; the Microsoft 365 re-enable script also switches Tasirio's application back on. Grant-TasirioDhcpRead.ps1, which you run on a separate DHCP server only if you want the Shadow-AI DNS collector to name devices from it, adds the collector server's computer account to that server's DHCP Users group (read-only access to DHCP); -Remove takes it out. Last, the Microsoft 365 fix script, Remove-TasirioSharingLinks.ps1, which you download beside a work list of findings, removes the SharePoint and OneDrive sharing links that list names, signed in as your own administrator, only when you run it with -Apply; without -Apply it changes nothing and reports what it would remove. Tasirio never runs it.

The commitment

Four guarantees, three of them enforced in our own code.

Read‑only, always

Every connector issues only read operations. Most are GET requests; a few vendors require a POST to run a read, and on‑prem databases are read with SELECT. No connector can create, change or delete anything in a system it reads. Tasirio writes only where you asked it to: your connector credential into a key vault, and — where you switch them on — tickets in your ticketing system, findings forwarded to your SIEM or SOAR endpoint, and alerts to your webhook or Slack. When you point Tasirio at your own cloud vault, it writes a test secret named tasirio-access-probe there to prove it can reach the vault, reads it back, then asks your vault to delete it; if the delete fails, cannot be asked, or the check stops before it, the test secret stays in your vault.

Revocable in one click

Remove consent or delete the application at any time — access stops immediately. For Microsoft 365 there's no standing password of yours for us to hold — consent is an app registration you can revoke. Other connectors do use a credential you supply. We keep it in a key vault and our database holds only a reference to it — unless you turn on the customer-key option, where it is stored in our database encrypted under your key.

Fails closed on over‑consent

For Microsoft 365 and Microsoft Fabric: if the app is ever granted a permission outside its published list, the connector refuses to run. Excess scope is rejected — never quietly used. Other connectors use the credential you scope; they issue only reads whatever it allows.

The standard pattern

Access is granted the same way you approve every other tool — an admin‑consented OAuth app, a scoped read‑only role, or an outbound‑only agent for on‑prem systems. The mechanism your team already knows, per platform.

The boundary

We read the locks — and we name the five places we read more, plus the four connectors that read activity records.

Tasirio governs the permission graph that decides what AI and people can reach. It does not open your documents, mailboxes or messages — and where a check cannot exist without reading a record field, we say which one rather than rounding it off.

No connector writes to a system it governs
No Microsoft 365 mailbox or file content — blocked in code
Configuration and permission metadata, plus the five named exceptions and the four connectors that read activity records
For Microsoft 365, no password or secret of yours is held — access is an app consent you can revoke. Other connectors use a credential you supply, kept in a key vault

Scoperead-only

Connector writes to a governed systemnone

Writes to a ticketing system you connectif you enable it

Microsoft 365 mailbox & file contentblocked

Record fields, content or cardholder locations readfive connectors, named below

Activity or history records readfour connectors, named below

Your Microsoft 365 password heldnever

Revokeone click

The five places we read more, plus the four connectors that read activity records, named: Medius reads supplier bank-account numbers and IBANs, because the check that finds several suppliers sharing one account cannot be done without them — they are stored masked — and supplier addresses, storing a street address only where two or more active suppliers share it but not a registration number. Softbase Evolution reads which columns hold cardholder data and how many rows those tables carry — column names and a row count, never a cardholder value. Notion reads the body text of pages you have Published to the web (for a published database, its title and description; its rows are not read), pattern-matched in memory so we can tell you a page anyone on the internet can open holds regulated data — we store the resulting labels, never the text. Databricks reads the source of notebooks and files in Git-backed workspace folders (at most 25 repositories and 60 files in each), pattern-matched in memory to find credentials written into code — we store the kind of credential and the file’s path, never the text. Smartsheet, for a dashboard you have published, receives what its widgets show — cell values, chart figures and text — in the same answer that names the sheets and reports feeding it; we keep only which sheets and reports feed it, and discard the rest in memory. Google Workspace, Salesforce, Snowflake and John Deere also read activity or history records for narrow facts, and Salesforce Apex code, Snowflake stored-procedure code and the text of past Snowflake queries that use AI features are read in memory; sections 5.1, 5.3 and 17 of our DPA say exactly what. And the writes, each yours to switch on: if you connect Jira, ServiceNow, Zendesk or Syncro, Tasirio opens and updates tickets there so you can manage remediation in the tool you already use; a SIEM or SOAR endpoint you connect receives findings; and an alert webhook or Slack you add receives alerts. No connector writes to a system it governs, and for every connector that asks for a permission named for writing, the build fails if the connector's own code can issue an update or delete request to the system it reads.

The access model

One pattern, every platform you choose to assess.

Each connector is a separate opt‑in, scoped to what you turn on. The rule: Tasirio reads the security and configuration model — who can reach what — and does not open the documents, mailboxes or messages behind it. Where a check cannot exist without reading more than that, the connector says so, and the five cases, plus the four connectors that read activity records, are named above. A representative slice:

Platform you assess	What Tasirio reads
CloudMicrosoft 365 & Entra ID	Users (including each account's last sign‑in date), groups, admin roles, app registrations, conditional‑access policies, sensitivity labels — not the sign‑in or audit logs themselves
CloudGoogle Workspace	Users, groups, admin roles, OAuth app grants, drive sharing posture, 2‑step‑verification enforcement
CloudSalesforce	Profiles, permission sets, roles, sharing rules, connected apps & API access — not record data
CloudAWS & Oracle	IAM identities, roles & policies, resource‑access & public‑exposure configuration
CloudSnowflake & Databricks	Roles, grants, shares, and data‑access governance — the entitlement model, never the tables
CloudOkta & ServiceNow	Users, groups, admin roles, app assignments, MFA/policy posture, ACL configuration
On‑premDynamics NAV (on‑prem) & SQL	The permission model only — users, permission sets, object access — via an outbound‑only agent; never a business record

Plus Dynamics 365 F&O, Dataverse, Fabric/Power BI, and dozens more — each its own read‑only connector. Every connector's exact scopes are shown in‑app before you approve it.

Full transparency

Read‑only wherever the vendor offers it — and we show you the exceptions.

Whatever the platform, Tasirio requests only the least‑privilege, read‑only scopes it needs to read the security model, and every connector's fetch path is pinned to read verbs, nearly all of them against an allow‑listed set of endpoints — a rule checked automatically on every release. On Microsoft 365 / Entra and Microsoft Fabric, where the vendor tells us what was actually granted, the connector also reads that list back and refuses to run if it holds anything that can write. Extending that check to each remaining vendor that exposes granted scopes is in progress; we'd rather name where it runs today than imply it everywhere. You see the exact scopes for a connector in‑app before you approve it. Here's one worked example, in full.

Microsoft 365 / Entra IDSee the standard Graph scope list ▾

Directory & identity

User.Read.AllGroup.Read.AllGroupMember.Read.AllDirectory.Read.All

Roles & applications

RoleManagement.Read.DirectoryRoleManagement.Read.AllApplication.Read.AllDelegatedPermissionGrant.Read.All

Security & activity

Policy.Read.AllAuditLog.Read.All

Data & labels

Sites.Read.AllInformationProtectionPolicy.Read.AllSensitivityLabel.Read.AllExternalConnection.Read.AllAppCatalog.Read.All

Teams & devices (metadata and policy only — no message or chat content, no device content)

Channel.ReadBasic.AllChannelMember.Read.AllTeamsAppInstallation.Read.AllDeviceManagementApps.Read.All

Blocked in code: all of Mail.* and Files.* — they cannot be requested even by mistake — and no *.Write, *.Send or *.Delete scope.

Two Microsoft exceptions, named: a few vendors publish no read‑only way to read the one thing that matters. Microsoft will not list which apps a SharePoint site is granted to without Sites.FullControl.All, and Business Central’s permission model can only be read by signing in as a licensed user — a delegated permission on an app you register in your own tenant. No application permission can read it at all, whatever it is named, so none is requested. The SharePoint one is off unless you switch it on, and we tell you what each unlocks and what we still will not collect before you grant it. Other connectors that need a permission allowing more than reading — HubSpot, Docusign, Box, Google Workspace, Oracle Fusion, John Deere and Azure AI Foundry — show it, and why, on the Connect screen before you grant it. Even then no connector writes: every request is pinned to a read, and for a connector holding one of these permissions the build fails if the connector's own code can issue an update or delete request to the system it reads.

Want the exact read‑only scopes for Google, Salesforce, AWS, Okta or any other connector? They're listed on each connector's Connect screen in the app — and we'll send the full set to your security team on request.