Policy and Audit

What an owner can enforce across a team, and what the audit trail will and will not tell you.

Team-wide inactivity timeout

A team owner can sign every member out after a period of inactivity. The control is in My Teams, inside the team, under Team Settings. Only the owner sees it: an admin can edit the team's name, domain and branding, but the inactivity cap is owner-only, and the API refuses it from anyone else.

The choices are No limit, 15 minutes, 30 minutes, 1 hour, 4 hours, 8 hours and 24 hours. There is no free-text value and nothing shorter than 15 minutes.

The cap covers everyone in the team, the owner included. The screen says so plainly:

Everyone in this team — including you as the owner — is automatically signed out after this much inactivity (or sooner, if someone sets a shorter personal timeout in their own account). "No limit" leaves it to each member.

Underneath, the owner is shown the number that will actually apply to them, because setting a 15-minute cap on the team sets a 15-minute cap on the person who set it.

How the effective timeout is worked out

Every member also has a personal setting in Profile & Account, on the Security tab, under Automatic Logout — the same durations, with No automatic logout in place of No limit. The timeout that applies is the shortest of:

• the member's own setting, and
• the tightest cap among every team they are a confirmed member of.

A pending invitation applies nothing; the cap starts biting once the invitation is accepted. Someone in two teams gets the tighter of the two caps. A member can always choose a shorter timeout than the team requires, and can never choose a longer one.

What enforcement does

Enforcement is server-side, on a sliding window. Every authenticated request restamps the last-activity marker; once the gap since the last one exceeds the timeout, the session is cleared and the request refused, and the app returns to the sign-in screen. Shortly before the cutoff the browser shows a Still there? dialog counting down, with Stay logged in and Log out now. After a cutoff the app reports Signed out — "You were signed out due to inactivity."

IP access restrictions

Restricting a credential to known addresses requires the ip_access_restriction entitlement — Business and Enterprise. On any other plan the control is locked, and a request that carries an IP list anyway is refused server-side with a plan-upgrade error; see Errors and limits.

The restriction belongs to an individual share and is set under IP Whitelist when you create it. There is no organisation-wide allow list, and no team setting that applies one to every share a member creates.

• Add addresses one at a time. Single addresses (203.0.113.7) and CIDR ranges (203.0.113.0/24) are both accepted; a viewer passes on an exact match or on falling inside a listed range.
• Leaving the list empty skips IP gating entirely.
• The address compared is the recipient's own resolved client address, not the address of the CDN in front of us. The same value is what the access trail records.
• Share settings are fixed at creation. Addresses cannot be added to, or removed from, a share that already exists — create a replacement and expire the old one.

The IP check runs early: after the key carried in the link is verified, and ahead of expiry, login and passwords. A blocked recipient sees:

You don't have permission to access this share

That is deliberately the same wording a domain refusal produces, so the person on the other end learns nothing about which rule stopped them.

Access-log retention

How far back the trail can be read is set by your plan's max_days_access_logs entitlement.

Yearly plans carry the same window as their monthly equivalent.

Retention is a read window, not a deletion schedule. Access-log rows are never removed — not when the window passes, not when a share expires, and not when a share is deleted. The window only clamps how far back a query may reach: the earliest readable moment is always now minus your plan's days, recalculated on every request.

Two consequences are worth planning around.

• Upgrading widens the window immediately, and it widens it over history you already have. Rows written while you were on the smaller plan become readable again as soon as they fall inside the larger window.
• Downgrading narrows it the same day. Older rows are not destroyed, they simply drop out of reach. Upgrading again brings them back.

Both the per-share Access History dialog and Export Audit Logs clamp their date pickers to the window, and the export re-applies the limit on the server, so widening the range by hand changes nothing. When the clamp bites, the export says so: "Your plan allows up to N days of audit retention. Earlier dates were skipped."

One export returns at most 50,000 rows. Hitting that cap marks the result (truncated) and asks you to narrow the range and run it again.

What the trail records

A row is written when a share is successfully opened, and when a wrong password is submitted against one. Each row carries the columns shown in Access History:

Both the per-share view and the account-wide export download as CSV or JSON.

Do not read the trail as a record of every attempt on a link. Nothing is written when an open is turned away by a gate that runs before the credential is served:

• refused by the IP allow list;
• refused because the share had expired, its view limit was already used up, or the link's key did not match;
• stopped at the login, multi-factor or domain gate;
• a password prompt that was displayed but never answered — only a submitted, wrong password is recorded.

Two further absences are worth stating outright. Secure requests write no access-log rows at all: opening a request link and submitting to it leave nothing in the trail, though the share each submission creates has a trail of its own once someone opens it. And there is no customer-visible log of administrative actions — creating, expiring or deleting a share, inviting or removing members, role changes and plan changes are not exposed anywhere in the product. Creation and expiry times appear in the Shares and Expired Shares lists; see Key concepts.

Access history is per-creator

The trail belongs to whoever created the share, and no role can read another member's trail. This is not a permission that can be granted:

• Access History on a single share is checked against that share's creator. Any other caller, member or admin or owner, is refused.
• Export Audit Logs returns only rows for shares owned by the account making the request.

The only way to obtain another member's access history is to ask them to open Access History or Export Audit Logs on their own account and send you the file. Support cannot retrieve it either — see Help and support.