Tasirio is designed for the buyer whose job is to say no. It reads the least it can, isolates every customer at the database, and proves its own integrity.
Your data is encrypted in transit and at rest — with a second, application-level layer over the most sensitive values, so a stolen database alone yields nothing readable.
No Tasirio connector writes, changes, or deletes anything in the system it reads. Every connector is written to issue only reads, and for every connector that asks for a permission named for writing — each one is listed when you consent — the build fails if the connector's own code can issue an update or delete request (PUT, PATCH or DELETE) to the system it reads. Where a vendor offers no read-only scope for something we must read, we ask for the write-named one and tell you exactly what it is before you grant it, rather than quietly skipping the check. Access is granted on your terms and can be revoked at any time. Beyond reading, Tasirio writes only where you asked it to: the connector credential you provide, into a key vault (ours, or your own cloud vault) with only a reference kept in our database — or, if you turn on the customer-key option, into our database encrypted under your key. Everything else is yours to switch on: if you connect a ticketing system (Jira, ServiceNow, Zendesk, Syncro), Tasirio writes the tickets it opens there on your behalf — setting their status and adding comments, and, without a further click, reopening a ticket with a comment when a later scan finds a finding marked fixed still present; if you connect a SIEM or SOAR endpoint, it forwards its findings there — after each scan that raises new findings, unless you untick “Auto-push”; and if you add an alert webhook or Slack, it posts alerts there. Never the configuration, permissions or records being governed, except that where a ticketing system you connect is also one it governs (ServiceNow and Zendesk can be both), it opens tickets there, sets their status and adds comments; and where your own cloud vault sits in a cloud account it governs, it writes your connector credentials and a test secret into that vault and can ask the vault to delete them. Nothing is sent to any of those three until you connect it. 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. 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 settings you switch on are listed in one place, with their defaults and who can switch each — including what a Tasirio administrator can switch on in your workspace.
We read the locks and the keys — identities, groups, permissions, sharing, and labels — rather than the contents of your documents and messages. Five connectors read record fields, content or where cardholder data sits because the check cannot be done without them, and all five are disclosed: Medius supplier bank-account numbers, stored masked, and supplier addresses, an address stored only where two or more active suppliers share it but not a registration number; Softbase Evolution cardholder column names and row counts, never a cardholder value; for Notion pages you have Published to the web, the page body text — pattern-matched in memory so we can tell you a publicly published page holds regulated data, with only the resulting labels stored, never the text; and, for Databricks, the source of notebooks and files in Git-backed workspace folders — pattern-matched in memory to find credentials written into code, with only the kind of credential and the file’s path stored, never the text; and, for a Smartsheet dashboard you have published, what its widgets show — cell values, chart figures and text — which Smartsheet returns in the same answer that names the sheets and reports feeding it, with only those sheets and reports kept and the rest discarded in memory. Separately, if you install our Shadow-AI DNS collector or send us your cloud or security-service DNS logs, we receive which public AI services your network looked up, from which address, device name or user name — a device name can include a person’s name.
Your governed data — every finding, permission and document record we hold about your estate — is isolated with row-level security enforced by the database itself, not by application code, so cross-tenant access fails closed — FORCE ROW LEVEL SECURITY means even the table's own owner cannot read across tenants without the tenant context, and the application connects as a non-owner role that cannot bypass row security. It sets one customer's context for each unit of work, and a query with no context fails rather than returning another customer's rows. Platform records such as your connector settings sit in a separate schema where every query is tenant-filtered and the application runs as a role that cannot bypass isolation.
The audit trail is hash-chained and HMAC-keyed. Any attempt to rewrite history breaks the chain and is detectable on verification.
Secrets live in a managed vault; the application connects as a non-privileged role that cannot bypass isolation. Connector credentials are certificate-first where supported.
Tasirio runs in its own dedicated cloud environment, separate from any other product or workload, with its own identity, secrets, and data store.
Everything Tasirio holds about your estate sits in Microsoft Azure, East US 2, in the United States. That is the only region we operate, it is not something you can choose, and there is no EU, UK or Canadian hosting option today. Our Data Processing Addendum and sub-processor list say the same thing in contract language, including the one qualification that is real. The exception is email: our email provider, Brevo, processes in the European Union the names and addresses of the people we email and what we send them — for a new-findings alert, how many findings there are by severity and by check, never which object a finding is about — and, where text messages are switched on, the mobile number and the message. You choose who receives alerts, and you can turn them off.
We say this next part because a buyer with a residency requirement deserves the actual state rather than a roadmap. On 22 August 2026 we stood up a complete second region in Azure Canada Central and proved, end to end, that a governed row written for a Canadian tenant landed in the Canadian database and was verifiably absent from the US one — and that a tenant assigned to a region we have not built is refused rather than quietly served from the US. Nine assertions, all passing. Then we deleted the region the same night and re-queried to confirm it was gone.
What that test does not say. It covered the database only. The credential vault, evidence storage and the ingest endpoint were provisioned but never written through, so their residency is unproven. The product ships with one region in its list, the region control is staff-operated rather than self-serve, and no customer runs outside the United States. The product is English-only. In short: the mechanism is proven, the offering does not exist yet. If regional hosting is a requirement for you, tell us — that is a scoping conversation, not a checkbox.
Data handling
You can't leak what you never collected. Tasirio deliberately governs the permission graph — the thing that determines AI reach — while leaving your documents, email and messages where they are. Five connectors read record fields, content or where cardholder data sits because the check cannot exist without it, and we say which: Medius supplier bank-account numbers (stored masked) and addresses (stored only where two or more active suppliers share one but not a registration number), Softbase Evolution cardholder column names and row counts — never a cardholder value — for Notion pages you have Published to the web, the page body text, pattern-matched in memory with only the resulting labels stored, for Databricks, notebook and file source in Git-backed workspace folders, scanned in memory for credentials written into code with only the kind of credential and the file’s path stored, and, for a Smartsheet dashboard you have published, what its widgets show, which Smartsheet returns with the sheets and reports feeding it — only those are kept. 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. If you install our Shadow-AI DNS collector or send us your DNS logs, we also receive which public AI services your network looked up, from which address, device name or user name.
Compliance posture
Two things earn a security team's trust: how we run our own shop, and how well we help you evidence your AI footprint to your auditors. We're explicit about both — and we never conflate them. So here is our own status, stated plainly rather than implied.
Our security posture — the unflattering version
We publish a self-attestation mapped to SOC 2 controls. That is not a SOC 2 report and we will not let it be presented as one. A third-party penetration test is in progress; no report has been issued. If your security review asks, that is the answer, and you should have it from us rather than from the questionnaire. The controls above are real and you can test them; the certificates are not, and we are not going to imply a timeline we have not bought. Read the rest of what we are not, in writing, on our partner disclosures, and the legal detail in our DPA, sub-processor list, privacy policy and what you switch on.
Frameworks we help you meet
Standard and framework names are the property of their respective organizations and are referenced descriptively to indicate what Tasirio helps you assess. Tasirio is not affiliated with, endorsed by, approved by, or certified by any of them, and a Tasirio mapping is not a formal conformity assessment or certification.
What we don't claim
Any tool can produce a green dashboard by not looking. These are the rules that stop us doing it — they cost us favourable-looking numbers on purpose.
A control is reported clean only if the read demonstrably ran, the surface was attested by the connector, and a test has already proved that check can fire on a bad estate. Anything else is reported not assessed — a different sentence, and usually the honest one.
Some vendors put read-only data behind a scope whose name says "write". We tell you what it is, what it unlocks and what we still will not collect before you grant it. Decline it and those checks report NOT RUN rather than passing. Quietly not looking is not the same as looking and finding nothing.
Where an estate is too large to read exhaustively, the result says "we read 40 of 900" instead of presenting a sample as a verdict.
"This regulated data exists" and "this job function can reach it" are different claims, and we never let the first be sold as the second. Where the permission model we would need lives in a system we were not given, the finding says so.
Tasirio does not ingest the logs that record who opened, read or downloaded your data, so we cannot tell you a file was opened — and we refuse to infer it from a login timestamp. It is a capability we do not have, and saying so is more useful than the claim would have been. Four connectors read activity or history records, for narrow facts: Google Workspace reads its OAuth-token activity and its login warnings (a suspicious sign-in, an account disabled for a leaked password, a government-backed-attack warning); Salesforce reads its OAuth sign-in history, its Setup Audit Trail of the last 365 days (up to 2,000 entries, keeping only the security settings they mention), whether anyone signed in through SAML single sign-on in the last 90 days, and which View All Data or Modify All Data holders signed in with a password in the last 90 days (a finding names up to 25), and counts how many Leads and Cases created in the last 180 days came from the web (a count only); Snowflake reads its query history, searched in memory for AI fine-tuning, document-AI and agent statements — keeping only the object, role and stage names found, never the text or who ran it — and its load history; and John Deere reads each machine’s location history and device-state reports, keeping only how many machines report them. None of them says who opened which item.
Effective access is computed from the permission model. We never test it by acting as one of your users, and Tasirio never writes to, changes or remediates the configuration, permissions or records it reads — even where a system it governs is also where you send tickets. 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. Beyond reading, it writes only where you asked it to: the connector credential you provide, into a key vault (ours, or your own cloud vault); and, if you connect a ticketing system (Jira, ServiceNow, Zendesk, 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 our findings; and an alert webhook or Slack you add receives our alerts. 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. 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.
Deploy in minutes. Connect to your existing environment.
Nothing to install for cloud systems, and no changes to your infrastructure to deploy it — except by software you run yourself, in four places: on a Windows DNS server, the Shadow-AI DNS collector’s installer turns on DNS debug logging if it is off and puts your settings back when you uninstall (run it with -NoAutoEnableDnsLog and it leaves them alone); 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; Grant-TasirioDhcpRead.ps1, run on a separate DHCP server only if you want device names from it, adds the collector server to that server’s DHCP Users group (read-only); and the Microsoft 365 fix script, Remove-TasirioSharingLinks.ps1, removes the sharing links a work list names, signed in as your own administrator, only when you run it with -Apply.
Tasirio never modifies or changes the environment it governs, except that where a ticketing system you connect is also one it governs (ServiceNow and Zendesk can be both), it opens tickets there, sets their status and adds comments; and where your own cloud vault sits in a cloud account it governs, it writes your connector credentials and a test secret into that vault and can ask the vault to delete them. It writes only where you asked it to, and never to the configuration, permissions or records it reads: your connector credential into a key vault (ours, or your own cloud vault) — and, only where you connect one, tickets in your ticketing system, the findings it forwards to your SIEM or SOAR endpoint, and the alerts it posts 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. 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.
Configuration and permission metadata — who can reach what. Five connectors read record fields, content or where cardholder data sits because the check cannot exist without it; all five are named here. 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. If you install our Shadow-AI DNS collector or send us your DNS logs, we also receive which public AI services your network looked up. Your data stays where it is.
Microsoft 365, Google Workspace, AWS, Salesforce, ServiceNow, Okta, and more — see the full coverage list.
Connect your first platform and start seeing insights in minutes.
Every customer environment is logically isolated with enterprise-grade security.
Scan on demand, or on a schedule you set — with a diff against the last run and an alert if a scheduled scan fails to produce one.
Enterprise scale. Enterprise security. Enterprise support.
That's the Tasirio difference.
Tasirio turns AI sprawl into clarity, ownership, and proof so you can move fast—without taking risks.
Discover the AI systems your connected platforms report and map their access to sensitive data, users, and critical systems.
Every finding can be given an owner and a path to resolution.
Generate audit-ready evidence and reports that map to your policies and regulations.
See what moved since the last scan, and keep your evidence aligned with evolving laws, frameworks, and policies.
Reduce risk. Improve accountability. Gain confidence.
Build AI you can trust.