AI CITY TECHNOLOGIES

A multilayer security architecture

Encryption, authentication, authorisation and recoverability: protection mechanisms with a clearly defined scope.

AES-256-GCMMFA · WebAuthnRLS · RBACEd25519 · HMACPITR

Cryptographic protection of secrets

Sensitive service secrets use AES-256-GCM authenticated encryption. Keys are supplied through protected runtime configuration, and management interfaces present masked secret values.

AES-256-GCM and AEAD

Storage paths for banking-integration passwords, TOTP secrets and relevant service keys use AES-256-GCM for encryption and tamper detection.

Random IV and authentication tag

Each encryption uses a fresh random IV; authentication-tag verification rejects corrupted or altered ciphertext.

Separate key management

Encryption keys are supplied through server configuration rather than stored alongside the ciphertext field; device-secret storage supports versioned key management.

Masked secret values

Management views use masked values with limited identifying fragments instead of returning complete secrets in ordinary display responses.

Authentication and account-takeover controls

Password protection is complemented by TOTP multi-factor authentication, staff WebAuthn passkeys and login-attempt controls. Each mechanism applies to its supported roles and sign-in flows.

bcrypt with cost factor 12

User passwords are stored as individually salted bcrypt hashes with cost factor 12; verification checks the hash rather than retaining a retrievable plaintext password.

TOTP and single-use recovery codes

Enabled TOTP requires an authenticator code, controls reuse of an accepted time step and provides hashed, single-use recovery codes.

WebAuthn passkeys for staff

Staff passkey authentication verifies origin, RP ID, a single-use challenge and required authenticator user verification through biometrics or a PIN.

Login-attempt controls

Sign-in and code-verification flows apply rate limits, failed-attempt tracking and relevant lockout rules.

Web transport and session protection

Public connections use HTTPS/TLS, while web sessions separate short-lived access from server-managed renewal. Cookie restrictions, origin checks and token rotation reduce opportunities for session misuse.

HTTPS/TLS and HSTS

Public web connections use TLS; HSTS instructs supporting browsers to use HTTPS for subsequent connections.

Secure, HttpOnly, SameSite=Strict

Production web-session cookies use Secure, HttpOnly, SameSite=Strict and host-only scope; the actual renewal credential remains server-side.

CSRF controls and origin verification

Cookie-session operations require exact origin/host matching and designated request attributes to reject unauthorized cross-site operations.

Refresh-token rotation and reuse detection

Renewal replaces the previous token; reuse can revoke the associated session chain, and logout also performs server-side revocation.

Layered data isolation

Access restrictions operate through application authorization and protected database tables. PostgreSQL Row-Level Security works with user, building and organization context.

PostgreSQL RLS and FORCE RLS

Protected-table policies restrict readable and writable rows by building and user context, supplementing application authorization.

Restricted database runtime role

The application’s database role is separated from maintenance privileges and designed to operate without ownership or BYPASSRLS privileges.

RBAC and action-level permissions

Role, organization, building and action checks restrict the underlying server operation as well as page visibility.

Chat and AI-history scope

Messaging checks participation, while resident AI history is scoped to its owning user and building to prevent access to another resident’s history.

Mobile-secret and device protection

Android and iOS use operating-system protected storage for session secrets. Local locking and access revocation complement server-side authentication controls.

Android Keystore and AES-256

Android uses a Keystore-managed key and AES-256 protected storage; failure does not fall back to persistent plaintext credential storage.

iOS Keychain with ThisDeviceOnly

iOS session secrets use Keychain with ThisDeviceOnly policy to prevent that session from migrating to another phone through ordinary backup restoration.

Local PIN and biometric locking

On supported devices, PIN or biometric verification adds a local app-access layer alongside server authorization.

Device-access revocation

Device or associated-access revocation is enforced through the relevant server checks to end subsequent authorized use.

Cryptographic control of physical access

Compatible devices validate access using signed data and time limits. Commands from a phone or server are authenticated through the applicable access protocol.

Ed25519 and ECDSA P-256

Supported BLE access protocols use asymmetric signatures: a public key verifies the permission without exposing the signer’s private key to the reader.

Challenge and expiry validation

Access verification checks the protocol challenge and permission validity period to limit reuse of previously captured messages.

HMAC-SHA-256 commands

In the supported door-control protocol, authentication binds the door ID, action, unique command and execution window; changing the contents breaks verification.

Signed results and firmware

Supported command results are bound to the original command hash. Validated device update artifacts undergo SHA-256 integrity and Ed25519 signature checks against a configured trusted key.

Browser and request protection

Web protection combines browser security policies with server-side input validation. Access to private material is evaluated against the user’s current permissions.

