Security in SLAtech Vantage: how it is built and where it stops

SLAtech Vantage keeps the data of many organizations in one database and separates them with a filter applied to every query. Sign-in uses a one-time code with no passwords, keys to connected systems are encrypted, personal data is replaced with tokens before any text goes to the language model, and the client reads the data access log of their own project. Below, each mechanism is described as it is built in the code, together with what it does not cover.

Who sees what: organizations, projects, participations

The data of all organizations lives in one database. Separation is done by global query filters: every query for project data is limited to the projects in which the user's organization participates. The filter is translated to SQL and runs in the database itself, not in application memory.

• Access comes from participation. An organization participates in a project as the client or as a provider. There is no access field that someone fills in by hand: no active participation, no data. An ended participation deletes nothing, but it stops access.
• No sign-in, no data. A request without authentication gets an empty set of projects, not "everything".
• A provider sees its own tasks. A task is visible to a provider only if the provider's organization is assigned to it. A new provider on a project gets the project knowledge, but not the previous provider's correspondence and rates.
• Permissions are rebuilt. The project list is stored in the sign-in ticket and rebuilt from participations periodically, every 30 minutes by default. So a revoked participation does not stop working in the same second.

Platform operator accounts, meaning SLAtech, and background processes (sync, indexing) are not narrowed by the filter: without that, incoming data could not be routed to projects and failures could not be investigated. How this shows up in the access log is described below.

Sign-in: a one-time code instead of a password

There are no passwords in the system, so there is nothing to guess, reuse or lose in someone else's breach. A person enters an email address, and if an account exists, a 6-digit code valid for 10 minutes is sent to it. For an unregistered address the screen answers exactly the same way, and no email is sent.

• The database stores a hash of the code, not the code. The code is single use: it is consumed on sign-in.
• Each code allows 5 attempts. An attempt is counted by one conditional update before the comparison, so parallel requests cannot get around the limit.
• Per address: at most 5 codes an hour and no more than one every 30 seconds.
• A network address that sent 10 code requests with none confirmed is blocked until an hour has passed since its last request. A correct code resets the counter, so an office that goes online from one address is not blocked.
• A session lasts 7 days and is extended while the person keeps working. Invitation tokens, like codes, are stored as hashes.

The network address counter is kept in process memory and resets when the process restarts. The per email limits do not depend on it: they are stored in the database.

Permissions inside the organization, and what stays internal

The organization owner grants permissions to each person separately: money (rates and amounts, off by default), reports and creating tasks. The organization owner always sees money.

• A person without the money permission sees no amounts on screens or in the access log: the event row stays, the values are removed. In email text and chat answers, numbers next to a currency or a price word are hidden from them.
• Internal notes and a task's internal resolution are not shown to the client, neither on screen nor in chat answers. A separate description of the work is written for the client.
• The provider's internal split of hours does not reach the client portal, PDF, Excel or the monthly report. An automated test guards this: if the field appears in data that goes to the client, the test fails before release.

Hiding amounts in text relies on the pattern "a number next to a currency or a price word". A phrase without a number, such as "at the usual rate", is not hidden.

What goes to the language model and how it is masked

Chat, project search and part of the analysis use an external language model. Before sending, the text is masked: personal data is replaced with tokens, the model sees only tokens, and the real values are put back into the answer on our side. Users see the real data; tokens exist only at the boundary with the model.

• What is replaced: email addresses; Israeli phone numbers; Israeli ID, company and business numbers that pass the check digit; passport numbers next to the Hebrew word for passport; names of people from the name dictionary and from the project's contact cards.
• Secrets are removed irreversibly. Passwords, API keys, tokens and connection strings written in text, including inside link addresses, are replaced with a token that cannot be reversed, neither by the model nor by us.
• Each project has its own token registry. The real values behind tokens are stored encrypted. Values are put back only from the map of the current request, so a token taken from another answer cannot be opened. Strings shaped like our tokens that are typed into chat are stripped before processing.
• The search index is built from masked text. For indexing, the model receives the same text with tokens.
• Text recognition on scans runs on our server, not in an external service, so a scanned document does not leave just to be recognized.

Masking is called at every place where the code talks to the model. An automated test walks all those places and fails if one of them neither masks the text nor appears in the exemption list with a written reason. The test proves that masking was not forgotten, not that it caught everything.

