Source code, servers and whatever is exposed on the internet. A pentest probes from the outside and samples — we read the entire contracted scope and, for every finding, show the file, the line and the chain walked from input to effect. The audit runs inside your environment: the code never leaves it.
Content suppressed. Either the lines exist and check out, or they do not — a trail cannot be faked.
01 · What defines the service
Before any other question, every client asks this one: where does my code go, and what can this agent do inside my machine? It is the right question, and we would ask it too. It is not answered with a promise — it is answered by how the service is built, and by what you can check yourself, without relying on our word.
The audit is carried out by a command-line tool you install yourself (details in section 09), inside your own infrastructure — on your machine or your server. The code is not copied out of it, and never passes through a server of ours.
The audit writes in one place only: its own folder, holding the plan, the partials and the final reports (Markdown and HTML). Outside it, every file of your software and environment stays exactly as it was — nothing is modified, moved, deleted or "improved", not even by accident. A probe verifies the lock before the audit starts; at the end, the sha256 of every file is compared with the one taken at the start, and the result goes in the report — the checking is yours.
It is a document your team opens next to the code and checks item by item — not a dashboard with a number, and not a badge. The flaw is pointed at, not fired: the path is written down, and confirming it on the running system stays with your team, who are the ones who can do it safely.
02 · Confidentiality by construction
What reaches SVO during the run is the progress — which step finished. Never the content, the data or the findings.
So who reads your code? The AI model that runs the audit — and that processing belongs to Anthropic, on your account and under their data policy: the same one that already applies when your team uses the tool to write code. Through SVO servers your code never passes.
On our side: the audit runs inside your environment, the report is born and stays there, and what reaches us is a step label. And read-only is not asked of the agent: it is enforced by mechanism. Before starting, the audit runs two probes that test its own locks — if either is not in force, it stops and tells you, instead of running unprotected. At the end, the sha256 of every file is compared with the one taken at the start, and the result goes in the report: that is how you check that nothing was touched — by arithmetic, not by promise.
Distrust of AI agents is reasonable, and we are not going to ask you to set it aside. The traffic leaving your machine is yours — and you can watch it, with a tool that is also yours, installing nothing of ours — and there is an equivalent on both systems:
macOS: LuLu (free) or Little Snitch — an application firewall: it prompts on each outbound connection, naming the program and the destination.
Windows: GlassWire does the same; the Windows Firewall logs outbound traffic out of the box; and TCPView (free, from Microsoft itself) shows every live connection and its owning process, with nothing third-party installed. To see request by request: Wireshark or Fiddler, on either system.
Turn it on before you start and leave it running.
You will see two destinations, and you should know that before turning it on. The large volume goes to Anthropic: your code being read by the model, on your account — the same traffic that already exists when your team uses the tool to write code. To SVO go short, sparse messages: a step label and a few dozen bytes each — a step label and a session identifier. The size alone answers the question: code does not fit in 100 bytes. And if you want to read the content, not just the size, Fiddler opens the encrypted traffic with its own certificate and shows every message in full.
⚠️ A monitor shows where traffic goes and how much — it does not read the content, which is encrypted — Fiddler is the one for that. And here the size alone is enough: what goes to SVO is dozens of bytes, and what goes to Anthropic is the volume of your code, going where it already goes when your team uses the tool.
That is the difference the monitor makes visible: your code is read by the party that has to read it in order to audit it, under the contract you already have — and no content goes to SVO. Not because we promised: because you checked.
03 · On your side
04 · The models
The size of the system sets the price band. What sets the model is what enters the scope and what access exists. One audit never covers both at once: auditing the software and auditing the machine are different services — Code looks at what your system does; Host and MultiHost look at where it runs. If you want both, you buy both, and the proposal says what each one adds.
Complete static reading of the contracted scope: logic, security, data handling, dependencies, configuration. The most common entry point.
The same code, on your server, with nothing downloaded. It sees what a copy hides: the real permissions on config files, the stale folder still being served, the forgotten database dump on disk, and the gap between what is deployed and what is in version control. Requirement: Claude Code must run inside your server — we ask that during the quote. If it is not possible, the product is Code, and we say so beforehand, not afterwards.
We audit your slice — its services and processes, the web server routing, the database, configuration and permissions — whether containerised or installed straight onto the system, without touching the neighbours. Limit stated in the report: your slice inherits the host's risk, and this audit does not assess it.
System, firewall, remote access, updates, users, every running service — containerised or native — and every domain served. It applies to container hosts and to traditional Linux alike: the model is defined by breadth, not by technology.
For those on shared hosting with no shell. Observation only: headers, TLS, what is publicly exposed. Zero exploitation — we do not break in, take anything down, or brute-force. To prove the site is yours, you publish a file with a name we give you and we read it over HTTPS — just like Google's domain verification.
05 · The two levels
At both levels, every finding faces a step that tries to take it apart before it enters the report — and whatever falls is listed. What changes is who does that work.
A complete linear reading of the contracted scope — a full audit, not a sample. One agent searches, locates and then itself confronts each finding with the code to judge whether it holds.
Several agents search in parallel, each through its own lens, and locate the findings. Other agents judge — they took no part in the discovery and receive each finding with the job of knocking it down. Only what survives someone with no attachment to it stays.
When Deep is not worth it. On a small, homogeneous system with no internal boundaries, Deep adds little. In that case we recommend ONE — saying so is part of the service. It pays off where there are boundaries: client and server, code and database, one platform and another, new system living alongside legacy. The seams are where a linear reading falls short.
Share has ONE only: with no server access there is no depth left to add.
06 · What you get
That is what makes the report checkable by your team without depending on us.
In a code audit, every finding is [ANALYSED] — nothing is executed, by design. The label exists so you never mistake what was read for what was measured, and so we can state plainly what only you can confirm in your own environment.
The report also carries the scope — within it, what was covered and what went unverified, with the reason —, the list of findings discarded in verification, and the cross-cutting counts, which group dozens of findings into a handful of root causes.
What we knocked down ourselves is in the report too, with the reason it fell. Publishing what did not become a finding may look counter-intuitive — and that is exactly where the value is: the refutation was made with the code in hand, and it may not hold in your environment. If the premise that killed a finding does not apply to your deployment, your team sees it in writing and decides. A hidden false negative is the one audit error nobody ever finds out about.
The report is written by a language model running our method on your machine. Every piece of evidence and every trail must be walked and verified by your development team — or your infrastructure team, on the Host and MultiHost models — before any fix reaches production. This is not boilerplate: it is what the fields above are for, and whoever verifies is whoever fixes.
Was a sentence in the report unclear? Write to us naming the sentence — we explain what the method meant, because that text is ours. What we cannot answer is whether the finding holds in your system: we have never seen it, which is exactly why the report hands you the trail instead of a verdict. Do not send us the report or excerpts of it — we could not assess them, and it should not leave your environment. Naming the sentence is enough.
07 · The two formats
The report is delivered in both, always, written to your machine.
Self-contained, with no external dependency. Print it, turn it into a PDF, send it to your board or to your own client.
Versionable alongside the code and as machine-readable as it is human-readable. If your team uses AI to help write code, the Markdown report is handed straight to it: ask for an analysis of the findings and an implementation plan, prioritised to fit your roadmap.
It works because every finding carries file and line, the path to the effect, the consequence and an objective test for "fixed" — exactly what an AI needs in order to plan, instead of you turning a PDF into tickets by hand.
The loop closes without going through SVO — and we still never touch your code. Treat the report as confidential material: it quotes snippets of your code as evidence.
08 · Access and passwords
The audit runs inside your own server, in a session you opened, with your own access. Password, key or credential: nobody here asks for one — not us, not our material, not the scope form.
An SSH key, for instance: no password is ever asked for.
It is your own terminal that asks, on each access. It is never written to any file of ours, never stored, and never reaches us.
When the audit needs to know which user the application connects to the database with, we ask — instead of telling you to open the config file. We check the location and permissions of those files without reading the values inside them. Asking beats reading a secret.
If any step of our material asks for your password, your IP or a dump of your database: refuse. That is our mistake, and we want to hear about it.
09 · Where the audit runs
Execution uses Claude Code, Anthropic's command-line tool — in the terminal of your machine or server, inside VS Code, inside JetBrains editors, or in any editor with an integrated terminal.
A paid Claude account. Claude Code does not work on a free account — and there are two routes: a subscription (fixed monthly fee) or prepaid credits on the Anthropic Console, pay-as-you-go: no monthly fee, paying per token consumed. For a one-off audit that is usually the one that fits. Set a spending limit on the dashboard before you start — with headroom, so the audit does not stop halfway. If you do not have an account yet, we walk you through it. We have no access to your account, we hand over no credentials, and we cannot see your usage: you can, on your own dashboard. How to install and pay with credits →
What you buy from SVO is the method: what to look at, in what order, what to demand as evidence, what to discard and how to declare scope. We tell you the order of magnitude of the consumption before starting, and advise running with headroom so the audit does not stop halfway.
10 · Limits
We read the system and show the path to the flaw; a pentest does the opposite, and simulates the attack. Here nothing is exploited, brought down or brute-forced.
We point to the fix and to who should make it. Changing the system of the party you are auditing is the opposite of auditing.
We promise the method and the trail — always delivered — and we declare, in the report itself, where we did not look.
The document is for your team to work from — a forensic report or a certification is another thing, and it is worth knowing that before hiring.
The price is the same with 3 findings or with 300: paying by quantity would be the incentive to inflate the list.
11 · Second Round
Any system that stays alive keeps changing: a fix lands, a patch is applied, a dependency moves up a version, a new feature ships. Each one solves what it came to solve — and each one touches code that was already standing. That is why there are security advisories whose title begins with incomplete fix for: the previous fix closed one door and left the one next to it open.
The report stays yours forever; the security state does not.
Second Round is a second complete audit of the same project, at whatever stage it is in when you run it — not a re-check of what changed. Discounted off the table, at the level you choose.
An audit shows the state of one day. Teams that treat security as routine look again after the system has moved — and that is what Second Round is for, at a discount and without starting over: same method, and the target is the system as it stands now.
Purchase within 30 days of the first · run within 90 days of the first run · same band · does not stack with other offers.
12 · Investment
The figure comes from three variables, none of them subjective. Quote on request, closed before anything is installed.
What enters the scope: code on your machine, code on your server, one application, your whole server, or the external view.
ONE or Deep. When Deep adds nothing, we recommend ONE.
For code, lines of your own code — with the discarded folders in plain sight: third-party libraries, generated code, data files and identical copies. For servers and websites, the services audited and the domains verified.
It takes a few minutes, runs on your machine, and the result is what becomes the quote.
Free trial: the Sample Audit. On the Code model only — you download it and run it yourself, on your own machine. It looks for the most severe critical problems and stops at the first ones it finds: it is not the full audit, and its job is to show you the method and the shape of a finding before you hire anything. See the step by step. The other models have no sample, for a simple reason: they need access to your server, and access is not something you grant for free to someone you have not hired yet. Free is our part: the AI credit is still yours (section 09) — and being a sample, it comes cheap.
The size is measured by you. For Code and Code Online, with a utility we provide and whose code you can read — and which we also run, over the same scope, to check. For Host, MultiHost and Share, the number is declared by you: at this stage we have no access to your environment at all, and that is what makes a quote possible without you handing over anything first.
You get back which model and level fit, what is in and what is out, and the order of magnitude of the investment — before installing anything.
Want a price? → Quote. Already have your quote number and want to close it? → Order. The form below is to talk about scope.
🔴 Auditing code? Before talking scope, measure your project: you download a read-only script, run it on your own machine and it writes a manifesto.json with the size. The script makes no network connection — you are the one who sends the file. Then request the quote on the Quote page, so the price is based on the real number. Step by step: how to measure your system.
The attachment goes straight into the e-mail and is never written to any disk. Send the measurement output — never your code.
Want to bring the number already? Measure your system first — it takes a few minutes. How to measure your system
Prefer plain e-mail? contato@svo.com.br
The report is yours and we do not publish it. Each client is isolated: nothing from one appears in another's report, folder or conversation. Secrets we happen to find — passwords, keys, tokens — are reported as an exposure, with the value masked, never copied in the clear. Testimonials or case studies only with written permission.