Would you like your AI assistant to work with HURMA? We’ll explain what data it can see, whether it will get access to the entire database, and what happens if you need to disconnect it.
In HURMA, data access is controlled at several levels. AI does not receive separate or expanded permissions simply because it is connected. On the contrary, for a specific integration, you can further define what information it is allowed to read and which company employees can use it.
Connecting an AI assistant does not give it access to all the information stored in the system.
First, access cannot exceed the permissions of the HURMA user on whose behalf the connection operates. Second, when creating the connection itself, you can further define what data AI is allowed to read.
In other words, a chat request cannot expand access. If the user or a specific connection does not have permission to access certain information, AI will not receive it.
When configuring the connection, HURMA lets you choose what information AI can use for responses and analytics.
You can configure access to employee and candidate fields separately. You don't have to make everything available: for a specific use case, you can leave only the data you need and withhold sensitive fields.
This is especially important when AI is used for analytics, where calculations may require statuses or other work-related data, for example, but not a person's contact details or home address.
AI doesn't always need to know the name of a specific employee or candidate to perform analytics.
Every record in HURMA has an internal ID. This means you can withhold full names, contact details, addresses, and other fields that aren't needed for a specific task, while still allowing records to be distinguished from one another.
The internal HURMA ID can be used in place of a name in the results. If needed, a user with the appropriate permissions can match it to a specific profile within the system.
In other words, less information is shared externally, while the system can still distinguish between records.
When creating an AI connection, you need to specify which company employees can use it.
Having a HURMA account does not automatically grant access to all created integrations. Even the person who created the connection must be added to the list of users authorized to use it.
The company can also create several separate connections with different permissions for different tasks or teams.
The current connection is read-only.
AI can access permitted data, analyze it, and use it to provide an answer or report. However, it cannot create new records or modify existing information in HURMA through this connection.
For example, AI can help identify vacancies that have remained open for a long time, but it cannot change their status on its own.
In HURMA, you can manage created connections, the list of employees with access, and connection status.
If an integration is no longer needed or a specific user’s access needs to be discontinued, it can be revoked. After that, the associated authorization data becomes invalid and cannot be used to make new requests to HURMA.
These are the key mechanisms for IT and security teams, from authentication to logging.
MCP (Model Context Protocol) is used to connect AI clients to external systems.
HURMA MCP works through a separate intermediary service and accesses data via HURMA API v3. AI clients do not connect directly to the HURMA database.
Authentication is based on OAuth 2.1 mechanisms using the authorization code flow and PKCE S256.
The user signs in on the HURMA side. The login and password are not shared with the AI client or MCP service: after successful authorization, interaction takes place through tokens.
The scenario in which an external system obtains a user's password and exchanges it for a token is not used for the MCP client.
HURMA accounts are additionally protected by hashing passwords with bcrypt, limiting the number of login attempts, and using two-factor authentication.
MCP does not have separate privileged access to HR data.
The HURMA API v3 permissions model is applied on the server side. For each request, the system checks whether:
whether the token exists and is valid;
whether it has not been revoked;
whether the user is active;
whether this user is allowed to work with the specific connection;
whether the client has the required scope—the permission for the relevant type of operation;
whether the requested data and fields are permitted.
If the required authorization is not available, the request is rejected with the appropriate HTTP status code 401 or 403 before the data operation is performed.
Separately, when creating an MCP connection, access to available employee and candidate fields can be restricted. Therefore, actual access is determined by both the HURMA user's permissions and the permissions of the specific connection.
HURMA determines which workspace a request belongs to based on the validated token, not on a parameter passed by an external client.
Therefore, changing the company identifier in the URL, parameters, or request body does not allow a valid token to be used to access another instance. Each HURMA instance is isolated as a separate tenant and has its own token signing key.
External communication with the service takes place over HTTPS. Unencrypted traffic to the service is not permitted at the infrastructure level.
Access tokens are transmitted only via the Authorization HTTP header. They are not added to URLs or query parameters, where they could end up in browser history, proxy caches, or other technical logs.
One-time codes are used for authorization: once exchanged for a token, the code becomes invalid.
Refresh tokens are rotated. When access is refreshed, a new refresh token is issued, and the previous one can no longer be used. Token lifetimes can be configured for a specific HURMA instance.
API tokens and keys are generated using a cryptographically secure random number generator. Stored OAuth client secrets and HURMA tokens are encrypted using Fernet.
Active MCP connections and the users who have access to them can be viewed and managed in HURMA.
When access is revoked, the associated access and refresh tokens are revoked. The previously authorized client can no longer use them to make new requests.
This makes it possible to terminate access for both a specific user and an integration that is no longer in use.
No. MCP does not act as a universal proxy to the internal HURMA API.
A defined set of routes required for authorization and MCP functionality is exposed externally. The operations an AI client can call are determined by the implemented tools, and the identifiers and other parameters provided are validated by the server.
Internal services and databases are located on a private network and are not directly accessible from outside.
To monitor the service's operation, HURMA maintains operational logs.
They store technical metadata needed to monitor stability, such as the tenant identifier, route, and response status code.
However, access tokens and request and response bodies are not recorded in operational logs.
Thus, diagnosing the integration's operation does not require duplicating the HR data transmitted as part of the request in technical logs.
When an AI assistant receives data from HURMA, further processing takes place on the AI provider's side (for example, Anthropic, OpenAI, or another service you use). HURMA does not control how long this data is stored within the AI client's session or whether the provider uses it; this is determined by the agreement between your company and the AI provider.
Therefore, we recommend that before connecting you:
review your AI provider’s data processing policy, in particular whether data is used to train models and what retention periods apply (for business plans, providers usually offer options that do not use customer data for training, as well as data processing agreements, or DPAs);
transfer through the integration only the minimum fields needed for the specific task—that’s exactly why HURMA lets you configure the available fields and use internal IDs instead of names and contact details;
if necessary, coordinate the connection with your DPO or legal team if the integration transfers personal data belonging to employees or candidates.
HURMA controls which data can leave the system, while the choice of AI provider and the processing terms on its side remain under your company’s control.
HURMA’s AI integration does not create separate, unrestricted access to HR data.
Access is determined by user permissions and the settings for the specific connection. You can also control which employee and candidate fields are available, avoid transferring unnecessary personal data, specify which users can access the integration, and revoke their access.
At the technical level, these restrictions are complemented by validation of every request, instance isolation, secure data transmission, token rotation and revocation, a closed network perimeter, and limited logging.
That is, AI receives controlled read access to specifically permitted data within the granted permissions.
