Privacy Policy
FSS MCP Hub Privacy Policy
Effective date:
Last updated:
1. About this policy
The FSS MCP Hub is the shared account, authentication and authorisation service operated by Finite Software Systems Ltd. It is used to sign users in to applications operated or supported by FSS and to issue the identity and access credentials those applications need.
The first public product using the Hub as its identity provider is brainattic. Other FSS applications may use the Hub over time.
This policy explains how the Hub processes personal data. It does not replace the privacy policy of an application you access through the Hub. For example, brainattic's handling of documents, attachments, searches and other knowledge-base content is covered by the brainattic Privacy Policy, not by this policy merely because brainattic uses the Hub for login.
2. Controller and contact details
The controller for the processing described in this policy is:
Finite Software Systems Ltd.
Bulgarian name: ФИНИТ Софтуер Системс ЕООД
UIC / Company No.: 175276896
VAT No.: BG175276896
- Registered office: 4 Gorotzvet Street, 1421 Sofia, Bulgaria
- Contact and management address: 180 Vitosha Boulevard, 1408 Sofia, Bulgaria
- Email: info@finite-soft.com
- Telephone: +359 2 439 21 00
We have not appointed a Data Protection Officer. Privacy requests are handled through the contact details above.
3. What the Hub does
The Hub currently provides:
- an FSS user account and login session;
- password login and password recovery;
- optional sign-in with Google;
- email verification for password self-registration;
- OAuth 2.0 and OpenID Connect authorisation;
- access and refresh token issuance;
- identity information for registered applications;
- per-user, per-application scopes, roles, tenant or workspace bindings and resource-specific attributes;
- remembered application approvals that a signed-in user can withdraw for future authorisation requests;
- invitation and self-registration support initiated by a registered FSS application;
- registration of compatible OAuth and MCP clients where enabled; and
- security, operational and administrative audit records.
4. Personal data processed by the Hub
4.1 Account and profile data
Depending on how the account is created and used, the Hub stores or processes:
- name;
- email address;
- whether the email address is verified and the source of that verification;
- a one-way password hash, if a password has been established;
- preferred language;
- an FSS-hosted profile image, if one is uploaded by an administrator;
- an internal, non-reused OpenID Connect subject identifier;
- account type, such as customer or staff;
- administrator status and active/inactive status;
- account creation, password-establishment, verification and last-login timestamps;
- application, resource-server, tenant or workspace bindings;
- granted and revoked scopes, roles and resource-specific attributes; and
- remembered OAuth client approvals and their revocation state.
The authenticated account page currently allows a user to change their display name and password, resend an email-verification link where applicable, change language, log out, and withdraw remembered application approvals. The account email is read-only on that page and is managed administratively.
4.2 Data received when you use Google sign-in
When you choose Continue with Google, the Hub requests the standard OpenID Connect scopes:
openid;email; andprofile.
The current Hub implementation reads the following claims from Google's signed ID token:
- Google's stable subject identifier for the account;
- email address;
- Google's
email_verifiedvalue; and - display name, where Google provides it.
The Hub uses those values to authenticate you, find or create the corresponding local Hub account, verify the email assertion, and link the Google identity to that account.
For the identity link, the Hub stores:
- the provider name (
google); - Google's stable subject identifier;
- the email address asserted when the link was created;
- the verification status asserted at linking; and
- the link timestamp.
The display name may be copied into the local Hub account when a new account is created.
The Hub does not receive your Google password. The Google token response is processed during the sign-in request, but the current implementation does not persist Google access tokens or Google refresh tokens. It validates the Google ID token and retains only the local account and identity-link data described above.
The current implementation does not use Google sign-in to access Gmail, Google Drive, Google Calendar, Google Contacts, Google Photos, advertising data, payment data or the contents of another Google service.
4.3 OAuth, OpenID Connect and client data
When an application or client requests access, the Hub may process:
- client identifier, name, redirect URIs, client type and authentication method;
- requested, granted, refused and revoked scopes;
- the target application or resource server;
- tenant, workspace or other resource-specific attribute values assigned to the account;
- authorisation codes, PKCE values,
stateandnoncevalues; - access-token and refresh-token records, including one-way token hashes, expiry and rotation status;
- token audience, resource, grant type and client association;
- consent or remembered-approval state;
- client registration metadata;
- issue, use, refresh, revocation and expiry timestamps;
- IP address and user-agent information associated with sessions or token issuance; and
- request identifiers and audit context needed to investigate an event.
Client secrets are displayed only when created or rotated and are stored as one-way hashes. OAuth access and refresh tokens are also represented by token records and hashes where the protocol flow requires server-side persistence.
4.4 Data shared with registered applications
The Hub shares data only through a registered OAuth or OpenID Connect flow and subject to the requesting client's configuration, the scopes granted for the request, the user's account grants, and the target resource server.
Depending on the granted scopes and the application's configuration, the Hub may provide:
- the Hub's stable user subject identifier;
- display name;
- preferred username derived from the email local part;
- email address and email-verification status;
- FSS-hosted profile-image URL;
- preferred language;
- account role, currently represented as customer, staff or administrator-related role values;
- authorised scopes;
- the intended application or audience; and
- namespaced tenant, workspace or other attributes registered for that application.
The Hub does not send all fields to every application. The profile scope controls the profile claim group, and the email scope controls email and verification claims. Resource-specific information is limited by the relevant resource-server registration and access grants.
After an application receives information from the Hub, that application's own privacy policy governs its subsequent processing.
4.5 Registration, invitations and verification
A registered FSS application may initiate an invitation or self-registration request with the Hub. The Hub may process:
- the target application;
- tenant or workspace identifier;
- email address, where supplied by the initiating application;
- a single-use registration or invitation token represented as a hash;
- a one-time return nonce;
- issue, use, refusal and expiry timestamps; and
- email-verification token and status for password registration.
The Hub sends password-reset, invitation, account-security and email-verification messages through FSS's configured email infrastructure.
4.6 Website, session and security data
When you visit or use the Hub, it may process:
- IP address;
- browser or client user agent;
- requested route and response outcome;
- timestamps and request identifiers;
- session identifier and session activity;
- login failures and temporary lockout state;
- security and application error information; and
- selected language.
The Hub uses functional cookies needed for session authentication, form protection and OAuth continuity, plus a language-preference cookie. The current public Hub and login implementation does not include advertising or behavioural-tracking code. When you are redirected to Google, Google's own cookies and technologies are governed by Google's policies.
5. Purposes and legal bases
| Purpose | Legal basis under the GDPR |
|---|---|
| Create and operate a Hub account | Performance of a contract or steps taken at your request before a contract; where an organisation provides the access, FSS's legitimate interest in providing the requested identity service |
| Authenticate with a password or Google | Performance of a contract and your request to use the selected sign-in method |
| Link a verified Google identity to a Hub account | Performance of a contract and FSS's legitimate interest in secure, convenient authentication and account-integrity controls |
| Issue identity and access credentials to registered applications | Performance of a contract and FSS's legitimate interest in operating a shared identity and access-management service |
| Store scopes, tenant bindings and resource-specific attributes | Performance of a contract and FSS's legitimate interest in enforcing authorised, application-specific access |
| Maintain sessions, token rotation, revocation and client records | Performance of a contract and FSS's legitimate interest in secure service operation |
| Prevent fraud, account takeover and abuse | FSS's legitimate interests in protecting users, applications and infrastructure |
| Keep operational and audit records | FSS's legitimate interests in accountability, troubleshooting, service integrity and security investigation |
| Send account and security messages | Performance of a contract and FSS's legitimate interest in account security |
| Respond to support, legal and privacy requests | Performance of a contract, steps requested by you, legitimate interests and compliance with legal obligations |
| Establish, exercise or defend legal claims | FSS's legitimate interests |
The Hub does not use Google identity information for advertising, data brokerage, unrelated profiling or training a general-purpose artificial-intelligence model.
6. Google user-data disclosure
The Hub requests only openid, email and profile for the user-facing purposes described in this policy.
Information received from Google is used to:
- authenticate the user;
- verify the signed identity assertion;
- locate, create or secure the corresponding Hub account;
- link the Google subject to that Hub account; and
- provide the resulting Hub identity and authorised access to registered applications.
The Hub does not sell Google user data or disclose it to unrelated third parties. It shares the resulting Hub identity claims only with registered applications through an authorised login or access flow as described in section 4.4.
FSS's use and transfer of information received from Google APIs is limited to these disclosed practices and is intended to comply with the Google API Services User Data Policy, including its Limited Use requirements.
Google independently processes information when providing Google Account and sign-in services. Google's own terms and privacy policy apply to that processing.
7. Recipients
Personal data may be received by:
- registered FSS applications and clients, limited to the claims, scopes and resource-specific information authorised for their login or access flow;
- Google, when you choose Google sign-in;
- authorised FSS personnel, where required for account administration, support, deployment, security investigation or legal compliance;
- FSS's hosting, connectivity and email infrastructure providers, to the extent needed to operate the service and transmit encrypted traffic or account messages;
- professional advisers, auditors, insurers, courts, regulators or public authorities, where legally permitted or required.
The Hub's current production application is hosted on FSS-controlled infrastructure in Bulgaria. FSS does not sell personal data.
8. International transfers
The Hub's current production infrastructure is located in Bulgaria, within the European Union.
Google may process sign-in information in the EEA and in other countries in which Google or its service providers operate. Google's transfer arrangements apply to Google's processing.
Where FSS appoints a processor that transfers personal data outside the EEA, FSS requires an applicable lawful transfer mechanism and appropriate safeguards.
9. Retention
The Hub retains records according to their purpose, configured expiry, operational cleanup jobs and legal requirements.
The implementation defaults at the date of this policy are listed below. A deployment may use different configured values; the values published here must match production.
| Data | Current implementation behavior and default |
|---|---|
| OAuth authorisation codes | Single-use; default validity 5 minutes |
| Access tokens | Short-lived; default validity 1 hour |
| OpenID Connect ID tokens | Default validity 1 hour |
| Refresh tokens | Default validity 30 days and rotated on successful use where enabled |
| Expired access/refresh token records | Cleanup eligibility after the configured post-expiry window; code default 7 days |
| Browser sessions | Until logout, administrative invalidation or configured session expiry; code default 120 minutes of lifetime |
| Self-registration intents | Single-use; default validity 30 minutes |
| Email-verification links | Single-use; default validity 24 hours |
| Expired or consumed registration-intent records | Cleanup threshold default 7 days |
| Expired or consumed email-verification records | Cleanup threshold default 7 days |
| Abandoned, unverified password-registration accounts | The scheduled sweep identifies accounts after the configured threshold, default 30 days, but is report-only. Removal requires a deliberate administrator action. |
| Dynamically registered ownerless clients | Become prune candidates after configured inactivity, default 30 days; the normal prune action deactivates them rather than promising immediate deletion |
| Account and Google identity-link data | Retained while the Hub account remains present, unless an administrator removes the link or deletes the account, or longer retention is required by law |
| Remembered application approvals | Retained until withdrawn or otherwise administratively removed; withdrawing an approval affects future prompts and does not by itself revoke tokens already issued |
| Repository-style Hub audit records | Code default retention 7 days, subject to deployment configuration and an active investigation or legal hold |
Operational web-server, system, mail and security logs may follow separate FSS retention schedules. We may keep limited records longer where required by law or necessary to investigate abuse or establish, exercise or defend legal claims.
10. Security
The Hub currently uses controls including:
- HTTPS transport;
- one-way password, client-secret, access-token and refresh-token hashes where stored;
- short-lived authorisation codes and access credentials;
- PKCE for supported public-client flows;
- OAuth
stateand OpenID Connectnoncevalidation; - signature, issuer, audience, expiry and nonce validation for Google ID tokens;
- refresh-token rotation and revocation paths;
- signed Hub ID and access tokens where the target resource server requires them;
- per-client, per-user and per-resource-server scope controls;
- tenant and resource-specific bindings;
- login throttling and temporary lockout controls;
- restricted administrator functions; and
- security and authorisation audit records.
No online service can guarantee absolute security. Users must protect their email account, passwords, devices and client credentials and notify FSS promptly of suspected misuse.
11. Your controls and rights
Depending on the circumstances and applicable law, you may have the right to:
- access personal data held about you;
- correct inaccurate or incomplete data;
- request deletion;
- restrict processing;
- receive portable data where applicable;
- object to processing based on legitimate interests;
- withdraw consent where consent is the legal basis; and
- lodge a complaint with a supervisory authority.
The Hub account page currently lets you withdraw remembered approvals for future authorisation prompts. This does not automatically revoke access or refresh tokens already issued to that client. Contact FSS where immediate token or account intervention is required.
The Hub does not currently provide a self-service account-deletion or Google-unlink button. To request account deletion, identity unlinking, correction of the read-only account email, or another privacy action, contact info@finite-soft.com. We may need to verify your identity and coordinate the effect on each connected application.
You may also revoke the FSS MCP Hub's access from your Google Account settings. Revoking it at Google prevents a future Google sign-in until it is authorised again, but it does not by itself delete the local Hub account or the historical local identity-link record. Contact FSS to request local deletion or unlinking.
If an organisation manages your access, FSS may need to coordinate an access change with that organisation. Application-specific data must be requested from the controller identified in the application's own privacy policy.
12. Children
The Hub is designed for business and organisational use. It is not directed to children, and FSS does not knowingly invite children to create Hub accounts.
13. Changes to this policy
We may update this policy when the Hub, its connected applications, identity providers, configuration or legal obligations change. The current version will show its last-updated date. Where required, we will provide additional notice or request renewed authorisation.
14. Complaints
You may complain to the Bulgarian supervisory authority:
Commission for Personal Data Protection
2 Prof. Tsvetan Lazarov Boulevard
1592 Sofia, Bulgaria
You may also contact the supervisory authority in the EU or EEA country where you live or work.
15. Contact
Finite Software Systems Ltd.
Contact address: 180 Vitosha Boulevard, 1408 Sofia, Bulgaria
Registered office: 4 Gorotzvet Street, 1421 Sofia, Bulgaria
Email: info@finite-soft.com
Telephone: +359 2 439 21 00