What you switch on

On this page

Part A — Off until you switch it on

• Connecting one of your systems
• Permissions whose names say more than reading
• Re-reading your systems on a schedule
• Deeper scans of Microsoft 365 and Smartsheet
• Telling Tasirio your Zendesk tickets hold regulated data
• Opening tickets in Jira, ServiceNow, Zendesk or Syncro
• Forwarding findings to your SIEM or SOAR
• Posting alerts to Slack, Teams or a webhook
• Email alerts
• Text-message (SMS) alerts
• Reports emailed on a schedule
• Share links to a report
• Your own key, or your own cloud vault, for connector credentials
• Installing a collector on your own server (Dynamics NAV, file shares)
• Installing the Shadow-AI DNS collector
• Letting your identity provider manage Tasirio users (SCIM)
• Copying a prompt that includes the resource name

Part B — On without a switch, or on by default

• A daily analysis of what Tasirio already holds
• The AI assistant, Ask Tasirio and the AI-leak simulation
• Deep scans of Dynamics NAV and Softbase Evolution
• Anonymous finding statistics and the peer benchmark
• A partner's access, if one is appointed over your organisation
• Tasirio staff opening your workspace

"What is recorded" names the entry written to your activity log, which you can export and verify. Approving or withdrawing a permission, making or revoking a share link, and changing which alerts or reports a recipient gets are saved together with their entry, so one never happens without the other. For the other settings, if the entry cannot be written, the change can still stand, and the failure is recorded in Tasirio's own error log.

How this list is kept in step with the product: a check in our build compares this list, and the defaults it states, with what it reads in ten places in our code — the vendor permissions named for more than reading; the code that sends to an address you give us through Tasirio's one sending function; the alerts, and which of them start on; the changes to where findings, alerts and reports are sent that ask for a fresh second-factor check; the choices on each Connect form, and their defaults; the on/off columns of the SIEM export and of the scan schedule, as our database migrations define them, and their defaults; the lowest severity the SIEM export starts with; the John Deere sign-in options, and their defaults; and, in our on-premises installers, the switches that take no value and the collection schedule and check-in interval each one sets. That check is not exhaustive: it reads only those places, and only in the forms it recognises. Everything else in this list is kept in step by review.

Part A — Off until you switch it on

Nothing in this part happens until someone acts — someone in your organisation; a partner (reseller or managed-service provider) you appointed with Manage access, where an entry says a partner can; or a Tasirio administrator (see "Tasirio staff opening your workspace" in Part B). Inside your workspace a Tasirio administrator acts with an Owner's capabilities, so they can switch on the settings in Part A there, except where a setting needs something support access does not give them, for example: installing a collector needs administrator rights on your server, confirming a text-message number needs the code sent to that phone, and approving a permission whose name says more than reading needs an Owner member of your organisation; they can also withdraw an approved permission. Each entry says who can act, and what is recorded when they do.

Connecting one of your systems

Tasirio reads nothing from a system until it is connected — by someone in your organisation, or by a partner you appointed with Manage access.

• Until you act: Nothing is connected.
• Where: Platform → Connectors.
• Who can switch it: An Owner. A partner (reseller or managed-service provider) with Manage access over your organisation can also connect a system, but cannot remove one: only an Owner can remove a connection.
• What Tasirio reads: That system's configuration and permission model, using the credential you create for Tasirio. Some connectors also read more than that — record fields, content, where cardholder data sits, or activity or history records; section 5 of the Data Processing Addendum lists them.
• What it shows: Findings about that system, to everyone in your organisation who can open the dashboard, and to the staff of a partner appointed over your organisation.
• What it writes or sends: Stores the credential you supply in a key vault — or, under the customer-key option, in Tasirio's database encrypted under your key. No Tasirio connector writes, changes, or deletes anything in the system it reads. 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.
• What is recorded: Your activity log records who connected it, when, and the choices made on the Connect form, such as the scan depth (connector_connected); and each completed sync after that. Removing it is recorded too.

Permissions whose names say more than reading

A few vendors put data Tasirio must read behind a permission named for writing or managing, with no read-only version. Tasirio uses such a permission only after an Owner member of your organisation approves it in Tasirio — Tasirio staff cannot approve it through their support access. Tasirio's code still only reads.

