Administration
Consent policy, conversation oversight, topic trends, file rules and limits, link previews, audit events, and billing for Chat.
This page is for org admins. It covers what you can observe and control for Chat across your org.
Consent policy
Before using Chat, each member accepts a consent notice that covers conversational AI data use. Chat stores messages and builds semantic embeddings to power conversation search and automatic recall.
Revoking consent — a member can revoke consent at any time from their account settings. Revoking consent removes:
- The member's semantic conversation embeddings (used for recall and search).
It does not delete the raw conversation messages themselves (which remain available for oversight per your retention policy).
Admin view — org admins can see the consent status of all members. Consent status is visible to workspace admins.
Conversation oversight
Org admins have metadata-level visibility into conversations in the workspace. This includes:
- Conversation ID, creation time, and last-active time.
- Member who owns the conversation.
- Model used per conversation.
- Conversation status.
Conversation lists show metadata only; access to message content is restricted and audited. Full audit trail is in the audit events (see below).
For your organization's detailed data handling and retention commitments, see your Scrydon agreement and the Compliance section of these docs.
Topic trends
The Chat → Admin → Topics dashboard (/admin/topics) shows weekly topic aggregates across your org's conversations. Topics are extracted from conversations by the organization's configured model and do not expose individual message text. Use this to understand what your team is asking Chat about at a high level.
Topics are extracted hourly.
File rules and limits
Org admins decide which files people can send in the Matrix workspace and how large they can be. Open Settings → Cortex → Settings. The Cortex group appears in Settings for org admins only.
| Setting | What it does | Default |
|---|---|---|
| Unscanned files in internal rooms | Allow files that cannot be scanned, such as videos, archives and unrecognized files, in rooms where everyone is from your organization. Readers see them marked Not scanned. | On |
| Unscanned files in shared rooms | Allow the same files in rooms that people from another server are in or can join. | Off |
| Largest file | The largest file, image or recording anyone can send, in MB (1 to 64). | 32 MB |
| Largest video | The largest video anyone can send, in MB (1 to 64). | 64 MB |
Select Save. The new rules apply to files sent after you save; files already in a conversation are not touched. A limit must be a whole number of MB from 1 to 64. 64 MB is the most Cortex can send and cannot be raised.
Unscanned files. A file is unscanned when nothing could read it: a kind Scrydon does not read (a video, an archive, an unrecognized file), or a kind your organization has no reader configured for (no document reader, no text recognition for images, no transcription for audio). Nothing checks its contents, so your DLP policy is not applied to it, and every reader sees it labelled Not scanned. Turn a setting off and an unscanned file is refused in that kind of room, and the sender is told that nothing could scan the file and the organization does not allow unscanned files in the conversation. Files Scrydon can read are not affected by these two settings: they are always checked against your DLP policy.
Internal and shared rooms. A room is shared when someone from another server is in it, or when it is open to other servers (federated). Every other room is internal. The decision is made by the platform when the file is uploaded, never by the sender's app, and when it cannot be made the room counts as shared. The defaults allow unscanned files internally and refuse them in shared rooms, so a file nobody read does not leave your organization unless you allow it.
Size limits. The video limit applies to files whose contents are video, and the file limit to everything else. Scrydon judges a file by its contents, so renaming a file does not move it to the other limit. The limits do not apply to members who upload with a different Matrix app: those uploads go straight to your homeserver and are held only to its own upload limit, 64 MB in a standard installation.
DLP. A file Scrydon can read is checked against your organization's DLP policy (Settings → Governance → DLP). In Enforce mode a match refuses the file. In Audit mode the match is recorded in the audit log and the file is sent. See Data loss prevention.
If Scrydon cannot read these settings, it does not fall back to the defaults, because that could undo a restriction you set. The file is not sent and the sender is asked to try again. This includes settings stored in a form Scrydon no longer accepts: the page then shows the defaults, and saving it replaces what was stored.
For what members see, see Attachments and voice notes.
Link previews
When a member pastes a web address into a message in the Matrix workspace, Cortex can show the page's title, description and picture as a card. Scrydon builds the card on the server, under your organization's rules, and the member's app sends it inside the encrypted message. Nobody who reads the message loads the page, and neither does your homeserver.
Previews are on by default. Org admins can turn them off with the Link previews switch in Settings → Cortex → Settings. The switch applies as soon as you flip it, to previews built after that; cards already in a conversation stay.
| Rule | What happens |
|---|---|
| Egress | The page, and every redirect it follows, must be allowed by your organization's egress policy (its allow list or deny list). A host the policy refuses gets no preview, and the refusal is recorded as a blocked egress event. Addresses on private networks, loopback addresses and cloud metadata addresses are never fetched, whatever the policy says. |
| DLP | The title, description and site name are checked against your DLP policy before they leave the server. A match, or a policy that cannot be read, means no preview. An organization needs a DLP policy set up for previews to work, as it does for file uploads: with none, there is no preview. |
| The picture | Only a PNG, JPEG, WebP or GIF of at most 1 MiB, recognized by its contents rather than its name, is used. It is not re-encoded. It is admitted like any file sent in that room, so the file rules apply to it, and it travels as an encrypted attachment. If the picture is refused the card is shown without it. |
| Limits | About 30 previews per person and 600 per organization per minute, on each Scrydon server. A deployment that runs several servers allows that many times as much in total, so a count in the audit log can be higher than these numbers without the limit being broken. A preview over the limit is simply not shown. |
| Who gets one | The server answers only for a person who is in the room. Cortex's own app asks for one preview per message, from its first link, and never for a message from an agent or from Cortex itself. |
A preview that was built is recorded as collaboration.link_preview.served, with the host of the link that was pasted and the host the page finally came from (these differ when the link is a redirect, such as a link shortener), and each reason a preview was refused is recorded as collaboration.link_preview.refused, with the reason and the host when there is one. Neither names the address, the page or the room. A refusal because the switch is off, or because a person is over their limit, is recorded once a minute for that person rather than once per request. A request refused because the server is busy, and a request from someone who is not in the room, are not recorded. Previews are not metered. If Scrydon cannot read the switch, it shows no preview rather than assuming the default.
Audit events
Every Chat action emits a cortex.* audit event. These events are searchable in the Audit events catalog and include:
- The model and integration used.
- Token counts, estimated cost, and duration.
- The workspace and member who initiated the conversation.
- Tool calls made during the conversation (web search, workflow creation, etc.).
Audit events are retained according to your org's audit log retention policy. See Audit logging for how to query and export them.
Usage and billing
Chat usage is billed under the chat billing source. To see breakdown by conversation, model, and member:
- Open Settings → Billing & Usage.
- Filter by source chat.
See Billing & usage for full detail on usage reports and cost attribution.