AI processing: which providers receive your content

Which providers may receive your content

Three AI companies, and no others:

• OpenAI — chat models and the embedding model behind search.
• Anthropic — chat models (Claude).
• Google — chat models (Gemini).

Which of the three actually sees a given request depends on the model your team leader assigned to that job in the AI console, so a project can be configured to use one provider, two, or all three. Two jobs are the exception and always run on OpenAI — see below.

Requests go to the providers' own APIs. Signoos does not route your content through any other AI service, and no AI provider is given access to your GitHub account, your repository, or your Signoos session — only the payload described in the table below travels, as the body of one request.

It depends on your own choices

Four decisions of yours control what leaves Signoos:

• Code access, folder by folder. A project starts with code access off. Nothing in your repository is read — by Signoos or by any AI provider — until you turn it on, and then only inside the folders you shared. The check is applied again when the file is fetched, and it fails closed: if the rule cannot be evaluated, the read is refused.
• Whether you use the solver. The automatic solver is started per task, by a person, on purpose. It is the job that sends the most.
• Whether you add review sources. Insights is optional. With no review sources configured, there is nothing to mine and the mining stages never run.
• Whose provider account pays. Your own key, a member's key, or Signoos' — which decides whose contractual relationship with the provider governs the request. See below.

What is sent, job by job

Every job that can see repository contents is filtered by your folder consent first. Where a review or a diff had files removed for that reason, the model is told the count rather than being handed a diff that silently pretends to be complete.

Choosing the model: the AI console

Each project has an AI console. The team leader assigns a model to each role — task titles, code search, push review, task conversation, fix proposals, the solver, project Q&A and ticket drafting — from a catalogue of models across the three providers. Every member of the project can read the assignments, even though only the leader can change them.

A request always names a role, never a model, a provider, an endpoint or a key. If the assigned model cannot answer, Signoos falls back through a fixed order and the result says which model actually ran and why, rather than reporting the model you chose.

The embedding model behind search and the models behind review mining are pinned and are not selectable — changing them would change what the stored numbers mean.

Whose account pays, and what that changes

A project can bring its own provider keys (“BYOK”). A key you store is sealed with envelope encryption using a managed key service, bound to the scope and provider it was stored for, and it is never returned by any endpoint — not to you, not to the team leader, not to anyone. It is only ever unsealed to make a request you asked for.

Requests are funded down a ladder, and your preference prunes it:

• The project's own key, if one is stored and you are permitted to spend it. The leader grants that permission per member and per provider, and absence of a grant means no.
• Your personal key, if you stored one.
• Signoos' account, as a last resort, under fixed daily ceilings — and only while the project leaves that fallback switched on.

What changes with the funding source is who the provider's customer is. A request paid for by your key is a request your organisation made to that provider under your agreement with them, and their data-handling terms for your account apply to it. A request that falls through to Signoos' account is made under ours. The content sent is the same either way; the contract behind it is not. If your provider agreement carries commitments you rely on — retention, region, training — fund the work with your own key so those commitments are the ones in force.

Two jobs that always run on our OpenAI account

We would rather say this than let you infer the opposite from the paragraph above. Two jobs are not routed by the funding ladder and always run on OpenAI, on Signoos' own account, regardless of any key you store:

• Review mining — the Insights pipeline that turns your review sources into ranked, evidence-traced gaps. It sends review text, not code, and it only runs if you added review sources.
• The search index — the embedding model that makes search and retrieval work. It sends the text being indexed.

These are pinned because the numbers they produce are compared with one another across time; a swapped model would silently change the meaning of stored scores. If that routing is unacceptable for your content, do not add review sources — the rest of Signoos works without them.

Daily spend ceilings

AI usage is bounded by daily spend ceilings, checked before each call rather than observed afterwards. Work funded by Signoos' account runs under fixed per-project and per-account daily ceilings that we set. Work funded by a stored key runs under a daily and monthly ceiling belonging to that key, which the team leader sets, and a separate smaller share for any member other than the key's owner.

Ceilings fail closed. When the ledger that records spend cannot be read, the call is refused rather than allowed through unmetered. Spend figures are estimated from published list prices for budgeting; they are not an invoice.

Training

Signoos does not train models on your content. We build no models, we fine-tune none, and your code, tasks, reviews and tickets are not used to improve anything we offer to anyone else. Code is read on demand, for the job you asked for, and is not retained for training.

We do not make that claim on behalf of the AI providers. What OpenAI, Anthropic or Google may do with an API request is set by the agreement covering the account that paid for it — yours under BYOK, ours otherwise — and by each provider's own API terms, which we do not control and will not paraphrase here. Read those terms for the account you intend to use, and if your own agreement carries the commitments you need, fund the work with your own key.

How to use Signoos with no AI access to your code

• Do not grant code access. Leave it off, or turn it off later in the project's settings. Tasks, the team, the mirror browser and evidence-carrying tickets still work; what you lose is the pointer to the file and lines.
• Share fewer folders. With code access on, exclude any folder that must never be read. Matching is per path segment, so a folder that is not shared is not a candidate for any job.
• Do not run the automatic solver. It is never started for you.
• Do not add review sources. Without them, Insights and its pinned OpenAI stages never run.
• Choose your funding source. Set the project to spend only a key you control, so no request is made on an account you have no agreement with.

Contact

Questions about what a particular job sends, or about the providers behind your project's configuration: [email protected].

See also the Privacy Policy and the Terms of Service.