# A multilayer security architecture — AI City Technologies Source: https://aicity.am/features/en/security Language: en Availability depends on the user’s role, enabled building services and compatible equipment. ## A multilayer security architecture https://aicity.am/features/en/security Encryption, authentication, authorisation and recoverability: protection mechanisms with a clearly defined scope. ### Cryptographic protection of secrets https://aicity.am/features/en/security#security-crypto 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 https://aicity.am/features/en/security#security-crypto-detail-1 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 https://aicity.am/features/en/security#security-crypto-detail-2 Each encryption uses a fresh random IV; authentication-tag verification rejects corrupted or altered ciphertext. #### Separate key management https://aicity.am/features/en/security#security-crypto-detail-3 Encryption keys are supplied through server configuration rather than stored alongside the ciphertext field; device-secret storage supports versioned key management. #### Masked secret values https://aicity.am/features/en/security#security-crypto-detail-4 Management views use masked values with limited identifying fragments instead of returning complete secrets in ordinary display responses. ### Authentication and account-takeover controls https://aicity.am/features/en/security#security-auth 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 https://aicity.am/features/en/security#security-auth-detail-1 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 https://aicity.am/features/en/security#security-auth-detail-2 Enabled TOTP requires an authenticator code, controls reuse of an accepted time step and provides hashed, single-use recovery codes. #### WebAuthn passkeys for staff https://aicity.am/features/en/security#security-auth-detail-3 Staff passkey authentication verifies origin, RP ID, a single-use challenge and required authenticator user verification through biometrics or a PIN. #### Login-attempt controls https://aicity.am/features/en/security#security-auth-detail-4 Sign-in and code-verification flows apply rate limits, failed-attempt tracking and relevant lockout rules. ### Web transport and session protection https://aicity.am/features/en/security#security-session 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 https://aicity.am/features/en/security#security-session-detail-1 Public web connections use TLS; HSTS instructs supporting browsers to use HTTPS for subsequent connections. #### Secure, HttpOnly, SameSite=Strict https://aicity.am/features/en/security#security-session-detail-2 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 https://aicity.am/features/en/security#security-session-detail-3 Cookie-session operations require exact origin/host matching and designated request attributes to reject unauthorized cross-site operations. #### Refresh-token rotation and reuse detection https://aicity.am/features/en/security#security-session-detail-4 Renewal replaces the previous token; reuse can revoke the associated session chain, and logout also performs server-side revocation. ### Layered data isolation https://aicity.am/features/en/security#security-data 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 https://aicity.am/features/en/security#security-data-detail-1 Protected-table policies restrict readable and writable rows by building and user context, supplementing application authorization. #### Restricted database runtime role https://aicity.am/features/en/security#security-data-detail-2 The application’s database role is separated from maintenance privileges and designed to operate without ownership or BYPASSRLS privileges. #### RBAC and action-level permissions https://aicity.am/features/en/security#security-data-detail-3 Role, organization, building and action checks restrict the underlying server operation as well as page visibility. #### Chat and AI-history scope https://aicity.am/features/en/security#security-data-detail-4 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 https://aicity.am/features/en/security#security-mobile 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 https://aicity.am/features/en/security#security-mobile-detail-1 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 https://aicity.am/features/en/security#security-mobile-detail-2 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 https://aicity.am/features/en/security#security-mobile-detail-3 On supported devices, PIN or biometric verification adds a local app-access layer alongside server authorization. #### Device-access revocation https://aicity.am/features/en/security#security-mobile-detail-4 Device or associated-access revocation is enforced through the relevant server checks to end subsequent authorized use. ### Cryptographic control of physical access https://aicity.am/features/en/security#security-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 https://aicity.am/features/en/security#security-access-detail-1 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 https://aicity.am/features/en/security#security-access-detail-2 Access verification checks the protocol challenge and permission validity period to limit reuse of previously captured messages. #### HMAC-SHA-256 commands https://aicity.am/features/en/security#security-access-detail-3 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 https://aicity.am/features/en/security#security-access-detail-4 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 https://aicity.am/features/en/security#security-web 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 https://aicity.am/features/en/security#security-web-detail-1 The CSP restricts executable script sources and blocks embedded objects, reducing the attack surface for injected content. #### Clickjacking and MIME protections https://aicity.am/features/en/security#security-web-detail-2 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 https://aicity.am/features/en/security#security-web-detail-3 Server-side validation checks expected fields and data formats, while operation-aware request limits constrain automated abuse. #### Private-file access checks https://aicity.am/features/en/security#security-web-detail-4 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 https://aicity.am/features/en/security#security-payments 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 https://aicity.am/features/en/security#security-payments-detail-1 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 https://aicity.am/features/en/security#security-payments-detail-2 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 https://aicity.am/features/en/security#security-payments-detail-3 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 https://aicity.am/features/en/security#security-payments-detail-4 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 https://aicity.am/features/en/security#security-audit 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 https://aicity.am/features/en/security#security-audit-detail-1 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 https://aicity.am/features/en/security#security-audit-detail-2 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 https://aicity.am/features/en/security#security-audit-detail-3 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 https://aicity.am/features/en/security#security-audit-detail-4 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 https://aicity.am/features/en/security#security-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 https://aicity.am/features/en/security#security-recovery-detail-1 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 https://aicity.am/features/en/security#security-recovery-detail-2 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 https://aicity.am/features/en/security#security-recovery-detail-3 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 https://aicity.am/features/en/security#security-recovery-detail-4 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 https://aicity.am/features/en/security#security-1 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 https://aicity.am/features/en/security#security-1-detail-1 Access is tied to the authenticated resident account, property relationships and active permissions to limit data scope. #### Employees work within their assigned scope https://aicity.am/features/en/security#security-1-detail-2 An employee’s data and action scope is determined by assigned roles and building permissions. #### Management organisations’ data stays separate https://aicity.am/features/en/security#security-1-detail-3 Access to organizations’ operational data is separated according to organization and building boundaries. #### The shared property marketplace contains published offers https://aicity.am/features/en/security#security-1-detail-4 A published shared-market listing does not expose its building’s financial or administrative records. ### Approvals and accountability https://aicity.am/features/en/security#security-2 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 https://aicity.am/features/en/security#security-2-detail-1 Activity records retain the actor and time of important changes for review and accountability. #### Manage financial and entry permissions by role https://aicity.am/features/en/security#security-2-detail-2 Financial and physical-access actions require the relevant authorization beyond merely being signed in. #### Responsible-person approval in the relevant workflows https://aicity.am/features/en/security#security-2-detail-3 Approval-based workflows require a decision by an authorized person before the change proceeds. #### Keep terms and consent history https://aicity.am/features/en/security#security-2-detail-4 Terms acceptance and consent records are retained to review the applicable version and acceptance process. ### Help and personal control https://aicity.am/features/en/security#security-3 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 https://aicity.am/features/en/security#security-3-detail-1 Account and device access controls help manage active environments and end permissions that are no longer needed. #### Personal settings and notification choices https://aicity.am/features/en/security#security-3-detail-2 Use personal settings to manage available preferences and message delivery within your account. #### Available account closure or deletion requests https://aicity.am/features/en/security#security-3-detail-3 Submit the designated account-closure or deletion request under the applicable process and retention terms. #### Privacy information and support contacts https://aicity.am/features/en/security#security-3-detail-4 Data-processing terms and security or support contacts are available on the relevant public pages. #### Guides for residents and management teams https://aicity.am/features/en/security#security-3-detail-5 Role-specific guides explain the intended steps and reduce uncertainty when using the platform.