Content Security Policy

The CSP restricts executable script sources and blocks embedded objects, reducing the attack surface for injected content.

Clickjacking and MIME protections

Frame-ancestors and X-Frame-Options restrict framing by other sites, while X-Content-Type-Options: nosniff limits incorrect interpretation of file types.

Request validation and limits

Server-side validation checks expected fields and data formats, while operation-aware request limits constrain automated abuse.

Private-file access checks

Protected-file requests check the current account and the material’s permitted audience. A no-store directive limits caching of sensitive responses by intermediaries.

Payment and critical-action safeguards

Financial trust combines bank confirmation, server-side verification and responsible human oversight. Critical-action approval is bound to the exact content that was reviewed.

Card-data separation

Online card details are entered in the bank’s payment environment. The platform does not store the full card number or CVV in its payment records.

Server-side bank verification

A payment-return page alone is not proof of payment: the integrated flow checks the result with the bank and matches it to the platform’s payment order.

Approval bound to reviewed content

For protected critical actions, HMAC-SHA-256 approval binds the action, responsible actor, organisation and content hash to detect substitution after preview.

Single-use, time-limited approval

Applicable approval tokens expire and are consumed once. In production, an unavailable verification store stops the protected action from proceeding.

Traceability and AI permission boundaries

Oversight includes significant-action history, limited disclosure of sensitive values and explicit AI access boundaries. An assistant response does not itself grant administrative or financial authority.

Action audit trail

Logged management actions are associated with an actor and time so changes can be investigated later. The audit trail is accessible to authorised staff.

Secret masking and error references

Sensitive-parameter masking and generic internal-error responses reduce secret exposure through diagnostics. An error reference supports investigation without showing internal details to the user.

AI access within role boundaries

Arega’s tools operate within the user’s and organisation’s permitted data scope. A conversation does not grant additional access to another resident’s or organisation’s information.

Human approval for consequential steps

A proposal from a photo or discussion follows its required approval step. AI does not independently post payments, change permissions or close cases; the final action remains under responsible human control.

Encrypted backups and recovery

The backup architecture includes encrypted repositories, a separate remote copy and recovery checks. Recoverability is managed as an operational process with monitoring and testing.

AES-256 backup encryption

PostgreSQL pgBackRest repositories are configured with AES-256-CBC encryption. The additional remote backup flow provides encrypted copies of data and uploaded files.

Remote storage and server identity checks

Storage separate from the primary infrastructure reduces the impact of a single-location failure. Strict SFTP host-key verification authenticates the intended remote server.

Point-in-time recovery: PITR

Full, differential and incremental backups are complemented by PostgreSQL WAL archives, allowing recovery to a chosen point within the retained backup chain.

Recovery drills and monitoring

Operational procedures provide for backup-freshness monitoring, integrity checks and isolated recovery drills before restored data is put into use.

The information each person needs

Residents see information relating to their properties and permissions, while staff see their assigned work scope. Management organizations’ data stays separated, with published listings available in the shared property marketplace.

Residents see their properties and available services

Access is tied to the authenticated resident account, property relationships and active permissions to limit data scope.

Employees work within their assigned scope

An employee’s data and action scope is determined by assigned roles and building permissions.

Management organisations’ data stays separate

Access to organizations’ operational data is separated according to organization and building boundaries.

The shared property marketplace contains published offers

A published shared-market listing does not expose its building’s financial or administrative records.

Approvals and accountability

Important changes record who performed the action and when. Financial and access-related actions are restricted by role, with staff approval required in relevant workflows and a history of accepted terms and consents retained.

Record who made important changes and when

Activity records retain the actor and time of important changes for review and accountability.

Manage financial and entry permissions by role

Financial and physical-access actions require the relevant authorization beyond merely being signed in.

Responsible-person approval in the relevant workflows

Approval-based workflows require a decision by an authorized person before the change proceeds.

Keep terms and consent history

Terms acceptance and consent records are retained to review the applicable version and acceptance process.

Help and personal control

Users can manage account and device access, personal settings and notification choices. Available account-closure or deletion requests, privacy terms and support contacts explain how to control their account and obtain help.

Manage account and device access

Account and device access controls help manage active environments and end permissions that are no longer needed.

Personal settings and notification choices

Use personal settings to manage available preferences and message delivery within your account.

Available account closure or deletion requests

Submit the designated account-closure or deletion request under the applicable process and retention terms.

Privacy information and support contacts

Data-processing terms and security or support contacts are available on the relevant public pages.

Guides for residents and management teams

Role-specific guides explain the intended steps and reduce uncertainty when using the platform.

Availability depends on the user’s role, enabled services and compatible equipment.