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: Tasirio is read‑only, reads the security model — not your content — fails closed if granted anything more, and can be revoked in one click.
The commitment
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.
Remove consent or delete the application at any time — access stops immediately. There's no standing credential of yours for us to hold.
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.
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
Tasirio governs the permission graph that decides what AI and people can reach. It deliberately never collects the thing it's protecting: your actual data.
The access model
Each connector is a separate opt‑in, scoped to what you turn on. The rule never changes: Tasirio reads the security and configuration model — who can reach what — and never the content behind it. 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‑premBusiness Central (NAV) & 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
Whatever the platform, Tasirio requests only the least‑privilege, read‑only scopes it needs to read the security model — and refuses to run if it's granted anything beyond them. You see the exact scopes for a connector in‑app before you approve it. Here's one worked example, in full.
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.
We'd rather earn your security team's approval than route around it. We'll walk your IT admins through the exact setup, answer every question, and hand over the full technical brief.
Talk to our security team