Scanning production safely

Pointing a security scanner at production sounds like a way to get woken up at 3am. People expect Violet to behave like an old-school vulnerability scanner — the kind that floods your app with brute-force payloads and takes the database with it. Violet is built differently, and a production scan is a normal thing to do. This guide explains why, and how to set it up.

The fear vs the reality

The fear is real and worth addressing first. Teams who have used traditional scanners carry scar tissue. They remember tools that sent thousands of requests per second and tripped every WAF circuit breaker in the process. Tools that created phantom user accounts that lingered in the database for weeks. Tools that brute-forced login endpoints until the whole auth system fell over. Tools that, in one memorable case, triggered a cascade of webhook retries from a third-party service that woke up the on-call rotation at 2am on a Saturday.

Violet does not do those things. Violet runs as a small number of AI agents that pace themselves. Each agent has a defined scope — it does not try every payload it knows against every endpoint it finds. Violet's exploitation policy is non-destructive by design, not by convention or by hoping the operator remembered to flip a flag.

The actual risk profile of a Violet scan against production is closer to that of a thoughtful manual pentester than an automated scanner. The mitigations in this guide reduce that risk to near-zero.

Default rate behavior

Violet paces requests politely. Agents do not flood endpoints. The scan is not racing to complete — it is reasoning about what it finds and deciding what to probe next.

Violet respects HTTP 429. When it hits a rate limit, it backs off and waits. It does not retry immediately or route around the limit by opening parallel connections.

Violet slows down on error spikes. If an endpoint starts returning 5xx responses, the agent treats that as a signal that something is stressed and stops escalating pressure. It does not interpret a 500 as "interesting, try harder."

Violet never opens parallel connection storms.

Focus and avoid rules

The scope config is how you tell Violet what is in scope and what is not. Two parts:

