● 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 in exactly two places, neither of them the configuration, permissions or records it reads: your credential into a key vault, and — only when you turn it on — ticketing. Connect Jira, ServiceNow, Zendesk or Syncro and we'll open a ticket for a finding, move it to done, or add a comment. That is the whole write surface — ticket objects in the tool you configured, never the systems being governed, and nothing at all until you enter those credentials. (A Slack incoming webhook, if you add one, receives a message about the finding; nothing is updated or commented there afterwards.)

The commitment

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

Read‑only, always

Every connector issues only read calls — GET in the cloud, SELECT on‑prem. No create, update, or delete path exists in the codebase. It's a structural guarantee, not a setting.

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, which we keep in a key vault rather than a database.

Fails closed on over‑consent

If the app is ever granted a permission outside its published read‑only list, the connector refuses to run. Excess scope is rejected — never quietly used.

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 three places we read more.

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 mailbox or file content — blocked in code
Configuration and permission metadata, plus the three named exceptions
No passwords or secrets leave your tenant

Scoperead-only

Writes to a governed systemnone

Writes to a ticketing system you connectif you enable it

Mailbox & file contentblocked

Read beyond metadatathree, named below

Your passwords heldnever

Revokeone click

The three places we read more, 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. 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 and databases you have Published to the web, 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. Everything else is configuration and permission metadata. And one write, 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. No connector writes to a system it governs, and the build fails if one gains the ability to.

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 a record field, that connector says so and the two cases are named above. A representative slice:

Platform you assess	What Tasirio reads
CloudMicrosoft 365 & Entra ID	Users, groups, admin roles, app registrations, conditional‑access policies, sign‑in & audit logs, sensitivity labels
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

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

Two exceptions, named: a few vendors publish no read‑only way to read the one thing that matters. Microsoft will not list who a SharePoint site is shared with 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. Even then Tasirio never writes: every request is pinned to a read, and the build fails if that stops being true.

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.