Privacy

Vora is a security product of Chroma Labs. Questions about this page, and the access and erasure requests described below, go to contact@chrom.ar.

When an organisation connects Vora to its GitHub organisation, Vora reads the pull requests it is asked to review and the code those pull requests touch. The access is read-only, limited to the minimum GitHub scopes a review needs, and scoped to pull requests: Vora has no access to production systems, and it never merges.

Each review produces findings — a defect, the file and line it sits on, a severity, and a suggested change. Findings are kept so that a later review of the same repository can tell a new problem from one it has already reported or seen resolved.

What Vora writes back is narrow, and worth stating exactly: a check run on the commit, and comments on the pull request — the inline findings, plus status comments when a run finishes or a finding is proved, resolved, withdrawn, fixed or reopened. It does not push commits, open pull requests, modify repository contents, or merge. Where a fix is proposed it is a diff, rendered in Vora's own interface for a person to read and apply themselves; it is never applied for you and never sent to the provider.

The Vora app for Microsoft Teams answers questions about findings that already exist. It performs no write actions: it cannot start a scan, and it cannot change the status of a finding.

It receives only the messages addressed to it. In a channel, the app is sent an activity only when a message @mentions it directly. It declares no resource-specific consent permissions — neither ChannelMessage.Read.Group nor ChatMessage.Read.Chat — so it has no means of reading the rest of a channel's conversation, before or after the mention. In a one-to-one or group chat, it receives the messages sent to it.

Message content is stored. The Bot Framework offers no operation that reads a conversation back, so a multi-turn exchange only works if Vora keeps its own transcript of it. Full message bodies are retained for 90 days and then deleted. That is a deliberate choice rather than a side effect. Alongside the text, each exchange carries:

• the Microsoft tenant id of the organisation,
• the conversation and channel ids the exchange belongs to,
• the Microsoft Entra object id of each person who writes to the app,
• and the text of the messages addressed to the app.

Each person links their own Vora account once, through a signed link, so the app answers as that person and never on anyone else's behalf.

Messages pass through the Microsoft Bot Framework on their way to and from Teams, which is how any Teams app receives them at all.

The app published in the Microsoft store is Vora's hosted deployment, so the transcript is held in Vora's own systems rather than inside your tenant.

Removing the app deletes both: when Microsoft delivers the uninstall event, the tenant's transcript and its account links are purged. What survives is the conversation record itself — a tenant id, a thread id and a service host — which is destination configuration and holds nothing about a person.

Slack message content is not stored at all. The integration keeps one row per person — the Slack team id, the Slack user id, and the Vora account that person links to — and nothing else.

The difference from Teams is not a difference in policy. Slack's API can read a thread back, so Vora fetches the recent messages it needs when a question arrives, uses them to answer, and keeps none of them. The Bot Framework has no equivalent operation, which is the whole reason the same feature in Teams requires a stored transcript.

Finding a defect, and answering a question about one, is done by a large language model. The code under review and the messages addressed to Vora are sent to the configured provider — Anthropic by default, or an endpoint your organisation configures instead — for as long as it takes to produce the answer.

Vora does not train on any of it. Your code, the findings derived from it and the messages you send Vora are not used to train or improve any model, and Vora runs no process that would. What the configured provider does with what it receives is governed by that provider's terms rather than by this page — Anthropic's terms state that inputs submitted through its API are not used to train its models, and an endpoint your organisation configures instead is governed by whatever your organisation agreed with whoever operates it.

Requests to vora.chrom.ar are logged by the infrastructure that serves it, as on any web server. The site sets no cookies and loads nothing from a third-party domain. A single browser local-storage entry, vora-lang, remembers your language choice and never leaves your browser.

Where the GDPR applies, the processing described above rests on legitimate interest, Article 6(1)(f): an organisation connects Vora in order to have its code reviewed, and what is set out here is what that review needs. The data is not kept longer than that purpose requires — the storage-limitation principle, Article 5(1)(e) — which is what the 90-day limit on Teams message bodies implements.

Two rights are implemented as working operations rather than as a promise: access, Article 15, which returns an export of the data held about you, and erasure, Article 17, which deletes it. Both are honoured on request.

To make either request, write to contact@chrom.ar and say which organisation it concerns and which integration — Teams, Slack or GitHub.

The date at the top of this page changes when its substance does.