Scope
Targets, identities, repositories and rules begin in one bounded workspace.
JULS brings scope, browser evidence, source context and specialist agents into one controlled workflow—then turns the work into clear, reviewable findings.
Review authentication boundaries. Use the approved scope and verified test identities.
Planning is complete. You decide what runs next.
JULS keeps every stage connected, so evidence, decisions and output remain traceable from first scope to final report.
Targets, identities, repositories and rules begin in one bounded workspace.
Capture the authorized HTTP surface through an isolated browser session.
Specialist agents map evidence and source context into targeted test cases.
Run focused checks, retain evidence and keep the tester in control.
Turn reviewed findings into an immutable, client-ready security report.
JULS is built to make progress and coverage clear. Do not trust AI models alone, inspect the work, edit the tests, run them and review the findings before publishing a report.
Awaiting review.
Check whether a cross-site navigation can create a snippet in user123’s session. Source context points to a state-changing GET without a CSRF check; runtime verification is still required.
⌁ Requests 1/newsnippet2The creation handler adds the supplied snippet to the logged-in user’s list without a CSRF-token or method check.
The form uses GET and provides no anti-CSRF value.
<form method="GET" action="/newsnippet2">
<input name="snippet" />
</form>
Awaiting review. No test has run.
Verify the login flow and protected session using the second approved identity.
/login/snippets.gtlAwaiting review. No test has run.
Check that protected content is no longer accessible with the same session after logout.
/logout/snippets.gtlAwaiting review. No test has run.
Request protected snippets without an authenticated session and inspect the access boundary.
/snippets.gtlAwaiting review. No test has run.
Verify that an anonymous request cannot access or modify the profile form.
/editprofile.gtlAuthenticated application security review.
An authenticated user can access a finding from another workspace by supplying its identifier directly.
The finding endpoint returned data outside the caller’s assigned workspace. The server accepted the record identifier without validating tenant ownership against the active session.
GET /api/v1/findings/finding_b
Host: portal.example.test
Cookie: session=workspace_a_user{
"id": "finding_b",
"workspace": "workspace_b",
"severity": "critical"
}Complete all required sections and review the PDF before publishing.
Refine the plan in chat. Inspect each draft’s objective, identity and linked requests, then approve or reject it before execution.
Capture traffic from your local browser, bring in committed source and keep everything connected to your assessment.
juls browser start --assessment ASSESSMENT_ID01Connecting to your JULS assessment
02Local Chromium connected
03Captured traffic sent to the assessment
✓Discovery is visible in JULS
Browse from your own network. Captured traffic stays attached to the assessment.
Traffic from your browser, ready for the planner.
Examples show the connection flow. Commands use your assessment ID.
Private targets.Local browser.Shared context.
Automation should make expert work clearer—not opaque. JULS keeps authorization, evidence and decisions visible at every step.
Discuss your workflow ↗Authorized targets, identities and workspace rules travel with each run.
Credentials stay vaulted and production files remain in private object storage.
Testers approve findings and publish immutable versions for clients.
Agents run in isolated sandboxes with access only to approved targets; everything else is blocked at the network layer.
The best security work is
See how JULS turns real scope and evidence into a reviewable security workflow.