Application context

Everything on this step is optional. You can skip it entirely and the agent will still do a solid job. But filling it out is one of the most valuable things…

Everything on this step is optional. You can skip it entirely and the agent will still do a solid job. But filling it out is one of the most valuable things you can do here, because the agent reads every word before it starts and uses it to prioritize. Five minutes on this step saves hours of wasted runs later.

What you can share

1. Application context

   A short description of what the app does and who uses it. Something like ‘B2B SaaS for invoice processing, tenants are SMB finance teams, the main workflow is uploading CSVs and reconciling them against an accounting ledger.’ The agent uses this to figure out which endpoints matter, what a normal user does, and which kinds of flaws would actually hurt your customers. Not required, but if you give the agent real context it becomes noticeably smarter about what to look for. The more it knows about your app, the more useful the scan.

2. Tech stack

   The frameworks, languages, databases, and major libraries your app is built on. Also optional. When you include it, the agent knows which class of vulnerabilities to look at first. A Rails app gets probed differently from a Next.js app, and both get probed differently from a Django API. The agent figures a lot of this out from responses, but telling it up front makes the first hour of a scan much more productive.

3. Security focus area

   Where you want the agent to spend extra effort. Maybe you just shipped a new file upload feature and you want it beaten up. Maybe access control has been your historical weak point. Maybe you’re worried about a specific role boundary. Whatever it is, spelling it out tells the agent to go deep on that part of the app, even if other areas would normally get more attention.