Signed download links
Every file that a member downloads from the dashboard is served through a short-lived signed link, never through a permanent storage link. The link is created at the moment you select Download, after Tars checks that the file belongs to your organization and that your role can read it. Anyone who gets hold of the link can use it only until it expires a few minutes later. The signed link covers these downloads:
If a link expires before the file saves, a toast reads Download link expired. Select Download again to get a fresh link. Conversation exports and transcripts are also transient files, so an old Download button can show Download unavailable once the file itself has been removed.
Each successful download is written to the audit log. The row reads that a member downloaded the file, with the file name, and the download therefore reaches SIEM destinations like every other audit event. See Search and export the audit log and Export conversations.
Redaction of tool execution logs
When an agent runs a toolkit action, Tars keeps an execution log with the input the agent sent and the output the provider returned. That log can hold sensitive values, for example the body of an email or a customer record. The Log privacy card lets you decide whether those values are stored at all. The card sits on the toolkit page, for example Tools, then Gmail, with a connection selected. The same card appears on every CodeKit toolkit page. Its text reads: Redact tool data in execution logs so sensitive inputs and outputs are never stored in plain text- The Enable redaction switch turns the feature on. On its own it redacts inputs and leaves outputs stored.
- The Redact inputs checkbox replaces the input of every logged execution with the text
[redacted]. - The Redact outputs checkbox does the same for the output. Tick both to store neither.
Encrypted secrets and one-time reveal
The Free plan card on the plan comparison lists Data encryption. Beyond that, the dashboard states how it treats each secret you hand it:
For the full flows, see Bring your own model key, Stream audit events to a SIEM, Write a custom action, and Verify end user identity.
Signed end user identity
Identity signing stops one end user from claiming another end user’s conversation history in the widget. Your server signs the identity of a signed-in end user with your organization’s key, and the widget accepts an identity only with a valid signature. Editing data in the browser cannot produce a valid signature, so an impersonation attempt lands in an anonymous conversation instead. The signing contract is in Identity signing. Key rotation, the OTP fallback, and profile merging are in Verify end user identity.Chat content safety
Chat content is sanitized before it is displayed, so markup or script inside a message does not run in the widget. PDF and other media attachments render inside an isolated frame. External links never open directly: the Open External Link dialog shows the destination first, and the end user chooses Copy Link or Open Link. The end user’s view of these controls is in End user experience.Framing rules for the dashboard and the chat host
Every dashboard page and every chat host page is served with a Content-Security-Policy header. Part of that policy states which sites may show the page inside an iframe. Another site therefore cannot wrap a Tars screen in its own page and overlay it.
The widget embed keeps working on your site because the chat and widget pages allow framing everywhere. See Iframe embed method for the direct iframe.
What this page does not cover
- Detecting and replacing personal data in end user messages: Personal data protection.
- How long records are kept, and what happens when the window ends: Data retention.
- Erasing an end user on request, and freezing records with a legal hold: Erasure and legal holds.
- How Tars staff get time-limited access to your organization: How Tars support accesses your org.