What masking does not cover

Masking is built on patterns and a dictionary, and it has known limits:

• A name that is neither in the dictionary nor in the contact cards can reach the model in clear text.
• Names of active employees and contractors from the project's contact cards are not masked when written in full or as a first name only: the model needs to understand who does what. A surname on its own is masked.
• A specification uploaded for an hours estimate, and the text a specification is composed from, go to the model as they are, images included. It is better not to put personal data in such documents.
• To grow the name dictionary, single words are sent to the model without the surrounding text, and the model decides whether each one is a name or an ordinary word.
• Code analysis of a task, where it is enabled, reads a copy of the repository with read and search rights only. The code itself is not masked, only the task text is.

Keys to connected systems, and what we write back

To pull tasks, hours, code and email, SLAtech Vantage needs access to your system: a Jira or GitHub token, a Freshservice API key, a Google or Microsoft permission to read a mailbox.

• The key is encrypted before it is written to the database. Each kind of key has its own encryption key, so exposing one kind does not open the others. Encryption keys are kept outside the database.
• After saving, the key never returns to the interface and is not written to server logs.
• A key belongs to the person who connected it, and someone else's key is never used in its place. When a connection is removed, the encrypted key is deleted with it.
• Mail connects with read-only permission (gmail.readonly, Mail.Read). Tasks, code, errors and hours are only read.

One connection writes to the external system, Freshservice: a ticket status change and a public reply on the ticket, when the provider does this from the task card. SLAtech Vantage writes nothing to your repository, Jira or error trackers.

Access log: the client reads it in their portal

The client portal has an "Access log" item. There the client sees who, from which organization and when, touched the data of their project. Two kinds of events are recorded:

• Changes: created, updated, deleted. For an update, the log records which fields changed and to what. Recording happens by itself when data is saved to the database, not through a call from each screen, so a new screen gets into the log with no extra work.
• Data taken out: a downloaded file (a specification and its files, a proposal, an attachment of a task, an email or a conversation, a knowledge base file), an exported monthly report, an issued public link to a proposal.

Data kinds in the log: tasks, time entries, recurring charges, departments, the project and its participations, invitations, contacts, mail filters, conversations, specifications, proposals and their lines, purchase orders, errors and error areas, knowledge base articles. The list is closed: anything not on it is not logged.

Limits. Screen views are not logged. Background processes with no person behind them are not logged. More than 20 objects of one kind in a single save collapse into one row with a count. Bulk updates that bypass the normal save path do not reach the log. A SLAtech employee who enters a project as the platform operator, rather than as a provider of that project, is not logged. The portal shows the latest 200 entries. Entries are kept for seven years.

Files, retention and server logs

• Files (email attachments, task and specification files, the knowledge base) are kept in private object storage with no public addresses. Downloads go through the application after an access check, and a download by a signed-in user is recorded in the access log.
• The access log is kept for seven years: the period during which a claim on an obligation can still be filed in Israel. The period is configurable.
• The portal activity log (client sign-ins, page and report views, exports) is kept for 12 months and cleaned by a daily job.
• Chat questions and answers are kept in the chat log with no automatic deletion.
• Server logs roll over by day and by size, and the last 20 files are kept. Error reports go to an external error monitoring service without email addresses, cookies or request bodies, and secrets are stripped from the request address.
• Project data is not deleted automatically after a period. A task deleted in the interface goes to an archive and is not erased from the database.

Connection, headers, and what we do not have

• The site and the application work over HTTPS only: an HTTP request is redirected, and a one-year HSTS header keeps the browser from opening the site without encryption.
• Responses carry X-Content-Type-Options: nosniff and Referrer-Policy: strict-origin-when-cross-origin, and embedding the pages in frames on other sites is forbidden.
• On the pages opened from a document approval link, the Content Security Policy (CSP) is enforced and blocks foreign scripts. On the other pages it still runs in report-only mode: violations are collected but not blocked.

SLAtech Vantage was built with the Israeli Privacy Protection Law in mind, including Amendment 13: less data leaves, clients are separated, and what was done with the data is recorded. This is not a statement of legal compliance.

We have no ISO 27001, SOC 2 or other certification, and this page does not claim one. Nor do we claim an external penetration test here.

Frequently asked questions