Security & privacy
Captured evidence, sensitive options, tenant boundaries, storage, retention, deletion, and data minimisation.
On this page
Proctoring can collect identity data, behavioural signals, screenshots/photos, audio/video evidence, device metadata, and assessment-writing telemetry. Your organisation is responsible for a lawful purpose, candidate notice, access controls, retention decisions, support/appeal routes, and jurisdiction-specific review before real sessions.
Data captured by capability
| Capability | Captured data | Default posture |
|---|---|---|
| Candidate identity | Required opaque id; optional name, email, metadata. | Send the minimum stable identifier needed for reconciliation. |
| Device/browser fingerprint | Privacy-minimised browser, platform, language/timezone, screen summary, fingerprint id. | Emitted once per session for continuity/reverification. |
| Preflight | Check outcomes, device selections, face reference photo/embedding when camera is active. | Required by standard and strict; camera is derived from active webcam evidence. |
| Runtime events | Focus, visibility, keyboard shortcut, clipboard-event metadata, fullscreen, network, idle, screen/webcam state. | Controlled by policy; browser detection is not prevention. |
| Webcam snapshots | Random JPEG frames plus post-session analysis signals. | standard. |
| Webcam recording | Continuous video chunks plus post-session analysis. | strict. |
| Screen recording | Entire-screen video chunks when required. | strict. |
The policy reference is the canonical source for enabled signals and defaults. Surface the resolved policy to candidates; labels such as “AI proctoring” are not a substitute for an evidence-specific notice.
Sensitive options
clipboard.captureContent and writing-answer capturePasteContent can store candidate text. Both default off. Enable only with a documented need, byte limits, redaction/handling rules, and appropriate notice.
Face embeddings and identity-mismatch analysis are biometric-adjacent/high-risk data in many jurisdictions. Define purpose, authorised reviewers, retention, false-positive handling, and an appeal/manual-review process. An automated flag is evidence for review, not a final misconduct decision.
Keys, origins, and tenant boundaries
pk_ application keys are publishable and belong in browser code. They identify an organisation/application and are constrained by allowed origins; they are not secrets. sk_ keys authenticate server-to-server /v1 calls and must never enter a browser bundle, log, screenshot, or client storage.
The API scopes keys and session lookups to the owning organisation. Configure SERVER_CORS_ORIGINS and application allowed origins to the exact candidate/dashboard origins. CORS is a browser boundary, not authentication; secret-key guards and organisation-scoped database queries remain mandatory.
Rotate/revoke keys through the dashboard and treat origin changes as deploy changes. See Authentication.
Storage and transport
Use HTTPS for every public origin. Media is stored in the configured S3-compatible bucket. Direct browser uploads use short-lived presigned URLs; limit bucket CORS to trusted origins and use IAM roles in production where possible. Abort incomplete multipart uploads with lifecycle rules.
Restrict bucket and dashboard access, enable encryption and backups appropriate to your threat model, log reviewer/destructive actions, and separate internal administration from customer domains.
Retention and deletion
Demo sessions are excluded from quotas and automatically purged after 24 hours when demo cleanup is enabled. For real sessions, the database has an organisation retentionDays setting, but this repository does not currently ship a general scheduled customer-session retention sweeper. Do not assume that setting automatically deletes production sessions.
The secret-key API exposes DELETE /v1/sessions/:id with a matching confirmation token. It purges session media before deleting the database row and is production-gated by ALLOW_PRODUCTION_PUBLIC_SESSION_DELETE. Define and operate your own approved deletion schedule until automated retention enforcement ships.
A retention value without an active purge process is not a retention control. For controlled trials, record the agreed period, owner, deletion method, verification evidence, backups policy, and exception/legal-hold process before enrolling candidates.
Candidate intake submitted through submitCandidateIntake goes to your backend, not the Proctor platform; you own its security and retention. Assessment answers likewise remain your responsibility unless you explicitly send content through an evidence option.
Data minimisation checklist
- Use opaque candidate ids; omit name/email/metadata unless reviewers need them.
- Choose snapshots instead of continuous webcam recording when the trial purpose does not require video.
- Never enable snapshots and recording together in a customer policy.
- Keep clipboard and answer-content capture off unless justified.
- Limit reviewer roles and export/download access.
- Set short, documented retention and verify deletion from both database and object storage.
- Test that logs, error trackers, webhooks, and support tools do not receive secrets or unintended PII.
- Publish a human review and appeal route for flags and identity mismatches.
Known security boundaries
A web page cannot prevent OS screenshots, another physical device, determined browser/OS manipulation, or activity outside captured camera/screen fields. Screen-share surface constraints are browser-enforced best effort. Face/gaze/object analysis can be wrong, particularly with lighting, occlusion, accessibility needs, or unsupported media containers. Treat platform evidence as risk signals with provenance and limitations.