Enji GuardWhat it runs
Auto-pentest is part of Guard's improvement loop. The run takes one verified surface and tries to move it forward after audit or product evidence makes the next step clear.
That does not give Guard open-ended permission to rewrite the repository. The run keeps the work small, records why this candidate was chosen, and produces output a person can review before anything lands.
This improvement is not owned by one audit score. It starts from verified product context and the current repository or linked website state.
Starting evidence
Verified website target, repository access, consent state, current GitHub issue and pull-request history, and tool readiness checks.
Earlier Guard context helps only when it still matches the target. The run revalidates access, looks for duplicate GitHub work, and treats stale or missing evidence as a reason to stop rather than a reason to guess.
Allowed change
Auto-pentest is tied to one verified linked website and the selected mode: one issue per finding or one fix pull request per finding.
- One GitHub issue per confirmed finding in issue mode.
- One reviewable fix pull request per finding in pull-request mode.
- A report-only outcome when consent, target, or repository access is missing.
One focused run keeps the change small enough to review.
Probe verified linked websites under explicit authorization, then report confirmed findings or open reviewable GitHub work.
Boundaries
Guard improvements stay useful because they are constrained. A run stops or falls back to a report when repository access, target scope, source context, or the write path is not clear enough.
- It does not test arbitrary hosts or infer permission from old artifacts.
- It does not merge fixes.
- It does not replace manual penetration testing for high-risk systems.
Candidate selection
Guard tests only the authorized target, deduplicates against previous security history, and avoids repeating findings or fix patterns that maintainers already rejected.
- 1
Resolve the target
Read the repository identity, selected improvement, and any linked website or paired audit context.
- 2
Validate current state
Check repository access and current files before relying on earlier Guard evidence.
- 3
Deduplicate existing work
Read relevant GitHub issues and pull requests so Guard does not repeat stale findings or rejected fix patterns.
- 4
Pick the smallest useful candidate
Prefer one improvement that can be explained, reviewed, and verified.
- 5
Record the stopping reason
If the run cannot safely write, the report explains whether the outcome is report-only, issue-only, or blocked by missing evidence.
Outputs
The report names the authorized target, tested scope, issue or pull-request links, and any limitation that prevented active probing or code changes. Output choice depends on the runbook and product mode. The report remains the durable record even when the visible result is a GitHub issue or pull request.
| Output | When it fits |
|---|---|
| Report | The run inspected the target and needs to record the outcome, limitation, or verification. |
| Issue | The evidence is real but the fix needs product, security, or architecture judgment. |
| Pull request | The candidate is narrow, reviewable, and has a credible verification path. |
Reflected parameter reaches an unauthenticated search endpoint
Finding reported against the verified staging URL
Product surface
Guard exposes improvements from the audit or repository surface, not a separate code-writing workspace. The same action can appear in the control panel, recent activity, and report history after a completed run.
Review and rerun
Auto-pentest adds runtime evidence to the improvement loop. A later security audit or pentest rerun confirms whether the exposed behavior is gone.
This is the same health model as the audit pages: Guard improves a concrete surface, a person reviews the output, and a later audit or improvement rerun evaluates the new revision. The maintained state is the green zone, not an untouched backlog of findings.