Assess the scope of the protection and the conditions for deploying it.
Before any integration you need to know what is checked, where the decision is made and what happens when a check does not run. This overview walks through those questions.
What is checked, and where the decision is made
One row per connected channel. A row is published only where the behaviour was read from the implementation; what we could not confirm is missing rather than guessed.
In plain words: a check can only decide where it actually runs. A script on a page records and scores, it does not enforce anything on your server, and a check that did not complete is never reported as a clean result.
| Channel | What is checked | Where the decision is made | If the check is unavailable | Limits |
|---|---|---|---|---|
| Browser extension | Recognised personal and business values in the text about to be sent, and files added as attachments. | In the browser, before the text leaves it. The selected mode decides: warn, anonymise, redact or block. | A file the reader cannot open is reported as not scanned, with a reason — never as clean. | The supported sites are ChatGPT, Claude and Gemini. The deep check and the server-side file check are calls that leave the computer. |
| Web form | Whether the submission carries a widget token and whether it verifies, and the content quality of the named fields. | In the form handler on your server. | A token that could not be checked is recorded like a missing one and never refuses the submission. | Refusal stays off until an operator switches it on for the site. A missing token is accepted: a visitor with no JavaScript looks the same. |
| Sign-in | That an attempt happened and whether it succeeded, as an event on the login surface. | Nowhere. This channel records; the credential check decides on the sign-in. | Nothing changes for the person signing in. | The event is filed only when exactly one registered site matches the origin of the request. No e-mail and no password enter it. |
| REST check | The payload you send: injection patterns, and the content quality of named form fields. | In your application. The endpoint answers; your handler decides what to do with the answer. | A failed call is an outage of a call your own code makes, so your handler decides. Nothing is refused on our side. | Only what you send is checked. Content-quality signal names stay in the server answer and are not echoed back to the browser. |
| AI proxy — input | Prompt text that arrived from outside. Your own system instruction is deliberately not judged as an attack. | Before the request is forwarded to the provider: a refused one gets an error with a reference instead. | A body that cannot be parsed is forwarded and the failure logged; nothing is refused because of it. | A finding may refuse a request only on the request shapes that are parsed precisely — OpenAI chat completions and responses, Anthropic messages. On any other shape the finding is recorded and the request goes on. |
| AI proxy — output | The model's reply, for data that should not leave. | Without streaming, before the reply is handed over, and the content is redacted. With streaming, only the bytes in the middle of forming something the renderer would fetch by itself are held back. | If the output check fails, the provider's reply is returned as it came. | Streaming cannot retract what has already been sent, and a value the check does not recognise leaves with the stream. Past the hold-back ceiling the guard releases what it holds. |
| Document | Structure first — extension, the actual file type, size, macros, scripts in PDF, SVG and HTML — then the antivirus and rule layer where it is available. | On upload, before the file reaches its final place. | In the recording mode the verdict is noted and nothing is refused. Where refusal is switched on, a file that nothing scanned is held, while a malfunction of the structural gate lets the file through and raises a loud alert. | A tenant who never chose a mode runs in the recording one: scanned, recorded, never refused. |
| MCP inspection tools | Only the text handed to the tool in the call. | In the answer: the finding comes back with the result as a notice, and the inspection tools themselves are never refused. | The tool answers without the finding. | A tool being offered does not mean the whole agent is being scanned. A per-session cap on tokens, calls, time and cost can be configured, but this path only measures against it: a call is never refused because a cap was reached. |
| MCP gateway | Every tool call that goes through it: the class of the tool and the intent inferred from the arguments, against the policy. | Before the tool runs. A blocked call is refused; a call bumped for approval is held only when the operator switched holding on. | When the classification fails, a call in a high-risk class — or one with no class at all — is held; everything else proceeds without it. | A tool missing from the class map counts as read-safe. Calls that do not pass through this gateway are not covered. |
In plain words: a check can only decide where it actually runs. A script on a page records and scores, it does not enforce anything on your server, and a check that did not complete is never reported as a clean result.
| Channel | What is checked | Where the decision is made | If the check is unavailable | Limits |
|---|---|---|---|---|
| Browser extension | Recognised personal and business values in the text about to be sent, and files added as attachments. | In the browser, before the text leaves it. The selected mode decides: warn, anonymise, redact or block. | A file the reader cannot open is reported as not scanned, with a reason — never as clean. | The supported sites are ChatGPT, Claude and Gemini. The deep check and the server-side file check are calls that leave the computer. |
| Web form | Whether the submission carries a widget token and whether it verifies, and the content quality of the named fields. | In the form handler on your server. | A token that could not be checked is recorded like a missing one and never refuses the submission. | Refusal stays off until an operator switches it on for the site. A missing token is accepted: a visitor with no JavaScript looks the same. |
| Sign-in | That an attempt happened and whether it succeeded, as an event on the login surface. | Nowhere. This channel records; the credential check decides on the sign-in. | Nothing changes for the person signing in. | The event is filed only when exactly one registered site matches the origin of the request. No e-mail and no password enter it. |
| REST check | The payload you send: injection patterns, and the content quality of named form fields. | In your application. The endpoint answers; your handler decides what to do with the answer. | A failed call is an outage of a call your own code makes, so your handler decides. Nothing is refused on our side. | Only what you send is checked. Content-quality signal names stay in the server answer and are not echoed back to the browser. |
| AI proxy — input | Prompt text that arrived from outside. Your own system instruction is deliberately not judged as an attack. | Before the request is forwarded to the provider: a refused one gets an error with a reference instead. | A body that cannot be parsed is forwarded and the failure logged; nothing is refused because of it. | A finding may refuse a request only on the request shapes that are parsed precisely — OpenAI chat completions and responses, Anthropic messages. On any other shape the finding is recorded and the request goes on. |
| AI proxy — output | The model's reply, for data that should not leave. | Without streaming, before the reply is handed over, and the content is redacted. With streaming, only the bytes in the middle of forming something the renderer would fetch by itself are held back. | If the output check fails, the provider's reply is returned as it came. | Streaming cannot retract what has already been sent, and a value the check does not recognise leaves with the stream. Past the hold-back ceiling the guard releases what it holds. |
| Document | Structure first — extension, the actual file type, size, macros, scripts in PDF, SVG and HTML — then the antivirus and rule layer where it is available. | On upload, before the file reaches its final place. | In the recording mode the verdict is noted and nothing is refused. Where refusal is switched on, a file that nothing scanned is held, while a malfunction of the structural gate lets the file through and raises a loud alert. | A tenant who never chose a mode runs in the recording one: scanned, recorded, never refused. |
| MCP inspection tools | Only the text handed to the tool in the call. | In the answer: the finding comes back with the result as a notice, and the inspection tools themselves are never refused. | The tool answers without the finding. | A tool being offered does not mean the whole agent is being scanned. A per-session cap on tokens, calls, time and cost can be configured, but this path only measures against it: a call is never refused because a cap was reached. |
| MCP gateway | Every tool call that goes through it: the class of the tool and the intent inferred from the arguments, against the policy. | Before the tool runs. A blocked call is refused; a call bumped for approval is held only when the operator switched holding on. | When the classification fails, a call in a high-risk class — or one with no class at all — is held; everything else proceeds without it. | A tool missing from the class map counts as read-safe. Calls that do not pass through this gateway are not covered. |
The checks behind those channels
The matrix says where a decision is made. This part says what produces the finding. In IT mode the details are open.
Behavioural signals and scoring
The widget reports how the form was worked with: typing rhythm, cursor movement, time to the first input, pasting, scrolling. From those signals, and the rules a site has switched on, a score is assembled.
You see the score, its breakdown and the rules that fired.
Signals are assembled into a session profile that can be compared with another session of the same site. The score comes from rules — signal, weight, an optional threshold — and the event records both the breakdown and the list of rules that actually applied. Block rules on an address, a device fingerprint and a user agent are kept apart, so “rules applied” keeps meaning scoring rules. Alongside your own signals comes the reputation of an address from public threat-intelligence sources, or from paid ones under your own key. The boundaries between recording, monitoring, a challenge and a stop are set per site.
Signals are assembled into a session profile that can be compared with another session of the same site. The score comes from rules — signal, weight, an optional threshold — and the event records both the breakdown and the list of rules that actually applied. Block rules on an address, a device fingerprint and a user agent are kept apart, so “rules applied” keeps meaning scoring rules. Alongside your own signals comes the reputation of an address from public threat-intelligence sources, or from paid ones under your own key. The boundaries between recording, monitoring, a challenge and a stop are set per site.
Semantic content check
A pattern catches a known wording; a rephrased one looks different. So the text is also compared by meaning against a collection of attack wordings — “ignore previous instructions” and “disregard the earlier directives” end up next to each other.
A finding rested on similarity of meaning, not on a pattern.
This layer runs beside the pattern check, not instead of it, and depending on the strength of the similarity it proposes an intervention or says nothing at all. When the comparison is unavailable it stays silent — a guess does not stand in for it, and the pattern check carries on. The model doing the comparison can run locally or at a provider; what runs where belongs in the deployment proposal.
This layer runs beside the pattern check, not instead of it, and depending on the strength of the similarity it proposes an intervention or says nothing at all. When the comparison is unavailable it stays silent — a guess does not stand in for it, and the pattern check carries on. The model doing the comparison can run locally or at a provider; what runs where belongs in the deployment proposal.
Traps and marked values
A page can carry a link and a field a person never sees: whoever uses them has given themselves away. Fake values can be scattered through the data in the same way.
A trap being taken is an event of its own, at high severity.
The hidden address answers with a neutral “accepted”, so the visitor does not learn they were caught, and records the event. A trap hit is not an addition to the score but a floor under it: it is not a degree of suspicion — the bait was taken or it was not — and a higher finding from another detector is left untouched. Fake values are matched as a hash, not as the value itself.
The hidden address answers with a neutral “accepted”, so the visitor does not learn they were caught, and records the event. A trap hit is not an addition to the score but a floor under it: it is not a degree of suspicion — the bait was taken or it was not — and a higher finding from another detector is left untouched. Fake values are matched as a hash, not as the value itself.
Payment cards
On payment attempts what is judged is the shape of the attack: one device working through many cards, a repeated card fingerprint, unusual clustering by issuer.
You see which rule fired and what intervention came out of it.
The verdict is composed from four rules. Only the one that recognises the shape of card testing reaches a stop on its own; the others each count a single dimension and raise suspicion. A pattern other shops have seen is capped below a stop — it is corroboration, not proof. The device is resolved from the token the shop already holds, so no device fingerprint is handed to a checkout page. Input containing a plain card number is refused at the edge, so such a number is never processed.
The verdict is composed from four rules. Only the one that recognises the shape of card testing reaches a stop on its own; the others each count a single dimension and raise suspicion. A pattern other shops have seen is capped below a stop — it is corroboration, not proof. The device is resolved from the token the shop already holds, so no device fingerprint is handed to a checkout page. Input containing a plain card number is refused at the edge, so such a number is never processed.
Files and attachments
An uploaded file goes to a holding area first. What is checked is what it actually is, not what it is called: the extension, the real file type, macros, scripts in PDF, SVG and HTML. The antivirus and rules follow where available.
You see the verdict and the reason; “not scanned” is a result of its own, not clean.
The structural check runs inside the application, the antivirus and rules in a separate process, and both results are folded into one verdict — in that order, so nothing shells out for a file the structural gate already rejected. When no tool was available at all, the verdict is “not scanned” and must not be read as clean. What happens to a verdict — hold, quarantine, record only — is decided by the configured mode, not by the check itself.
The structural check runs inside the application, the antivirus and rules in a separate process, and both results are folded into one verdict — in that order, so nothing shells out for a file the structural gate already rejected. When no tool was available at all, the verdict is “not scanned” and must not be read as clean. What happens to a verdict — hold, quarantine, record only — is decided by the configured mode, not by the check itself.
Model output
The model's reply is checked for data that should not leave. Without streaming it is rewritten before being handed over. With streaming, only the bytes forming something the renderer would fetch by itself are held back.
You see the finding, and whether it was held back or only recorded.
Held text is released before the stream's last frame, because a construct completed by the very last fragment is precisely what an attack aims for. The envelope of the stream — the finish reason, the usage, the tool calls — goes on byte for byte and in order; a guard that rewrites it breaks the client it protects. Streaming cannot retract what has already gone, and a value the check does not recognise leaves with it.
Held text is released before the stream's last frame, because a construct completed by the very last fragment is precisely what an attack aims for. The envelope of the stream — the finish reason, the usage, the tool calls — goes on byte for byte and in order; a guard that rewrites it breaks the client it protects. Streaming cannot retract what has already gone, and a value the check does not recognise leaves with it.
An agent's tool calls
Before it runs, a tool call is put in a class and compared with the intent inferred from its arguments. Depending on the policy it proceeds, goes for approval, or is stopped.
You see the call, its class and the reason for a stop or an approval.
Arguments are validated against the tool's schema, and the length of the chain of steps in one session is watched too. The tool's description and the text of its schema are read separately: an agent takes them as instructions, so a poisoned tool can hide an order in them that nobody expects behind a name like “add”. A tool missing from the class map counts as a safe read, and calls that do not pass through the gateway are not covered.
Arguments are validated against the tool's schema, and the length of the chain of steps in one session is watched too. The tool's description and the text of its schema are read separately: an agent takes them as instructions, so a poisoned tool can hide an order in them that nobody expects behind a name like “add”. A tool missing from the class map counts as a safe read, and calls that do not pass through the gateway are not covered.
Token reuse
The token a form received is not single-use — a double click or a page refresh are ordinary. So the number of its uses is counted.
A refusal for reuse carries its own reason, kept apart from content findings.
The signature and the age of a token were always checked; what was missing was counting its uses — a token harvested from a genuine browser otherwise authorised submissions until it expired. A score does not help here: the dangerous token is precisely a clean one from a genuine session. So the count of uses decides, and its boundary sits above anything a person reaches — which is why this check refuses in the standard setting already.
The signature and the age of a token were always checked; what was missing was counting its uses — a token harvested from a genuine browser otherwise authorised submissions until it expired. A score does not help here: the dangerous token is precisely a clean one from a genuine session. So the count of uses decides, and its boundary sits above anything a person reaches — which is why this check refuses in the standard setting already.
The checks below are present in the deployment, but not all of them are on by default — each one says whether it protects straight away or once you switch it on.
Learning from your own events
From what actually happens on your sites the protection proposes new rules by itself. A new rule first runs without effect and is watched; it starts to count only once it is confirmed. Security documents you add shape that proposal — the decision taken in the moment does not read them.
You see the proposed rules, how often each one bit, and you confirm or retire them.
Experience from other deployments
Attack patterns can be collected across deployments in an anonymous form — no content, no e-mail addresses, an address narrowed to its range. In the standard setting this is off and it is switched on only with your consent, from your own administrator account. Switching it on is written into the audit — who switched it on, and when.
A fresh pattern only watches at first; it begins to stop anything once enough deployments have confirmed it.
A catalogue of known web attacks
Input is compared with a catalogue of the classic attacks on sites and applications: injected database commands, scripts planted in a page, reading files that are none of the caller's business, operating-system commands, and calls aimed at your internal network. We keep the catalogue centrally and a deployment refreshes it on its own.
A finding says which class of attack it belongs to.
Brand impersonation and phishing
Links inside submitted messages and e-mails are checked for domains dressed up as yours: a swapped character, a different ending, your name buried in a longer address. Here it records only and refuses nothing. On attachments a finding does count towards the verdict — an impersonated bank or insurer, Slovak or Czech text written deliberately without accents, a password derived from a public identifier.
A finding on a link is an event of its own and is not mixed into the content verdict.
Crypto-wallet abuse
Model replies and documents are checked for wallet addresses, recovery phrases, requests to sign a transaction and mining scripts. A recovery phrase is the finding after which the text is not handed over as it was.
You see what was found and whether it was rewritten or stopped.
Country and address reputation
A visitor's country can be resolved, and an operator can leave countries out: a visitor from one of them never gets the page open and submits nothing. By default none is left out. Reputation from public sources runs with nothing to configure; paid sources you connect with your own key.
You see the country, the reason for a stop, and that reputation contributed.
Confirmation by a key in the device
A form can ask for confirmation by a security key or by a fingerprint in the device, a passkey. The server verifies the signature itself and the confirmation holds once. By default this only measures — it is protection we can give you once you switch it on for the forms you choose.
You see whether the confirmation was verified and whether it decided the pass.
Whether a text was written by a person or a model
A longer text can be assessed for signs of machine origin. It is a supporting signal on request, not an automatic part of judging every request, and it does not judge a short text at all.
The answer goes to whoever asked for it; it does not enter the event record.
A nightly run against the attack catalogue
Every night the protection takes a catalogue of known attacks down the same path real requests take and measures how many of them it stops. A drop in coverage is an alarm — that is how a change which quietly made something worse gets noticed.
It runs on our side and is not part of the customer overview.
Learning from your own events
From what actually happens on your sites the protection proposes new rules by itself. A new rule first runs without effect and is watched; it starts to count only once it is confirmed. Security documents you add shape that proposal — the decision taken in the moment does not read them.
You see the proposed rules, how often each one bit, and you confirm or retire them.
Experience from other deployments
Attack patterns can be collected across deployments in an anonymous form — no content, no e-mail addresses, an address narrowed to its range. In the standard setting this is off and it is switched on only with your consent, from your own administrator account. Switching it on is written into the audit — who switched it on, and when.
A fresh pattern only watches at first; it begins to stop anything once enough deployments have confirmed it.
A catalogue of known web attacks
Input is compared with a catalogue of the classic attacks on sites and applications: injected database commands, scripts planted in a page, reading files that are none of the caller's business, operating-system commands, and calls aimed at your internal network. We keep the catalogue centrally and a deployment refreshes it on its own.
A finding says which class of attack it belongs to.
Brand impersonation and phishing
Links inside submitted messages and e-mails are checked for domains dressed up as yours: a swapped character, a different ending, your name buried in a longer address. Here it records only and refuses nothing. On attachments a finding does count towards the verdict — an impersonated bank or insurer, Slovak or Czech text written deliberately without accents, a password derived from a public identifier.
A finding on a link is an event of its own and is not mixed into the content verdict.
Crypto-wallet abuse
Model replies and documents are checked for wallet addresses, recovery phrases, requests to sign a transaction and mining scripts. A recovery phrase is the finding after which the text is not handed over as it was.
You see what was found and whether it was rewritten or stopped.
Country and address reputation
A visitor's country can be resolved, and an operator can leave countries out: a visitor from one of them never gets the page open and submits nothing. By default none is left out. Reputation from public sources runs with nothing to configure; paid sources you connect with your own key.
You see the country, the reason for a stop, and that reputation contributed.
Confirmation by a key in the device
A form can ask for confirmation by a security key or by a fingerprint in the device, a passkey. The server verifies the signature itself and the confirmation holds once. By default this only measures — it is protection we can give you once you switch it on for the forms you choose.
You see whether the confirmation was verified and whether it decided the pass.
Whether a text was written by a person or a model
A longer text can be assessed for signs of machine origin. It is a supporting signal on request, not an automatic part of judging every request, and it does not judge a short text at all.
The answer goes to whoever asked for it; it does not enter the event record.
A nightly run against the attack catalogue
Every night the protection takes a catalogue of known attacks down the same path real requests take and measures how many of them it stops. A drop in coverage is an alarm — that is how a change which quietly made something worse gets noticed.
It runs on our side and is not part of the customer overview.
The paths by which protection enters your system
For each path, what you hand over and what comes back. The procedure and the code are on the integrations page.
- Widget on the page
You add one script with the site key. It hands over signals about the work on the form and returns a signed token you submit with the form.
- SDK and middleware
Ready middleware for Python, Node.js and PHP including Laravel, an add-on for WordPress and WooCommerce. It hands over the token and the submitted fields and returns a decision to your handler.
- REST check
You call the interface with the content to be examined, or with a token to verify. It returns the finding; what to do with it is your application's decision.
- Proxy in front of the model
You change the base URL of your OpenAI or Anthropic calls. It hands over both the prompt and the model's reply and returns them once checked.
- MCP gateway
An agent connects to the MCP interface. It hands over the tool name and the arguments and returns the result, or a refusal with a reason.
- Browser extension
It is installed in an employee's browser. It hands over the text about to go to a supported AI tool and returns it according to the chosen mode — a warning, anonymisation, a rewrite or a stop.
A decision needs a clear place where it is carried out.
Monitoring records a finding. An active mode can trigger an intervention in the connected flow. The behaviour on error is part of the deployment design, so it is clear when the application continues and when it stops the request.
Recording
The finding is written down and nobody is refused. This is where every channel starts.
Intervention
Only where the channel actually carries one: a refusal, a redaction, a hold. The matrix says which channel can do which.
On error
Every channel has its own answer, and it is never “clean”. Either the request goes on and the gap is recorded, or it is held — agreed per deployment.
What is recorded, and what the record is not
A record is not the communication
An event holds what a submission or a call carried and how it was judged, not the full content.
A hash is not a legal conclusion
An address is stored as a hash. That reduces what the record exposes; it does not by itself make the record anonymous.
A signature is not audit compliance
A record can be signed so a third party can verify it was not altered. That is not a general guarantee of audit compliance.
A rule is not a trained model
Rules are derived from recorded events. That is neither training a model nor a model of ordinary behaviour.
This is not a promise to be filled in at signature. What follows is what an event actually records, what it does not, how long it stays, who can reach it and where it runs.
- What an event records
The time, the type of event, the verdict and its score, an indirect fingerprint of the device and of the address, the browser, the behavioural signals, and the context of the request: the page address, the status of the answer, the mark of a challenge and, where there is one, the account name in an indirect form.
- What it does not record
The content of the communication. On a sign-in neither the password nor the e-mail address. The browser string is kept shortened. Input carrying a payment-card number in the open is refused at the edge, so such a number is never processed.
- How long it is kept
By contract and configuration; these are the defaults. An ordinary event thirty days. An event an operator has labelled, a year. The full address seven days, after which it is stripped from the event and only its indirect and shortened form remains. Quality measurements thirty days, records from protected devices ninety, Audit records are not deleted: the application can add to that log, not change it and not take a line out of it.
- Who can reach it
Data is separated per customer in the database itself. The event overview and the ordinary export are open to an administrator and a manager. The full address appears only in the detail of a single event under investigation. The evidence export that carries addresses, and the auditor's bundle, are for an administrator alone.
- Export
Events and threats as a table, a report as a PDF, a continuous feed into security monitoring with a resume point and without full addresses, an evidence export with addresses for a third party, and an anonymised record of one agent run. Every download is written into the audit.
- The signature over the records
Each audit record is chained by a fingerprint to the one before it and signed with a key belonging to your deployment. The private key never leaves the system and is not in the export. An operator runs the verification of the chain and also sees how many rows are unsigned. The tip of the chain is anchored at regular intervals with an independent time-stamping authority, so a third party can establish that a record existed at that time. That is not a guarantee of audit compliance.
- A snapshot for an investigation
An administrator can ask for a snapshot of the state of the protection over a chosen window. It is encrypted for a key you supply and carries its own fingerprint of the content. A regular automatic snapshot is switched on when it is asked for. Nothing removes a snapshot on a timer: the overview shows which of them a chosen period would cover, and until that is agreed none is deleted.
- Backups
A copy of the databases is made every night, and another before every update. Recent copies stay with the service; of the older ones a weekly and a monthly copy remain. One copy is also kept outside the location the service runs in — always within the EU — and is topped up every night, so losing that one location is not losing the data.
- Where it is processed
The service we run is in the EU. The other option is protection inside your own infrastructure, where the content does not leave your network; part of the checks can run on the device itself. Address reputation and a provider's models are calls that go out — what runs where belongs in the deployment proposal.
- What an event records
The time, the type of event, the verdict and its score, an indirect fingerprint of the device and of the address, the browser, the behavioural signals, and the context of the request: the page address, the status of the answer, the mark of a challenge and, where there is one, the account name in an indirect form.
- What it does not record
The content of the communication. On a sign-in neither the password nor the e-mail address. The browser string is kept shortened. Input carrying a payment-card number in the open is refused at the edge, so such a number is never processed.
- How long it is kept
By contract and configuration; these are the defaults. An ordinary event thirty days. An event an operator has labelled, a year. The full address seven days, after which it is stripped from the event and only its indirect and shortened form remains. Quality measurements thirty days, records from protected devices ninety, Audit records are not deleted: the application can add to that log, not change it and not take a line out of it.
- Who can reach it
Data is separated per customer in the database itself. The event overview and the ordinary export are open to an administrator and a manager. The full address appears only in the detail of a single event under investigation. The evidence export that carries addresses, and the auditor's bundle, are for an administrator alone.
- Export
Events and threats as a table, a report as a PDF, a continuous feed into security monitoring with a resume point and without full addresses, an evidence export with addresses for a third party, and an anonymised record of one agent run. Every download is written into the audit.
- The signature over the records
Each audit record is chained by a fingerprint to the one before it and signed with a key belonging to your deployment. The private key never leaves the system and is not in the export. An operator runs the verification of the chain and also sees how many rows are unsigned. The tip of the chain is anchored at regular intervals with an independent time-stamping authority, so a third party can establish that a record existed at that time. That is not a guarantee of audit compliance.
- A snapshot for an investigation
An administrator can ask for a snapshot of the state of the protection over a chosen window. It is encrypted for a key you supply and carries its own fingerprint of the content. A regular automatic snapshot is switched on when it is asked for. Nothing removes a snapshot on a timer: the overview shows which of them a chosen period would cover, and until that is agreed none is deleted.
- Backups
A copy of the databases is made every night, and another before every update. Recent copies stay with the service; of the older ones a weekly and a monthly copy remain. One copy is also kept outside the location the service runs in — always within the EU — and is topped up every night, so losing that one location is not losing the data.
- Where it is processed
The service we run is in the EU. The other option is protection inside your own infrastructure, where the content does not leave your network; part of the checks can run on the device itself. Address reputation and a provider's models are calls that go out — what runs where belongs in the deployment proposal.
The defaults above hold for the service we run; in a dedicated deployment, or in your own infrastructure, they move by contract and configuration. Every one of them was read from the deployed version of the protection on 18 October 2026 and changes together with it.
What we verify together
A proposed verification of the deployment, not a claim that these tests have already been run on your systems.
- An ordinary request
- An expected finding
- A wrong finding and its correction
- A client bypassed
- An unavailable check
- An exceeded limit
- Exporting an event