Security
Amlak™ holds lease documents, bank statements and your tenants’ details. This page says what protects them and, at the bottom, what we are not going to pretend to.
It is written for three kinds of reader: landlords deciding whether to put their leases here, reviewers at a partner we integrate with, and anyone doing security research. It describes how the product works today. It is not a certification, an audit, or a warranty — section 6 is the honest boundary of what we claim.
1. Your data is isolated in the database itself
Every table in Amlak carries a row-level security policy tying each row to the account that owns it. This is enforced by Postgres, not by the application, so even if a query asked for a row belonging to someone else, the database would return nothing. It is the difference between “the code doesn’t ask for other people’s data” and “other people’s data cannot be returned”.
The reporting views that power the financial screens run with the caller’s own permissions rather than their author’s, so the same rule applies through them. The browser only ever receives a public key that is subject to those policies; no privileged key exists in the application, the build, or this website.
2. Your account
- Passwords are hashed by our authentication provider. Amlak never sees or stores the password itself.
- Two-factor authentication with an authenticator app (Google Authenticator, Authy, 1Password and similar) is available and can be turned on in Settings. It is the single strongest thing you can do for your account.
- A second-factor code by email also exists, for accounts that have not set up an authenticator. The code is six digits, stored only as a hash, expires in ten minutes, and any earlier code is cancelled when a new one is sent. It is weaker than an authenticator app — anyone holding your mailbox holds it too — and we would rather you used the app.
- Changing your password requires re-authenticating first. An open laptop is not enough to take an account over.
- Public sign-up is closed. Accounts exist only because they were created deliberately. There is no registration form to attack.
- Sign-in attempts are rate limited per IP address by our authentication provider.
3. Documents
Uploads go to a private storage bucket, not a public one with hard-to-guess names, inside a folder keyed to your account, with the same ownership rule applied. Uploads are restricted by type (PDF, Word documents, CSV spreadsheets and common image formats) and size, enforced on the server rather than only in the browser.
A link sent to a tenant to sign a document carries a 256-bit random token. Guessing one is not a practical attack, and the endpoint that accepts it is rate limited and records the IP and user agent of anyone who uses it.
4. AI requests
Every function that reads a document requires a signed-in user and is rate limited per account, so the public key alone gets you nothing. Documents are passed to the model wrapped as data rather than as instructions, which is the standard defense against a document trying to talk to the model. And the model is never asked to do arithmetic: every figure in Amlak is computed in code from terms you confirmed. See the privacy policy for who receives what.
5. Everything else
- All traffic is over HTTPS, to this site, the application and the API.
- Database constraints bound every field a user can write, covering lengths, non-negative money and sane dates, enforced for every writer regardless of which screen it came from.
- Queries go through a parameterised query layer; there is no hand-assembled SQL taking user input.
- An audit table records permission denials, rate-limit hits and unauthorised calls to the scheduled jobs.
- The scheduled reminder job is not a public endpoint. It requires a shared secret, compared in constant time.
- There is a written plan for a security incident — who decides, what gets shut off, who is told and in what order. If your data were ever exposed you would hear it from us, with what happened and what was involved, and the privacy policy says the same.
6. What we do not claim
Amlak is a small product in private beta, and the useful thing here is knowing where the line is:
- No SOC 2, ISO 27001, or any other certification. None has been attempted.
- No third-party penetration test has been carried out.
- No CAPTCHA on sign-in. Public sign-up being closed is what limits that surface today.
- No formal uptime commitment and no status page.
- No bug bounty, but see below: reports are genuinely welcome.
If any of these are requirements for you, say so when you ask for access and we will tell you honestly whether Amlak is a fit yet.
7. If you are reviewing us
Everything a partner or a prospect usually asks for, in one place: privacy policy · terms of service · support and contact · who we are · request access. Anything not answered by those, ask at support@amlakre.com and you will get a straight answer, including where the answer is “we do not have that yet”.
8. Reporting a vulnerability
If you find something, write to support@amlakre.com with enough detail to reproduce it. You will get a real reply. Please give us a reasonable chance to fix it before publishing, and please don’t access, alter or keep anyone else’s data while investigating. Demonstrating that you could is enough.
Good-faith research reported this way is welcome, and we will not pursue anyone for it.