• Focus paths — explicit paths to test (e.g., /app/*, /api/*)
• Avoid paths — explicit paths NOT to test (e.g., /admin/*, /payments/*, /webhooks/*)

scope:
  focus:
    - "/app/*"
    - "/api/*"
  avoid:
    - "/admin/dangerous-action"
    - "/api/v1/webhooks/*"
    - "/billing/charge"

Be liberal with avoid. Anything you do not want Violet to interact with — even read — belongs in avoid. Violet treats the avoid list as binding.

If you cannot decide whether a path belongs in avoid, put it in avoid. You can always remove it from the next scan.

Paths to exclude

This is the list every team should set on day one, before the first scan runs.

• Auth callback URLs (e.g., /auth/callback, /oauth/callback) — probing these churn OAuth state with third-party identity providers. Test them manually after the scan instead.
• Webhook endpoints (e.g., /webhooks/*, /api/v*/webhooks/*) — third-party services have their own retry logic. Probing an inbound webhook often kicks off a cascade of retries from the sender's side, which Violet cannot control.
• Payment routes (e.g., /billing/charge, /api/payments/*) — even sandbox transactions show up in dashboards and accounting logs. Test payment flows with a separate test plan outside the scan.
• Destructive admin endpoints (e.g., /admin/users/delete-all, /admin/db/truncate) — Violet's non-destructive policy covers this already, but defense-in-depth means you don't rely on a single safeguard.
• CI and deploy webhooks (e.g., /deploy/trigger, /ci/build) — accidentally triggering a build from a scan request is embarrassing. Add these before you find out the hard way.
• Bulk communication endpoints (e.g., /admin/send-broadcast) — Violet finding a vulnerability in an email blast endpoint is useful; Violet triggering the endpoint to prove the point is not.

Auth for production

Create a dedicated test account. Never give Violet credentials for the real admin or for a real customer account.

Make the purpose of the test account obvious from its name: [email protected] is unambiguous in logs, in user lists, and in any audit trail. If someone sees it and wonders what it is, the name answers the question.

Give the test account permissions equivalent to a normal user — not admin, unless you specifically want admin-only paths covered. Less access means less blast radius if anything goes wrong. Keep the scope of the test account matched to the scope of the scan.

Rotate the test account's password before and after the scan. The password is in the scan config, which means it sits in logs. Rotating after the scan closes the window.

If the test account creates any data during the scan — posts, comments, profile updates — clean it up after. The report lists what Violet created; use that list as your cleanup checklist.

If you find yourself worrying about whether the test account "has enough access," you have given it too much. Less access means less blast radius if something goes wrong.

The non-destructive policy

Violet refuses to modify, overwrite, or delete existing data. No UPDATE, DELETE, DROP, or TRUNCATE on production tables. This is not a setting you toggle — it is wired into the agent prompts.

Violet never sends bulk or mass requests. No denial-of-service payloads, no resource exhaustion, no crash-inducing input sequences against production systems.

Data extraction stops at minimum proof: one or two rows, not full tables. If Violet can prove SQL injection by returning one email address, it stops there.

Command injection is proven with read-only commands (id, whoami). Files may be written to /tmp as part of a proof — never modified or deleted outside /tmp.

Auth bypass demonstrates access to one unauthorized resource, not bulk enumeration. Proving that user 1002 can read user 1001's profile is enough. Dumping all user profiles is not.

Be honest about what Violet may do as part of proof. Violet can register new user accounts to prove a mass-assignment flaw. It can INSERT into non-critical tables to prove SQL write access. It can upload new files to prove a file-upload vulnerability. These artifacts get listed in the report so you can clean them up after.

Pre-flight checklist

Run through this before every production scan, in order.

1. Tell your on-call channel. One Slack message: "Violet scan starting at HH:MM, expected duration 60–90 minutes, contact me if anything looks weird." Everyone who might see anomalous traffic needs a heads-up before the scan starts, not after.
2. Confirm the scope config. Open the scan settings, scroll the avoid list, make sure nothing critical is missing. This takes 60 seconds and catches the mistake you will make eventually.
3. Confirm the test account. Log in as the test account manually. Confirm it has the right permissions, the credentials are current, and nothing is blocking it (MFA prompts, forced password reset, suspended account).
4. Note the start time. Two reasons: post-scan log filtering, and an explanation for any anomalies that surface during the window. A timestamp you wrote down is better than one you have to reconstruct.
5. Watch the first 5 minutes of the live progress page. If something is going to go obviously wrong, it will show up in the first phase. Stay present until the pre-recon phase completes, then step away.

Mid-scan abort

The Stop button on the scan page is real. It cancels the current agents and exits cleanly. Use it if something looks wrong and you want to investigate before the scan continues.

A scan you abort mid-flight does not consume your credit in trial, and does not charge you again on paid plans.

If something is on fire and you cannot reach the dashboard: Violet runs from external IPs. Blocking those IPs at your edge — in your WAF, your CDN, or your firewall rules — is the kill switch of last resort. It is blunt, but it works.

If you are worried about needing this, that is a sign your scope config is too aggressive. Tighten the avoid list and try again.

Post-scan verification

Three checks. Do all three before you close the tab.

1. Error rates returned to baseline. Open whatever dashboard you watch normally. The metrics for the last 90 minutes should look like the 90 minutes before the scan started. If they do not, you have something to investigate before moving on.
2. The test account is in the state you expect. Log in as the test account. Confirm any data Violet created during the scan — posts, comments, profile updates — is what the report documents. Delete anything you do not want to keep.
3. No mystery accounts. If the report lists newly-created accounts (created as proof of mass-assignment or privilege escalation vulnerabilities), confirm they exist in your user list, then delete them. Do not leave pentest artifacts in production.

After 30 days of running scans, this checklist becomes muscle memory. After 90 days, you stop worrying about the scan at all.

Production scans aren't dangerous. Reckless production scans are. Set the scope, set the test account, tell your on-call, run the scan.