Platform admin overview

You're on the TSNC team itself โ€” you can see and act across every organization. That comes with real responsibility. Here's the lay of the land, and the rails we've built so the team doesn't accidentally hurt customers.

๐Ÿ”’ thoushaltnotclick.com/platform/dashboardTSNCAll UsersAll OrgsEnterprisesAudit LogScanner AcctsPlatform Audit LogSystem-wide event streamTotal Users12,847Active Orgs284Events Today1,402Alerts3Recent Eventsloginprincipal@stmarys.eduSuccessvault_recoveryadmin@holyspirit.eduCo-approval pendingscanner_loginscanner@tsncSuccess (90d JWT)mfa_setupcgarcia@sthelen.eduCompletedcampaign_sentsystem47 recipientsadmin_actionprincipal@blessed.orgOrg settings updated
The Platform Audit Log โ€” System-wide events. Used for triaging customer issues and detecting bad behavior.

What a Platform Admin can do

  • See every org and user in the system โ€” read-only by default, write access through specific tools
  • Impersonate users for support โ€” but with hard guardrails (vault is blocked, every action is logged with your identity)
  • Manage scanner accounts โ€” accounts dedicated to security scanners like Intruder.io that bypass MFA but cannot access vaults or admin features
  • Co-approve recovery requests โ€” when an org admin's recovery request needs an external sign-off
  • Review the system-wide audit log โ€” every login, every admin action, every API call
  • Access the platform logs โ€” server-side errors, payment events, deployment markers

What a Platform Admin cannot do

  • Read any user's vault. Even with platform-level powers, vault decryption requires either the user's master password or the org's escrow private key โ€” neither of which TSNC has. The platform admin's reach stops at the vault boundary.
  • Wipe a school's vault. Vault wipes are restricted to the school's own org admin. We chose this on purpose: it would be too dangerous if a single TSNC engineer with platform credentials could destroy customer data across the system.
  • Initiate vault recovery without involving the school. A platform admin can co-approve, but cannot initiate. The org admin at the school is always the one driving recovery.
  • Suppress non-suppressible notifications. When a user's vault is recovered, they get an email and in-app notification. There's no admin override that hides those โ€” by design.
โœ๏ธ
Why we built it this way
We knew before launch that a malicious or compromised TSNC employee was the worst-case threat to customer data. So we built the architecture so even we can't do certain things. Vault wipes restricted to org admins. Recovery requires a school's private escrow key (we don't have it). Notifications can't be suppressed. Co-approval gates that can't be bypassed. This isn't paperwork โ€” it's the security model. If a customer ever asks "but what if a TSNC engineer goes rogue," the answer is: they would still need an org admin's cooperation to read or destroy any vault.

The team-side tools

All Users / All Orgs / All Enterprises

Read-only inventory views. Use for triaging support tickets โ€” find the customer, see their org, see their roles. From here you can navigate to a specific user or org for deeper action.

Audit Log

Every action in the system, by every user, ever. Filterable by user, org, action type, time range. The first stop when investigating "what happened to my account" tickets.

Platform Logs

Server-side technical logs โ€” API errors, deployment markers, payment events, worker job runs. For engineering debugging, not customer support.

Scanner Accounts

Manage user accounts flagged for use by automated security scanners (Intruder.io, Burp, ZAP). See Scanner accounts โ†’

Impersonation

From an org or user's page, hit Impersonate to assume their session for support purposes. See Impersonation safeguards โ†’

Report Queue

Phishing emails users have reported via the browser extension. Triage queue for finding new threat patterns and updating the community-threats database.

Community Threats

Cross-customer threat intelligence. When 5 different schools all report a similar phishing email, that's a campaign โ€” flag it, push the fingerprint to the threat-detection rules, protect everyone.

Daily rhythm for the platform team

  • Morning (10 min): scan Audit Log for unusual patterns. Look for anomalous logins, repeated MFA failures, new orgs that look spammy.
  • During the day: handle support tickets via impersonation when needed. Stay out of customer vaults entirely.
  • Weekly: review the Report Queue, promote new threats to Community Threats. Update detection rules.
  • Quarterly: review who has platform-admin privileges. Revoke for anyone who left the team. Rotate scanner tokens.
Next โ†’
Impersonation safeguards