AlertaVuln AI
There are two ways AI shows up in AlertaVuln, and they are genuinely different in what happens to your data. The distinction is the whole point, so it is worth being blunt about it rather than marketing over it.
Available today: BYOAI (bring your own AI)
Section titled “Available today: BYOAI (bring your own AI)”No model operated by us is in the path of your data. AlertaVuln assembles the context for a question - the finding, its reachability verdict, the package and version, the file and line - and hands that structured context to your assistant, through an IDE handoff or a prompt you copy. Whatever a model sees is seen under your organisation’s own AI policy, your own tenancy, and your own agreement with whoever provides it.
This is the default and it needs no consent flow, because there is nothing for you to consent to: we are not processing anything with a model. It is also why the feature works for organisations whose policy forbids sending code to third-party models at all.
Not yet available: hosted AlertaVuln AI
Section titled “Not yet available: hosted AlertaVuln AI”The hosted service would let AlertaVuln call a model on your behalf, for the cases where a handoff is awkward - explaining a finding in place, or drafting a fix. Everything in this section describes intended behaviour of an unreleased feature.
Off until you turn it on
Section titled “Off until you turn it on”It will be optional and off by default, activated only by an organisation administrator, and disabling it stops all model calls immediately. Consent is recorded with a version, so a change to what the feature does requires fresh consent rather than inheriting the old agreement.
Fair use
Section titled “Fair use”Hosted AlertaVuln AI is metered and subject to fair use. Unlike every other module, each call costs real inference, so the per-seat price buys a generous but finite monthly allowance rather than unlimited use.
Sustained heavy use may be throttled, or need a higher tier. Throttling is not silent: the server reports it as a distinct state rather than failing the request as though something broke, so you can tell “we are over the allowance” from “the model errored”.
BYOAI is unaffected by any of this - you are paying your own provider, and we are not in the loop to meter anything.
Where the model runs
Section titled “Where the model runs”Requests would go to an Azure AI Foundry resource in Australia East, provisioned inside our own Azure subscription rather than a shared or third-party endpoint. Authentication is managed-identity only - the account has key authentication disabled, so there is no API key in existence to leak.
Microsoft does not use these inputs to train its models.
What would be sent
Section titled “What would be sent”The minimum the feature needs, and no more: finding metadata, the reachability verdict, package and version, and - for code-aware features only - the specific snippet the finding points at. You are shown what will be sent before you enable it.
Everything that originates in your repository is treated as hostile input before it reaches a model. Scanner messages routinely embed the matched source line, and file paths and rule identifiers come from the scanned tree, so anyone who can land a file in your repository can write text that reaches an assistant. That text is fenced and labelled as data, its structural machinery is stripped, and it is capped in size. We do not claim to “detect prompt injection” - natural language cannot be filtered reliably, and pretending otherwise is how these systems get compromised. The real containment is that no model output is ever granted a privileged action: a suggested fix becomes a draft pull request on a fresh branch and nothing else, and it fails closed if it cannot be verified.
What would be kept, and what is audited
Section titled “What would be kept, and what is audited”This is where the hosted service genuinely differs from BYOAI, so it gets stated directly rather than buried.
Every hosted AI call produces two records:
- A usage record - which organisation and project, which user asked, which feature, which model, the token counts, how long it took, and the outcome. Outcomes include the calls that were refused or denied, not only the ones that succeeded, because “how often were we turned down, and why” is the question an investigation asks first. This record contains no prompt or response content.
- The conversation itself, written to a separate locked-down store. It is write-once, so a conversation cannot be quietly rewritten afterwards; it is unreachable from the public internet; it has no account key, only revocable managed-identity access; and its path carries the organisation and the finding, never a user identity or an email address. In production it is held under a retention policy that prevents deletion or modification inside the window, including by an administrator.
The purpose of keeping the conversation is to be able to answer, later and under scrutiny, exactly what was asked and what was answered. An assistant that suggests a change to security-relevant code and leaves no reproducible record is not something we are willing to operate.
You will always be able to see your organisation’s AI usage. The exact request contents for each feature will be documented here before that feature ships.