Security

Access control at the database level

Every application, document, version and upload record is bound to the account that created it, and the database refuses reads and writes that do not belong to the requesting account. This is not a filter applied in the browser — a request carrying a different account's identifier is rejected, not quietly narrowed.

Authorisation is derived from the verified session on the server. An identifier supplied by the browser is never trusted as proof of ownership.

Administrative separation

Administrative capability is stored separately from user profiles and checked on the server. An account cannot grant itself a role, and role records are not writable from the application. Administrative checks fail closed: if a role cannot be verified, access is denied.

Uploads and extracted text

Uploaded files are treated as untrusted. Type, size and content signature are checked, files are never executed, and text extracted from a document or image is sanitised before it is displayed. Markup or script inside an uploaded file cannot run in the application.

Instruction injection

Job descriptions and CVs are handled strictly as data. Instructions embedded in them — for example text telling the service to ignore its rules or invent experience — are ignored. The no-fabrication rule cannot be switched off by content.

Abuse controls

Generation and upload activity is rate-limited against automated abuse, and security-relevant events are recorded. These controls target machine-speed behaviour; ordinary job-seeking volume is not restricted, and there are no credits or quotas.

Secrets and credentials

Service credentials exist only on the server and are never delivered to the browser. Errors shown to you are plain messages: we do not surface stack traces, database errors, internal paths or configuration.

What we will not claim

Code delivered to a browser can always be inspected by the person receiving it — anyone claiming otherwise is mistaken. Our protection comes from server-side authorisation, database access rules and secret handling, not from hiding client code.

We also cannot promise that no incident will ever occur. If one affects your data, we will tell you.

Reporting a vulnerability

Email support@knowunit.com with enough detail to reproduce the issue. Please do not access other people's data while testing, and give us a reasonable opportunity to fix the problem before publishing.