No customer project records.
Project examples, contract excerpts and screenshots are fictional. Gallery captures and the product video come from this prototype, not from a client deployment.
← Back to MadloolTrust is built on evidence.
SECURITY & TRUST
Trust is built on evidence.
Not on badges.
A clear view of this website’s boundaries, the product’s security requirements and the evidence needed before production use.
WHAT IS TRUE TODAY
This preview, in plain terms.
No hidden form delivery.
Demo requests are prepared in browser memory by default. They are not sent, stored in browser storage or booked into a calendar. Live collection requires explicit configuration and an updated operator privacy notice.
Assets served with the site.
No analytics, ad trackers, external fonts or remote video embeds are included. The language preference may be stored locally. Hosting providers may process access logs under their own settings.
CLEAR BOUNDARIES
Preview behavior vs. production controls.
These requirements are not claims that the production controls already exist. Each needs implementation, testing and evidence before company data is introduced.
| Control area | This website | Required before production use |
|---|---|---|
| Identity & permissions | Role switches illustrate perspectives; they do not authenticate users or enforce access. | Verified identity, role and project authorization, least privilege and appropriate administrative controls. |
| Customer data isolation | Only shared fictional sample records exist. No tenant database is included. | Server-side tenant scoping, isolation tests and prevention of cross-customer data access. |
| Encryption & transport | The deploy package includes browser security header settings. HTTPS is established by the selected hosting provider. | Verified transport encryption, storage encryption and controlled key management for the production architecture. |
| Audit & approval | Demo approval changes temporary page state only. It is not a legally operative approval or an audit record. | Traceable identities, approval authority, protected event records and an agreed retention policy. |
| AI & document handling | All extraction and draft examples are scripted. No document is sent to an AI provider. | Approved providers, data-use terms, source traceability, input isolation, permission limits and human approval for sensitive actions. |
| Backup & recovery | No customer operational data is hosted by the prototype. | Documented backups, tested recovery, agreed recovery objectives and service continuity responsibilities. |
| Integrations & payments | No ERP, bank or live payment gateway is connected. “Pending” is a sample status only. | Authorized connectors, scoped credentials, approval controls and reconciliation of external transactions. |
BEFORE A PILOT
What a customer should be able to verify.
Data & hostingAgree the permitted data, hosting location, retention, deletion, exports and third-party processors.
Access & accountabilityConfirm the role matrix, customer/contractor separation, approval authorities and audit evidence.
Testing & recoveryReview risk assessment, security verification, backup restoration and incident responsibilities.
AI & commercial scopeDefine allowed agent actions, mandatory human review, usage costs, support boundaries and pilot success measures.
No ISO 27001 certification, SOC 2 report or regulatory compliance status is claimed. No residency location, recovery target or service-level commitment is implied by this page.
ASK FOR EVIDENCE
Start with your requirements.
Use the walkthrough request to describe security and procurement needs without including confidential project information. The current form shows whether it is preparing a local draft or delivering to a configured service.
Security verification can be structured against an agreed baseline such as OWASP ASVS. Reference to a verification standard is not a certification or a statement of conformance.
OWASP ASVS reference