Search is unavailable right now. Try again in a moment.
Reading a real person’s records is one of the three actions that stop and wait for your written approval. That is a property of how the platform runs, not a policy written about it. An engagement proves the path and stops there, so in the ordinary case there is nothing of your customers’ for it to hold.
What it holds
An assessment cannot be evidence-bearing and hold nothing. What it holds is the material a finding is made of, which is a description of how your systems behave and not a copy of what is inside them.
| What an engagement holds | Why, and for how long |
|---|---|
| The scope you authorised | Targets, classes, roles, and for the classes that need one the movement boundary. It is the document the engagement is measured against, and it is retained with the engagement record. |
| The evidence for each finding | The request as sent and the response as returned, with the part that proves the defect marked. A finding without it is an assertion, which is why this is the one thing an engagement necessarily keeps. |
| What the targets disclosed | Versions, configuration, routes and the other material discovery returns. It is what the report is written from. |
| Source code, where a review is in scope | Held while the engagement is active and deleted after thirty days of inactivity. Where the review runs inside your own pipeline the source never leaves it at all. |
| Credentials you issued for testing | The accounts you created for the engagement, for the roles whose boundaries are being tested. Yours to revoke at the end, and worth revoking. |
The scope you authorised
The evidence for each finding
What the targets disclosed
Source code, where a review is in scope
Credentials you issued for testing
The gate that does the work
An authorisation defect is proved by reaching one record that belongs to somebody else. Enumerating the rest of them proves nothing further and changes what the engagement is holding, so it is a separate act behind a separate written approval. The same line runs through every class: a cloud finding is a permission proved by making one call, not by decrypting a production dataset; an API finding is a pair of requests, not an export.
Where you do authorise the next step (because the finding genuinely needs it, or because your own investigation does), the report says which findings went that far. That is worth more to a reviewer than a blanket assurance, because it is checkable.
What reaches a model
Before anything is sent to a third-party model, it passes through B-52’s anonymisation and tokenisation layer. The details that identify you are swapped for randomised values, the model analyses what is left, and B-52 puts your context back before the result reaches you.
The layer sits in front of every third-party model provider we engage, and it is a contractual duty at §3.10(a) of the data processing agreement. Where your policy rules out shared model infrastructure altogether, the next section is the one to read.
Where the models run
Standard hosting is where most engagements start. The other three are for estates whose security, regulatory or residency position rules out shared model infrastructure, and all four run the same B-52 platform and the same orchestration.
| Hosting option | Where inference runs | Who receives your material | Who it suits |
|---|---|---|---|
| Standard | Leading third-party models behind the anonymisation layer, with our own models for anything that needs identifiable material. | The supported providers, after tokenisation. They do not train on it. | Most estates. It is the most cost-effective option, and it runs on frontier models. |
| Dedicated hardware | Compute that Security Brigade owns and operates, allocated to you alone. | No third-party model provider. | Organisations that want isolation from shared inference without running hardware themselves. |
| Inside your environment | Supported models hosted entirely inside your own infrastructure. | No third-party model provider. Inference stays inside your security boundary. | Environments where information cannot leave your infrastructure. |
| Your own model | Your enterprise model, through your own provider agreement or hosted privately. | Your provider, under your terms. | Organisations that have already standardised on an enterprise model. It has to meet the capability bar for autonomous security testing and be in, or validated against, the supported model set. |
Standard
Dedicated hardware
Inside your environment
Your own model
What changes between them is the balance between isolation, model capability, infrastructure complexity and cost. Standard hosting gives you leading frontier models with the anonymisation layer in front of them. The other three let B-52 run without shared public model infrastructure at all.
The option is settled at scoping, priced in the written scope, and written into your agreement at §3.12 of the DPA.
Where it sits
You choose the region: India, the European Union, the United States, or Singapore and Asia-Pacific. For an entity inside the scope of CERT-In Directions No. 20(3)/2022-CERT-In (issued 28 April 2022, effective 27 June 2022, and requiring 180 days of rolling ICT logs within Indian jurisdiction), that choice is a compliance decision, not a preference.
External and application testing need nothing deployed inside your network at all. Internal network testing needs a position inside it, on your own infrastructure or in your own cloud tenancy. Deployment and residency sets out all three shapes and what is agreed before each.
It is the sensible order, and the answers are the same either way. Where something here does not cover what your security team needs to know, ask: a gap is better named than guessed at.