Security, audit and legal holds

Control what published reports may do in a reader's browser and where they may be embedded, read and export the audit log, and preserve records under a legal hold.

Three screens for the people responsible for security and compliance: Organisation → Security, Records → Audit log and Records → Legal holds. Owners, admins and security admins can open all three.

Report content policy

A report is HTML an AI wrote, and it runs in your readers' browsers. The content policy on Organisation → Security decides what it may do there, for every report in the organisation. By default a report may run its own scripts but cannot reach anything on the internet. A change applies the next time a report is opened; nothing needs republishing.

SettingStartsAllows
JavaScriptOnReports may run their own scripts — interactive tabs, charts.
Inline scriptsOnScripts written into the report's HTML. Most AI-generated reports need this.
External scriptsOffScripts loaded from the internet, such as a CDN.
External imagesOffImages loaded from other websites.
External data requestsOffReport scripts calling APIs elsewhere.
External fonts & stylesOffStylesheets and fonts loaded from the internet.
FormsOnForms inside a report that submit back to the report itself.
External form submissionOffForms that send data to other websites.
Embedded framesOffReports embedding their own iframes.

Embedding

Reports can be shown inside a page on another site — a SharePoint intranet, for example — only if that site is listed under Sites allowed to embed your reports. Enter one address per line, https:// and the host only, with no path. Everywhere else is refused. A public report shows itself to every visitor. For any other report, readers who are not signed in see a link that opens it in a new tab instead, because a browser will not let them sign in inside someone else's page. The report's Embed button gives the code to paste and says which case applies.

Who may be given a report — guests, domains, public links — is on Organisation → Sharing; see Sharing.

Classification of new reports

Default classification — public, internal, confidential or restricted — is what a newly published report is classified as when the person or agent publishing it does not say. It starts at internal. Classification decides which publishing policies apply, so raising the default makes new work more guarded from its first version. Reports that already exist keep their classification.

Connected apps

Any AI app can ask to connect to a person's account, because AI tools register themselves. The risk is an app that calls itself something familiar but sends the access to its own website. The sign-in screen always names that website and asks the person to confirm one it does not recognise.

To remove the choice altogether, switch on Only recognised apps can connect on Organisation → Security. Claude, ChatGPT, Microsoft 365 Copilot, Copilot Studio, VS Code and apps on the person's own computer or phone can still connect; a connection that would send access to any other website is refused. Switching it on also ends the connections to such websites that people in the organisation have already made, and they are not renewed.

The audit log

Records → Audit log is the record of what happened in the organisation: who published, shared, decided, invited, changed a setting or was refused, and when. Each event has a type (such as report.published), the person, agent or system that caused it, the thing it happened to, and the detail. Events cannot be edited or deleted from the app; they are removed only by the retention sweep described below. Each organisation's events are hash-chained, each one carrying a hash of the one before it, and the page checks the chain each time it opens: Chain verified up to the newest entry it checked, or where the chain broke.

  • The screen shows the 200 most recent events. Filter by event type, by actor (an email address or agent name), and by date range.
  • Download CSV exports the events matching the current filters, up to 5,000 rows, with the full detail of each.
  • By API, GET /api/v1/audit-events returns every event, newest first, a page at a time, with each one's place in the chain. It needs a key with the audit:read scope that belongs to an owner, an admin or a security admin; an agent's key is refused. deliverd audit reads it from the command line, in CLI 0.17.0 and later.
  • As a stream, a webhook endpoint subscribed to audit.event receives every event as it is written, with its hashes, for a SIEM or an archive of your own. It is off until you subscribe an endpoint to it.

How long events are kept

A daily sweep removes events older than your plan's audit history. The history of who viewed reports has its own, separate window.

PlanAudit historyView history
Free7 days30 days
Team90 days180 days
Business Starter180 days180 days
Business365 days365 days
Enterprise365 days365 days

Some events are never removed, whatever the plan: those beginning billing., platform., api_key. and legal_hold. — billing, platform operator activity, API keys and legal holds. And nothing is removed while a legal hold is in force.

On Enterprise, an administrator can set the audit history the organisation keeps, under Audit retention on Organisation → Security: any number of days from the plan's window up to 3,650 (ten years). The setting can only lengthen what the plan keeps, every change is in the audit log with the old and new value, and a legal hold still stops anything being removed.

A legal hold stops deletion while a matter is open. Placing one is included in Enterprise; a hold already in force stays in force on every plan, including after a downgrade. Holds are placed and released on Records → Legal holds by an owner, an admin or a security admin.

While any hold is in force:

  • The retention sweep removes nothing from the organisation — neither audit events nor view history.
  • The organisation cannot be closed. Any open hold refuses it, including a hold on a single report, because closing would delete that report too.
  • What the hold covers cannot be deleted: a report's datasets, a task and its side tasks, and the attachments of a comment that is retracted, which then keeps its files. The refusal names the hold's matter reference.
  1. 1

    Give the matter a reference

    Whatever the instruction calls it, such as a case number. This is what appears on every refusal the hold causes.

  2. 2

    Choose the scope

    The whole organisation, which is the usual choice at the start of a matter, or one report, one project, one task and its side tasks, or one person's material (a custodian: their comments, attachments and tasks). Any scope can take a date range, and then keeps what existed by its end.

  3. 3

    Add a note if useful, and place the hold

    It appears under In force with who placed it and when.

To release a hold, choose Release and say why; the reason is required and kept. Released holds stay listed with their dates and who released them. Placing and releasing are recorded as legal_hold.placed and legal_hold.released, and those events outlive every retention window.

Try it on your own agent.

Free to start, no card. Sign up with Google, Microsoft or GitHub, and the first page after hands you an API key.