> ## Documentation Index > Fetch the complete documentation index at: https://recontrol.money/docs/llms.txt > Use this file to discover all available pages before exploring further. # Access Controls Policy > How access to Recontrol's systems and your data is granted, authenticated, authorised, and reviewed. **Effective Date:** 29 October 2026 **Last Updated:** 29 October 2026 **Version:** 1.4 **Review cycle:** Annually, or upon any significant change to systems or law > [!NOTE] > > **Version 1.4 changes:** users may also sign in with their email address, by a one-time code or, where the account has one, a password (Sections 4.1 and 4.2). > > **Version 1.3 changes:** corrections to match the Service as it now works. Sign-in is with Google or Apple only (Section 4.1); the web application's session is described (Section 4.3); a new Space starts with Admin, Editor and Viewer roles, and permissions cover plans and connections (Section 5.2); AI Chat can propose changes that are committed only on the person's confirmation, and a person may connect their own AI tool (Sections 5.5 and 5.6). > > **Version 1.2 changes:** entitlement (has anyone paid) and permission (may this member) are documented as two separate, non-merged gates (Section 5.4); the AI Chat access boundary is described (Section 5.5); webhook authentication now includes signature verification (Section 7.1); and the offboarding rules were restated — a sole administrator's departure no longer blocks account deletion (Section 8). *** ## 1. Purpose This Access Controls Policy defines how access to Recontrol's systems, applications, and data is requested, granted, authenticated, authorised, monitored, and revoked. Its goal is to ensure that only the right people and services have the right access to the right data — and nothing more. It implements the access-control expectations of **ISO/IEC 27001:2022** (Annex A controls A.5.15–A.5.18, A.8.2 and A.8.5) and supports the "reasonable security practices" required by the **Information Technology Act, 2000** and the SPDI Rules, 2011, and the security obligations of the **Digital Personal Data Protection Act, 2023**. This policy complements the [Information Security Policy](https://recontrol.money/docs/legal/security.md), the [Data Retention and Disposal Policy](https://recontrol.money/docs/legal/data.md), and the [Privacy Policy](https://recontrol.money/docs/legal/privacy.md). *** ## 2. Scope This policy applies to: * **End-user access** to the Recontrol applications and to data within collaborative Spaces; * **Administrative / privileged access** to production systems (database, Hasura console, cloud platform, secrets); and * **Service and integration access**, including machine-to-machine tokens and third-party aggregator connections (Plaid, Zerodha). *** ## 3. Principles 1. **Least privilege.** Every user, role, and service receives the minimum access necessary for its purpose. 2. **Role-based access control (RBAC).** Permissions are assigned to roles, and roles to users — not to individuals ad hoc. 3. **Need-to-know.** Access to personal and financial data is limited to where it is genuinely required. 4. **Deny by default.** Access is denied unless explicitly granted; API endpoints require authentication by default. 5. **Separation of duties / segregation of data.** Data in one Space is never accessible to members of another Space. 6. **Accountability.** Actions are attributable to an authenticated identity. *** ## 4. Authentication ### 4.1 User authentication methods Recontrol authenticates users through the Nhost authentication service. The supported methods are: * **Sign in with Google** (OAuth) * **Sign in with Apple** (OAuth) * **Email:** a six-digit one-time code sent to the address, valid for 10 minutes; or, for an account that has one, a password No screen offers sign-up by password. The first sign-in by any method creates the account. ### 4.2 Credential security * With **Google** or **Apple**, authentication is delegated to them via OAuth; Recontrol never receives your Google or Apple password. * With **email**, a one-time code is sent to the address and is valid for 10 minutes. A password, where an account has one, is stored only as a **one-way hash**, and a new password is checked against known breached passwords; Recontrol never stores or sees plaintext passwords. * Sign-in attempts and code requests are rate-limited. * Users are responsible for keeping their Google or Apple account, and their email account, secure. ### 4.3 Tokens and sessions * On successful authentication, the client receives a signed **JSON Web Token (JWT)** plus a refresh token. * Every API request must present a valid JWT (`Bearer` scheme); requests without one are rejected by the authentication interceptor before any business logic runs. * Access tokens are short-lived; refresh tokens are invalidated on logout and on account deletion. * On mobile, tokens are held in platform-native secure storage (**iOS Keychain / Android Keystore**), never in plaintext app storage. * In the **web application**, the refresh token never reaches page scripts: the web application's own server seals it, encrypted, in a `Secure`, `HttpOnly`, `SameSite=Strict` session cookie, and the page holds only the short-lived access token, in memory. The web application signs a person out after **one hour without activity** and requires a fresh sign-in **24 hours** after the last one; signing out revokes the refresh token. ### 4.4 Device-level protection Users may enable an optional **biometric app lock** (Face ID / fingerprint). This is verified on-device by the operating system; biometric data is never transmitted to Recontrol. *** ## 5. In-application authorisation (Spaces, roles, and permissions) Recontrol's collaborative model enforces authorisation at the data layer through **Spaces, roles, and permissions**. ### 5.1 Spaces A **Space** is an isolated workspace. Data in a Space is visible only to that Space's members. The user who creates a Space is automatically its **administrator**. ### 5.2 Roles and permissions * Permissions are expressed as a **resource × action** matrix — actions (**create, read, update, delete**) over resources (Spaces, accounts, transactions, budgets, goals, watchlists, connections, memberships, and roles). * Administrators may create **custom roles** with any combination of permissions they themselves hold. * Three roles are created with each Space: **Admin** (everything, including membership and roles), **Editor** (day-to-day records, plans and connections; no membership changes) and **Viewer** (read-only). * **Role changes take effect immediately** for all current holders. ### 5.3 Membership lifecycle * Administrators invite members by email or phone number; invitations may wait for recipients who have not yet signed up. * Members may leave a Space at any time. * Administrators may change a member's role or remove a member. * **A Space is never left without an administrator.** If the last administrator leaves or deletes their account, the longest-standing remaining member is automatically granted an administrator role. If they were the only member, the Space is deleted with them. Neither case blocks their departure or their erasure. ### 5.4 Entitlement and permission are two separate gates Recontrol evaluates two independent questions, in order, and deliberately does not merge them: 1. **Entitlement** — *has anyone paid for this capability?* Bank connections require the Space to be sponsored by an active subscription; AI Chat requires the caller's own active subscription. 2. **Permission** — *may this member perform this action?* The resource × action model in Section 5.2. They are kept apart so that changing a member's role can never move a paywall, and so that a refusal states the correct remedy — obtaining a subscription is a different fix from asking an administrator for access. Refusals carry a machine-readable reason so the App can present the right one. A failure to *reach* the entitlement record is treated as a transient fault and reported as such, never as "you have not paid": a paying customer is not locked out because a lookup failed. Where a last-known-good verdict is available it is used; where it is not, the request fails as temporarily unavailable rather than as a permission denial. ### 5.5 AI Chat access boundary AI Chat runs under the **caller's own identity and access token**, so the figures it is given are exactly those the caller's role in that Space already permits them to read. It has **no elevated privilege and no administrative credential**. It can only **propose** a change: the change is computed and checked by the backend and held server-side, and it is committed only when the person confirms it, under that person's own access token and permissions. It cannot act on connections, memberships, roles, invitations, Spaces, a person's own Recontrol account, or billing. Text drawn from a user's own records is passed to the model as delimited data with an explicit instruction that it is never a command, so content inside a ledger cannot be used to redirect the model's behaviour. ### 5.6 A person's own AI tool A person may connect their own AI tool to the Service from the web application. The connection authenticates as that person through Recontrol's sign-in, acts only with that person's own permissions, and offers no tool that deletes data. The person can remove it in their AI tool at any time. *** ## 6. Privileged and administrative access * Administrative access to production systems (the database, the Hasura console, the cloud platform, and secrets) is restricted to the **Data Fiduciary / owner** and any explicitly authorised personnel, on a strict need-to-know basis. * Privileged credentials (for example, the Hasura admin secret and database credentials) are treated as high-value secrets: held only in protected environment configuration, never committed to source control, and never exposed to clients. * Administrative operations (such as schema migrations and data backfills) are performed through controlled, versioned, idempotent mechanisms rather than ad hoc production changes. * Privileged access is reviewed whenever responsibilities change. *** ## 7. Service, machine, and integration access ### 7.1 Internal service authentication Automated internal calls — such as the scheduled jobs that refresh connected data, the secure webhooks from Plaid that notify us of new bank transactions, the subscription webhooks that report a purchase or renewal, and Hasura cron/event triggers — are authenticated with a **shared webhook secret**, separate from user JWTs. Webhooks from Plaid and from our subscription provider are subject to **two independent checks, both of which must pass**: a shared secret that authenticates the *caller*, and a cryptographic signature over the raw request body that authenticates the *payload*. A replayed or tampered body therefore fails even if a shared secret were disclosed. In production the service refuses to start if signature verification is not configured. A subscription webhook is treated as a **notification, not as an authority**: every event triggers an authoritative read from the provider, and the entitlement we record comes from that read rather than from the payload. Entitlement expiry only ever moves forward, so a lost or out-of-order webhook cannot revoke a paying customer's access. ### 7.2 Third-party integration access (user-authorised) When a user connects an external institution, access is granted by the **user**, directly with the provider, using the provider's authorisation flow: * **Plaid:** the user authorises through Plaid Link; Recontrol exchanges a one-time public token for a scoped access token (limited to the transactions product). Recontrol never receives the user's banking credentials. * **Zerodha (Kite Connect):** the user authorises through Zerodha's login; Recontrol exchanges a request token (with a signed checksum) for a daily access token. Recontrol never receives the user's brokerage credentials. Integration access tokens are **encrypted at rest (AES-256-GCM)**, are scoped to the connecting user and Space, and can be **revoked by the user at any time** by disconnecting — which revokes the token with the provider and deletes it from our systems. Zerodha tokens additionally expire daily. *** ## 8. User access lifecycle | Stage | What happens | | - | - | | **Onboarding / provisioning** | A user self-registers; a personal Space is created automatically. Space membership is granted by invitation. | | **Changes** | Role and permission changes within a Space are made by an administrator and take effect immediately. Privileged (admin) access changes are made deliberately and recorded. | | **Offboarding / deprovisioning** | Leaving a Space, being removed by an admin, or deleting an account removes the associated access. Account deletion revokes external integration tokens at the provider, withdraws the user from every Space under the same rules a deliberate departure follows (Section 5.3), invalidates authentication tokens, and removes the user's own data. It is never blocked by an administrative dependency. | *** ## 9. Access reviews * **Privileged access** to production systems is reviewed periodically (and on any change of responsibilities) to confirm it is still required. * **Integration connections** are surfaced to users so they can review and revoke connected institutions at any time. * **This policy** is reviewed at least annually (Section 11). Reviews confirm that access remains aligned with least privilege and remove access that is no longer needed. *** ## 10. Responsibilities | Role | Responsibility | | - | - | | **Owner / Data Fiduciary** (Mrinal Wahal) | Owns this policy; controls privileged access; conducts access reviews | | **Space administrators** | Manage roles, permissions, and membership within their Spaces responsibly | | **All users** | Protect their credentials; use the app lock and a strong password; report suspected unauthorised access | *** ## 11. Review This policy is reviewed at least **annually**, and whenever there is a significant change to authentication, the authorisation model, integrations, or applicable law. Material changes are reflected in the "Last Updated" date and version above. *** ## 12. Contact * **Owner / Grievance Officer:** Mrinal Wahal * **Email:** [support@recontrol.money](mailto:support@recontrol.money) * **Mailing Address:** 2005, Yucca, Paramount Symphony, Crossing Republik, Ghaziabad, Uttar Pradesh, India 201016 This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.