• Until you act: Off. Each one needs two separate acts: you grant it in the vendor's system, and an Owner approves it in Tasirio. Granting it in the vendor alone is never taken as approval.
• Where: Platform → Connectors, on the connection's approval card. Withdraw it on the same card.
• Who can switch it: An Owner approves: a person who is an Owner member of your organisation in Tasirio. A partner cannot approve, and Tasirio staff cannot approve through their support access: a Tasirio administrator who is not an Owner member of your organisation is refused. Giving someone the Owner role after your organisation is created — directly, through a group, or by an invitation — is written to your activity log (as for the other settings, if the entry cannot be written, the change can still stand, and the failure is recorded in Tasirio's own error log). A partner with Manage access, or a Tasirio administrator, can withdraw an approval — which stops the reads it unlocked: for Box, DocuSign, Oracle Fusion and Business Central every read from that system, and for Microsoft 365 every sync while the permission is still granted in Microsoft.
• What Tasirio reads: More from that one vendor — what each permission unlocks is listed below and shown on the approval card before you approve.
• What it shows: Findings from the extra reads.
• What it writes or sends: Nothing. The connector still sends read requests only.
• What is recorded: For an approval: who approved it, when, and the exact text they were shown. For a withdrawal: who withdrew it and when. Both are kept with the connection's approvals (app.scope_acknowledgements) and written to your activity log (elevated_scope_acknowledged, elevated_scope_withdrawn).

• Microsoft 365 — Sites.FullControl.All: lets Tasirio list which apps hold access to each SharePoint site. If it is granted in Microsoft but not approved in Tasirio, Tasirio refuses to sync Microsoft 365 at all. If it is not granted, site app access is simply not read.
• Google Workspace — admin.directory.user.security: lets Tasirio read third-party app tokens, app-specific passwords and how many backup codes each user holds. Without approval those reads are skipped and their checks report "not assessed".
• HubSpot — tickets and files (files.read): the ticket property list with counts of filled-in fields, and which File Manager files are public. Without approval those checks report "not assessed".
• Box — manage_managed_users: the list of users in your Box enterprise. Required: without approval Tasirio reads nothing from Box.
• DocuSign — signature: the account's users and its Connect (webhook) settings. Required: without approval Tasirio reads nothing from DocuSign.
• Oracle Fusion — the identity-integration REST privilege: the list of roles. Required: without approval Tasirio reads nothing from Oracle Fusion.
• Business Central — user_impersonation: the permission model through the Automation API. Required: without approval Tasirio reads nothing from Business Central.
• Azure AI Foundry — the Defender CSPM role: the lists of AI agents and assistants. Without approval the two agent checks report "not assessed"; the other Foundry checks still run.
• John Deere — eq1 (equipment and where it has been), files (which files exist and how they are shared) and ag3 (every file type; John Deere grants MANAGE access to fields and production data with it). On the John Deere sign-in: Organizations & partners is always asked for; Fields, field operations, products & operators, Equipment & machine locations and Uploaded files are ticked by default; All file types (ag3) is off by default; the asset list (eq2) is not offered in this release. Connect stays disabled until each chosen permission is approved. org2 and eq2 are approved only where an existing John Deere credential already holds them; Tasirio's own reads do not need org2.

Re-reading your systems on a schedule

This entry is about the systems Tasirio reads from its own service — every connection except the ones a collector on your own server feeds, which run on that collector's schedule (see the two collector entries). Tasirio re-reads such a system only when someone asks — Sync now on that connection, or re-verifying a finding as fixed, which re-reads every connection Tasirio pulls from — unless you set a schedule. There are two separate schedules.

• Until you act: Off. Each such connection's auto-sync is Manual, and the Re-sync button on the Dashboard (re-read every connection Tasirio pulls from before each scheduled scan) is off.
• Where: Auto-sync: Platform → Connectors, per connection (Manual, Daily, Weekly or Monthly). Re-sync before each scan: the Re-sync button on the Dashboard's Continuous monitoring card.
• Who can switch it: Auto-sync: an Owner. A partner with Manage access can turn Manual into a schedule or make it more frequent, but cannot switch it back to Manual, make it less frequent, or pause the connection. Re-sync before each scan: an Owner.
• What Tasirio reads: Your connected systems, on the schedule you set.
• What it shows: Up-to-date findings.
• What it writes or sends: Nothing by itself. But a scan that follows a re-read of every connection — because re-sync is on, or because someone re-verified a finding — reopens the ticket of a finding someone marked fixed that is still present (see the ticketing entry), and sends what you switched on for new findings.
• What is recorded: A connection's cadence change is in your activity log with the old and new values (connector_settings_changed). Turning re-sync on or off is in your activity log (monitor_config_updated).

• Sync now: an Owner, or a partner with Manage access, on Platform → Connectors. An Admin or Analyst can start the same read through the Tasirio API.
• Re-verifying a finding: anyone who can work on findings — an Owner, Admin, Compliance or Analyst user, or a partner with Manage access.

Deeper scans of Microsoft 365 and Smartsheet

Two connectors read a sample by default and read more only if you choose a deeper scan.

• Until you act: Microsoft 365: Standard (directory, site-level sharing and the sharing of up to 400 files). Smartsheet: Standard (about 1,500 sheets).
• Where: The scan-depth choice on the Connect form, or in the connection's settings on Platform → Connectors.
• Who can switch it: An Owner. A partner with Manage access can choose a deeper scan, but cannot make one shallower.
• What Tasirio reads: Microsoft 365 Deep: the sharing of up to 3,000 SharePoint and OneDrive files (at most 375 from any one site). Microsoft 365 Full (Enterprise plan): the sharing of every file, read in stages of about an hour until every site is read. Either way, file names and who can open them, never what is in them. Smartsheet Full (Enterprise plan): every sheet and dashboard.
• What it shows: Findings about the extra files and sheets.
• What it writes or sends: Nothing.
• What is recorded: Your activity log records the change, with the old and new depth (connector_settings_changed); the depth chosen when connecting is recorded with the connection (connector_connected).

Telling Tasirio your Zendesk tickets hold regulated data

Tasirio never reads ticket bodies, so it cannot tell whether card numbers or other regulated data are in them. Answering yes turns on three checks that only matter when they are.

• Until you act: No / not sure. The three checks are then reported "not assessed", never clean.
• Where: The Connect form for Zendesk. It cannot be changed on an existing connection: to change it, the connection must be removed and connected again — removing it deletes what that connection collected.
• Who can switch it: Answering it: whoever connects Zendesk — an Owner, or a partner with Manage access. Changing it later needs the connection removed, which only an Owner can do.
• What Tasirio reads: Nothing more.
• What it shows: Three more checks: card redaction switched off, public ticket attachments, and Agent Copilot reaching those tickets.
• What it writes or sends: Nothing.
• What is recorded: Your answer is written to your activity log with the connection (connector_connected), and kept in the connection's settings.

Opening tickets in Jira, ServiceNow, Zendesk or Syncro

Tasirio writes tickets into your ticketing system only after an Owner connects it. Once connected, some of those writes happen without a further click.

• Until you act: Off. No ticketing system is connected.
• Where: Governance → Remediation → Ticketing & SLA.
• Who can switch it: An Owner connects it; a new destination asks for a fresh second-factor check. Once it is connected, anyone who can work on findings (Owner, Admin, Compliance, Analyst, or a partner with Manage access) can open tickets.
• What Tasirio reads: The status of tickets linked to findings — after each scan, and when someone clicks Sync ticket statuses. When someone assigns a finding's owner, it also looks people up in your ticketing system's user list (names and email addresses).
• What it shows: The ticket status next to the finding.
• What it writes or sends: Writes into your ticketing system: it creates a ticket when someone clicks Create ticket (up to 200 at once). After that, without a further click: it sets the ticket's status when the finding's status changes in Tasirio, and it reopens the ticket and adds a comment when a scan after every connection was re-read finds a finding marked fixed still present. When someone re-verifies a finding, it adds a comment saying what the re-check found, and reopens the ticket if the finding is still present. A Slack or generic webhook can be chosen instead; it receives one message per finding with the finding's title, type, resource name, severity and description as written (for a file share these name the server and folder), but not the separate location, object id or Open link, and nothing is updated there afterwards. A ticket carries the finding's title, type, resource name, severity and description and, where Tasirio recorded it, where the object is, its id and the vendor's own address that opens it.
• What is recorded: Connecting it or changing it is in your activity log with the destination's host (remediation_integrations_updated). The ticket reference is stored on the finding; the activity log does not name who opened each ticket.

Forwarding findings to your SIEM or SOAR

Tasirio sends findings to Splunk, Microsoft Sentinel or another endpoint only after an Owner sets it up. Once it is on, sending after each scan is on too unless you untick it.

• Until you act: Off: the export is not switched on. When you switch it on, "Auto-push new findings after each scan" is already ticked, and the lowest severity sent is High.
• Where: Governance → Monitoring → SIEM / SOAR export.
• Who can switch it: An Owner. A new endpoint or token asks for a fresh second-factor check.
• What Tasirio reads: Nothing more.
• What it shows: Nothing more.
• What it writes or sends: Sends findings at or above the severity you chose, decrypted. With Auto-push ticked, this happens automatically after every scan — scheduled, Run now, or a re-verify — that raises new findings or a compliance regression; that push carries each one's title, type, severity and resource name, not its description. Export current findings, and the test send, carry each finding's full description too. Where Tasirio recorded where a finding's object is, every finding sent also carries that location, the object's id and the vendor's own address that opens it.
• What is recorded: Changing the export, including ticking or unticking Auto-push, is in your activity log with the destination's host (siem_config_updated); a test send (siem_test_sent) and each push (siem_export_run) are too.

Posting alerts to Slack, Teams or a webhook

Tasirio posts an alert to a chat channel or webhook only after an Owner enters its address and that alert is switched on for it.

• Until you act: Off. No webhook address is set. When the first address is saved, four alerts are switched on for it: a scheduled scan did not run; new exposures found; a compliance control regressed; a connected system went dark.
• Where: The address: Governance → Monitoring → Webhook URL. Which alerts it gets: the four above, switched on when the first address is saved; there is no setting on a page to change them yet — an Owner can through the Tasirio API (the "webhook" target of the notification subscriptions), and a later save of the address does not switch back on an alert that was switched off.
• Who can switch it: An Owner. A new address asks for a fresh second-factor check.
• What Tasirio reads: Nothing more.
• What it shows: Nothing more.
• What it writes or sends: Sends the text of each alert switched on for it to that address — for new findings, counts only — how many, by severity and by check — never which object a finding is about, where it is or an address that opens it. The alerts switched on for the webhook stay switched on when the address is changed: from then on they go to the new address.
• What is recorded: Changing the address is in your activity log with its host, never the full address (monitoring_destination_changed or monitor_config_updated); changing its alerts is too (notification_subscriptions_updated). Each send is in the delivery history.

Email alerts

Tasirio emails alerts only to people an Owner adds as recipients. A new email recipient starts with four alerts already on.

• Until you act: No recipients. When you add one with an email address, these are switched on for them straight away: a scheduled scan did not run; new exposures found; a compliance control regressed; a connected system went dark. These start off: a connected system came back; a scheduled analysis ran; a connector finished syncing; an on-prem collector has an update.
• Where: Governance → Monitoring → Who gets notified. Each alert can be switched off per person. An address typed into the "Alert email" box higher on the same page is added as a recipient with the same four alerts on.
• Who can switch it: An Owner. Adding an email address asks for a fresh second-factor check. A recipient can unsubscribe themselves from the email; adding them back is then refused unless an Owner deliberately overrides it, and the override is recorded.
• What Tasirio reads: Nothing more.
• What it shows: Nothing more.
• What it writes or sends: Sends emails through our email provider (Brevo, in the European Union). A new-findings alert carries counts only — how many findings, by severity and by check — never which object a finding is about, where it is or an address that opens it; its link opens the list in Tasirio.
• What is recorded: Adding a recipient is in your activity log with the email domain and how many alerts were switched on for them (notification_recipient_added). Changing a recipient's alerts is too (notification_subscriptions_updated). Each email is in the delivery history.

Text-message (SMS) alerts

Tasirio texts an alert only to a mobile number that has been verified and switched on for that alert.

• Until you act: Off. A number receives nothing until the 6-digit code sent to it is entered in Tasirio, and an alert is switched on for texts. Text messages must also be available for the service; the page says when they are not.
• Where: Governance → Monitoring → Who gets notified.
• Who can switch it: An Owner adds the number. The code is sent to that phone; an Owner enters it in Tasirio.
• What Tasirio reads: Nothing more.
• What it shows: Nothing more.
• What it writes or sends: Sends a headline only — never a resource name or a finding title — and only for the four "something went wrong" alerts.
• What is recorded: When the number was verified; each text is in the delivery history with the number masked.

Reports emailed on a schedule

Tasirio emails a report on a schedule only if an Owner switches it on for a recipient. Each email carries a link that opens the report without signing in.

• Until you act: Off for every report: Owner's Playbook, Executive / Board report, Governance report, Cyber-insurance readiness and Evidence pack.
• Where: Governance → Monitoring → Who gets notified, per recipient (Weekly, Monthly or Quarterly).
• Who can switch it: An Owner. Adding a report asks for a fresh second-factor check.
• What Tasirio reads: Nothing more.
• What it shows: The report, to anyone who holds the emailed link, without signing in, until the link expires (14 days for a weekly report, 38 for monthly, 98 for quarterly). The evidence pack holds every finding.
• What it writes or sends: Sends an email each period with the link. For an evidence pack, Tasirio also keeps an encrypted copy so the link opens quickly (see the retention schedule in the Data Processing Addendum).
• What is recorded: Switching a report on is in your activity log (notification_subscriptions_updated). Each link is recorded as made by the schedule, and each email is in the delivery history.

Share links to a report

A share link lets someone open one report without signing in — for an auditor, a broker or a board member. None exists until someone makes one.

• Until you act: No links.
• Where: The Create share link button on a report page (for example Owner's Playbook, Board Report, AI Assessment, Insurability, Governance). Revoke a link from the same place.
• Who can switch it: An Owner, Admin or Compliance user. A partner cannot. Making a link asks for a fresh second-factor check.
• What Tasirio reads: Nothing more.
• What it shows: That one report, to anyone who holds the link, until it expires or is revoked.
• What it writes or sends: Nothing is sent. For an evidence pack, Tasirio keeps an encrypted copy so the link opens quickly; it is deleted when the last link is revoked.
• What is recorded: Making and revoking a link are in your activity log, written together with the link itself (report_share_created, report_share_revoked).

Your own key, or your own cloud vault, for connector credentials

You can choose to hold the key that protects your connector credentials, or keep the credentials in your own cloud vault.

• Until you act: Off. Credentials are kept in Tasirio's key vault.
• Where: Access → Security → Bring your own key — connector secrets.
• Who can switch it: An Owner.
• What Tasirio reads: Nothing more.
• What it shows: Nothing more.
• What it writes or sends: Under the customer-key option, your connector credentials are stored in Tasirio's database encrypted under your key. Under your own cloud vault, Tasirio writes your connector credentials into your vault (Azure Key Vault, AWS Secrets Manager, Google Secret Manager or Oracle Vault) with the access you grant. Tasirio updates a credential there when the vendor renews its token, and deletes it there when you remove the connection, when you replace that connection's credential, or when you move your credentials out of that vault. When you point Tasirio at your own cloud vault, it writes a test secret named tasirio-access-probe to prove it can reach the vault, reads it back, then asks your vault to delete it: AWS Secrets Manager and Google Secret Manager delete it straight away, Oracle Vault schedules the deletion about a day later, and Azure Key Vault keeps it soft-deleted for your vault's retention period. If the delete fails, cannot be asked, or the check stops before it, the test secret stays in your vault.
• What is recorded: Every change is in your activity log (byok_backend_changed, byok_key_rotated, byok_disabled); an attempt that failed and changed nothing is recorded as byok_change_failed.

Installing a collector on your own server (Dynamics NAV, file shares)

For systems behind your firewall, a small collector runs on your own server and sends what it reads out to Tasirio. Nothing is read until you install it. Once installed, it collects on its own schedule — once a day unless you set another — and checks in with Tasirio every minute.

• Until you act: Not installed.
• Where: Dynamics NAV: download the package from Platform → Connectors and run the installer on your server. File shares: Tasirio staff enrol the collector with you; the installer shows you what it would send and asks "Send this to Tasirio and schedule the agent? (y/N)" before anything is sent. When it updates a file-share collector whose earlier install on that server finished, it keeps that server's saved settings (which shares, the limits) and first asks whether to show that preview again (default No); answering No sends the new version's first read without a preview, as the installed collector already did on its schedule, after saying what the new version sends that the installed one did not. A preview shown there and not approved is shown again the next time the installer runs.
• Who can switch it: Dynamics NAV: an Owner downloads the package; someone with administrator rights on your server runs it. File shares: Tasirio staff create the enrolment; your administrator runs the installer.
• What Tasirio reads: Dynamics NAV: the permission model, with a read-only database login that Tasirio never receives: you type it on the setup page, your browser writes it into the downloaded package, and the agent keeps it on your server. File shares: share and folder permissions, group membership, and file and folder names, plus the size and last-modified date of files whose names suggest sensitive data — never what is in a file; no file is ever opened.
• What it shows: Findings about those systems.
• What it writes or sends: Sends what it read, outbound only. Once installed, Tasirio can ask it to collect now: an Owner, or a partner with Manage access, uses Verify / Run now on Platform → Connectors, and an Admin or Analyst can ask the same through the Tasirio API.
• What is recorded: Issuing the collector's token is in your activity log (agent_token_issued). For file shares, your yes/no at the installer is not recorded in Tasirio; -SkipDryRun (Windows) or --yes (Linux) skips that question, and on an update -Preview (Windows) or --preview (Linux) shows the preview without asking.

• Its schedule: it collects every 1,440 minutes (once a day), unless the downloaded package or the installer's -IntervalMinutes (Windows) or --interval-minutes (Linux and macOS) sets another cadence. Choosing "Manual / one-off" when downloading the Dynamics NAV package still installs the daily run. On Linux and macOS, --no-schedule installs it with no schedule; the Windows installers always schedule it. To change the schedule, run the installer again with another value, or change the scheduled task (Windows) or the cron or launchd entry (Linux and macOS) it created.
• It also checks in with Tasirio on a 1-minute check-in, to ask whether someone pressed Verify / Run now; each check-in sends the server's computer name and the collector's version.
• The auto-sync choice on Platform → Connectors does not apply to a connection a collector feeds: Tasirio refuses a pull schedule for it, because how often it runs is set where it is installed.

Installing the Shadow-AI DNS collector

The DNS collector tells you which public AI services your network looked up. On a Windows DNS server, its installer turns on DNS debug logging there unless you tell it not to. Once installed, it collects every hour unless you set another schedule, and checks in with Tasirio every minute.

• Until you act: Not installed.
• Where: Download the package from Platform → Connectors and run the installer on your DNS server.
• Who can switch it: An Owner downloads the package; someone with administrator rights on the DNS server runs it.
• What Tasirio reads: Your DNS server's log, read-only. The installed collector drops lookups of hosts that are not AI services on your server; they are never sent. To name the addresses it reports, it also lists — on a Windows DNS server, read-only — that server's DHCP leases (or those of the DHCP server you name with -DhcpServer) and its own DNS A records, and asks reverse DNS; the lease list and the records themselves are never sent.
• What it shows: The Shadow AI page lists each AI service looked up, how often, and every address that looked one up with its device name (and how many of the addresses have a name) — to everyone who can open the dashboard, including the staff of a partner appointed over your organisation; a Shadow-AI finding's page lists the addresses that looked its service up, with their device names. Each Shadow-AI finding names up to five of the device names, addresses or user names seen, and so does a finding about an AI tool found in one of your connected systems whose name matches a service your DNS shows was looked up — which also lists up to 50 of them, with the tool's owner, as people to ask about it — so a device name such as "Johns-iPhone" can appear in a finding's description, and in what carries descriptions, such as a SIEM export or an evidence pack.
• What it writes or sends: On a Windows DNS server it changes your DNS settings: if DNS debug logging is off, the installer saves your current settings and turns it on — it sets the log file's path, a maximum log size of 500,000,000 bytes (about 500 MB), log-file rollover off, and which packets are logged (incoming queries over UDP and TCP; not outgoing packets or answers); uninstalling puts the saved settings back; -NoAutoEnableDnsLog tells it not to touch them. The Linux and macOS installer changes no DNS setting. Sends, for each lookup of a known AI service: the name looked up, the address that looked it up, that address's device name when one is found — from your DHCP leases, your DNS server's own A records or reverse DNS (often a computer or phone name, which can include a person's name) — and a count; with each upload, how many of its addresses have a name, and the error a name source gave when it could not be read, and the DHCP server named with -DhcpServer, if any; plus the DNS server's host name and, on Windows, its computer name (from version 1.3.1), which Tasirio puts into the commands it shows. -ClearDhcpServer (Windows) removes a DHCP server named earlier. -NoDeviceNames (Windows), or DEVICE_NAMES set to off in the collector's config.json, sends the addresses with no names and reads none of the three. Grant-TasirioDhcpRead.ps1, which someone with administrator rights runs on a separate DHCP server only if you want names 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. Tasirio keeps the AI service's name (not the full hostname), the address, its name, the count and the dates reported.
• What is recorded: Issuing the collector's token is in your activity log (agent_token_issued). The DNS settings saved before the change stay on your server, in the install folder.

• If you send cloud or security-service DNS logs instead of installing the collector (AWS Route 53, Google Cloud DNS, Azure DNS, Cisco Umbrella, Zscaler, Netskope, Cloudflare Gateway), your export sends Tasirio the raw log records — every lookup, including lookups of other hosts, with the address, user or device each names. Tasirio keeps only the lookups of known AI services and discards the rest in memory before anything is stored. A kept record with no address is kept under the user name, email, device name or identity that service records.
• Removing the collector does not delete what it already sent. Removing your last DNS connection on Platform → Connectors does.
• Its schedule: it collects every 60 minutes, unless the Collect every (min) value in the downloaded package or the installer's -IntervalMinutes (Windows) or --interval-minutes (Linux and macOS) sets another cadence. On Linux and macOS, --no-schedule installs it with no schedule; the Windows installer always schedules it. To change the schedule, run the installer again with another value, or change the scheduled task, cron or launchd entry it created. The auto-sync choice on Platform → Connectors does not apply to it.
• Device names come from the collector version 1.3.0 and later; an earlier collector asks reverse DNS only. The name shown is the one the address had at its latest lookup — earlier lookups from the same address may have come from another device, because a DHCP address moves — and an address that looked up an AI service before its name could be found keeps no name until it looks one up again. Naming from another DHCP server also needs the DHCP Server tools for PowerShell on the DNS server (Install-WindowsFeature RSAT-DHCP). A new package keeps -NoDeviceNames and -DhcpServer from the installed collector.
• It also checks in with Tasirio on a 1-minute check-in, to ask whether someone pressed Verify / Run now; each check-in sends the DNS server's host name, on Windows its computer name (from version 1.3.1), and the collector's version.
• From version 1.3.1, a collection run that finds no AI lookup sends one check-in saying when it read the log (a timestamp, nothing from the log), so Tasirio can tell a quiet network from a collector that stopped and close a Shadow AI finding once no device has looked the service up for 7 days.

Letting your identity provider manage Tasirio users (SCIM)

A SCIM token lets your identity provider create, change and deactivate people in Tasirio for you.

• Until you act: No token. There is no page for this; it is set up through the API.
• Where: The Tasirio API (POST /api/scim/token).
• Who can switch it: An Owner, with a fresh second-factor check.
• What Tasirio reads: Nothing from your systems.
• What it shows: Nothing more.
• What it writes or sends: Your identity provider can create, change and deactivate Tasirio users — including the last Owner. When that leaves no Owner, it is written to your activity log and Tasirio is alerted.
• What is recorded: Issuing and revoking the token are in your activity log (scim_token_issued, scim_token_revoked).

Copying a prompt that includes the resource name

A finding can be copied as a prompt to paste into your own AI assistant. The resource name is left out unless you choose to include it.

• Until you act: Left out.
• Where: The finding's detail panel: "include the resource name".
• Who can switch it: Anyone who can see the finding.
• What Tasirio reads: Nothing more.
• What it shows: The resource name in text you copy.
• What it writes or sends: Nothing. Tasirio sends nothing; you paste it yourself.
• What is recorded: Not recorded.

Part B — On without a switch, or on by default

These are listed so this page cannot be read as "everything is opt-in". Each is on without anyone switching it on, or on by default.

A daily analysis of what Tasirio already holds

Every organisation is placed on a daily scan that re-analyses data already held. It does not re-read your systems unless you turn re-sync on.

• As it stands: On, daily.
• Where: Governance → Monitoring: untick "Continuous monitoring" to stop it; Re-scan cadence sets how often.
• Who can switch it: An Owner.
• What Tasirio reads: Nothing new from your systems — except the status of tickets linked to findings, if you connected ticketing.
• What it shows: Updated findings.
• What it writes or sends: Whatever you have switched on above: alerts to your recipients and webhook, and new findings to your SIEM.
• What is recorded: Switching it off or on, or changing how often it runs, is in your activity log (monitoring_schedule_changed, or monitor_config_updated from the Dashboard card). Who last changed it is also kept with the schedule.

The AI assistant, Ask Tasirio and the AI-leak simulation

There is no switch to turn AI off for your organisation. Nothing is sent to the AI provider unless a person clicks the assistant, asks a question, or runs the simulation on the Dashboard.

• As it stands: Available. Used only per click.
• Where: Not switchable. "✨ Walk me through fixing this" in a finding's detail panel; Overview → Ask Tasirio; the Dashboard's "Try it: what would an AI assistant leak?" card.
• Who can switch it: The assistant: anyone who can work on findings (Owner, Admin, Compliance, Analyst, or a partner with Manage access). Ask Tasirio: anyone who can open the dashboard, partners included. The simulation: an Owner, Admin or Analyst, or a partner with Manage access.
• What Tasirio reads: Nothing more.
• What it shows: The answer, to the person who asked.
• What it writes or sends: The assistant sends the finding's type, severity, resource name and description as written — not redacted — plus any question typed, to Tasirio's own Azure OpenAI service. Ask Tasirio sends the question with finding types and counts, never resource names or descriptions. The simulation sends the question typed and the names of up to 60 SharePoint and OneDrive files the chosen person can reach, each with a sensitivity label worked out from its name — names only.
• What is recorded: Not in the activity log.

Deep scans of Dynamics NAV and Softbase Evolution

For these two connectors the deeper scan is the default.

• As it stands: Dynamics NAV: Deep — it also reads each company's change log, job queue and published web services. Softbase Evolution: Deep — it also counts the rows in tables that hold regulated data (a count, never a value).
• Where: The scan-depth choice on the connection (Fast reads less).
• Who can switch it: An Owner. A partner with Manage access cannot switch either to Fast, which is the shallower scan.
• What Tasirio reads: As above.
• What it shows: Findings from those reads.
• What it writes or sends: Nothing.
• What is recorded: A change is in your activity log with the old and new depth (connector_settings_changed).

Anonymous finding statistics and the peer benchmark

Tasirio keeps a record of finding activity with no names, resources or accounts in it and, while your account exists, a reference to your organisation, and uses it for product statistics and the peer benchmark. There is no opt-out.

• As it stands: On for every organisation.
• Where: Not switchable.
• Who can switch it: No one.
• What Tasirio reads: Nothing more.
• What it shows: A benchmark figure only where at least five other organisations are in the comparison.
• What it writes or sends: Nothing that identifies your organisation leaves Tasirio. Aggregate figures derived from it — the peer benchmark, and statistics about the product that Tasirio may publish — never identify a customer.
• What is recorded: Section 6.3 of the Data Processing Addendum describes it.

A partner's access, if one is appointed over your organisation

If you are served through a reseller or managed-service provider, its staff can see your findings and audit log and export evidence packs. When the appointment is made, it carries Manage access unless reduced.

• As it stands: Manage access: the partner can also connect systems, choose a deeper scan or a more frequent auto-sync, start scans, cancel a running scan, withdraw an approved permission and work on findings. It cannot remove a connection, pause one, switch its auto-sync to Manual or less frequent, or make a scan shallower.
• Where: Access → Partner — you can ask Tasirio to remove the partner, move to another, or reduce them to view-only. Tasirio approves the change.
• Who can switch it: You request it; Tasirio decides.
• What Tasirio reads: What a connection reads, if the partner connects one.
• What it shows: Your findings, audit log and evidence packs, to the partner's staff.
• What it writes or sends: Nothing by itself. A partner cannot set up ticketing, a SIEM, alerts, share links, your own key, or approve a permission. A partner with Manage access can withdraw an approved permission, which stops the reads it unlocked — for Box, DocuSign, Oracle Fusion and Business Central every read from that system, and for Microsoft 365 every sync while the permission is still granted in Microsoft — and can cancel a queued or running scan (the part already running finishes first) or a paused one, which discards its place.
• What is recorded: Partner staff opening your workspace is in your activity log, naming the person and giving the partner's Tasirio id — about once an hour for each person while they are in it, not once per thing they look at (a restart or a second Tasirio server can add a row, never remove one).

Tasirio staff opening your workspace

Today a Tasirio administrator can open your workspace for support without your approval, and inside it acts with an Owner's capabilities. A switch for you to control this is built, but it is not yet in force.

• As it stands: Staff can enter. Every entry is written to your activity log.
• Where: Access → Security → Tasirio support access — you can open access with a reason and a time limit (7 days unless you choose up to 30) and close it again. Until Tasirio turns enforcement on, closing it does not keep staff out, and the page says so.
• Who can switch it: An Owner. Opening access asks for a fresh second-factor check and a reason; closing it does not.
• What Tasirio reads: Nothing from your systems.
• What it shows: Your workspace, to the Tasirio staff member who enters.
• What it writes or sends: Nothing by itself. Inside your workspace a Tasirio administrator acts with an Owner's capabilities, so they can switch on the settings in Part A there, except where a setting needs something support access does not give them, for example: installing a collector needs administrator rights on your server, confirming a text-message number needs the code sent to that phone, and approving a permission whose name says more than reading needs an Owner member of your organisation; they can also withdraw an approved permission. An approval records who approved it, when and the exact wording they were shown, and giving someone the Owner role after your organisation is created — directly, through a group, or by an invitation — is written to your activity log (as for the other settings, if the entry cannot be written, the change can still stand, and the failure is recorded in Tasirio's own error log). Opening the support-access switch is also yours alone; they can only close it.
• What is recorded: Each staff entry is in your activity log, naming the person — about once an hour for each person while they are in it, not once per thing they look at (a restart or a second Tasirio server can add a row, never remove one). A change they make is recorded like anyone's — as that setting's entry says — under their Tasirio user id; the entry written when they open your workspace gives their name beside that id. Opening access is recorded as support_access_granted and closing it as support_access_revoked.