Factory Private
Security Remediation
Private AI security remediation with review gates
September 18, 2026 - 2 minute read
Private AI security remediation should reduce a verified risk without creating an unreviewable change. A growing list of suspected vulnerabilities can increase reviewer work while leaving the actual backlog untouched.
Start with a defined finding class, a responsible owner, and evidence of the affected behavior. Keep the intake narrow enough that reviewers can inspect both the claim and the fix.
Private AI security remediation starts with validation
Factory's security review workflow separates candidate generation from validation. It checks reachability, exploitability, existing controls, and false positives before reporting findings.
Apply that discipline before changing code. Trace the relevant input and trust boundary. Preserve the evidence explaining why an existing control fails or why a suspected issue is not actionable.
Use synthetic data in a disposable environment for any safe reproduction. Avoid live-system testing or real credentials. A finding should not require expanding the deployment's approved data boundary.
Constrain private AI security remediation
Provide a working copy, required tests, and scoped repository access. Keep standing production credentials outside the task environment.
Factory's Agent Safety & Controls includes command restrictions, sandboxing, hooks, and staged-diff secret scanning. Use the relevant controls without granting deployment authority merely because Droid can prepare a patch.
Review the inference route for the finding's source code and diagnostic context. In an airgapped environment, provide approved internal model endpoints and references. Do not assume that the workflow can consult current public advisories.
Keep the resulting change focused. The investigation may span many files, but each edited line should support the fix or its validation. Separate unrelated cleanup from the remediation.
Preserve context through review
Add a regression test for the unsafe behavior and a check that legitimate behavior still works. Record the commands and results. If a required test cannot run, identify the gap rather than claiming successful validation.
Context continuity matters when a reviewer needs to understand earlier decisions. In the Chainguard case study, Staff Engineer Josh Wolf described his experience:
When you don't have to think about context windows, you can treat Droid like a colleague that just remembers what you've been talking about.
That quote describes engineering context, not a private-deployment certification or a measured remediation result. Use the actual finding, diff, and tests as evidence that this fix works.
Have the reviewer recheck the changed data path. A passing test may miss another entry point or a bypass around the new control.
Measure accepted fixes and review effort
Factory's sovereign software development whitepaper identifies validated findings, accepted fixes, false positives, and review burden as measures for a security workstream.
Track those outcomes instead of counting generated patches. Separate agent execution time from delays in ownership assignment, validation infrastructure, or approval.
Preserve evidence in the systems authorized reviewers already use. Full interaction content may contain sensitive code or reproduction details, so collect it only when necessary and approved.
Expand after the initial workflow produces repeatable evidence and manageable review effort. Record who can close the finding and who approves the change.
The final record should explain why the finding was real, how the patch corrected it, which checks ran, and who accepted the result. That makes the work inspectable without relying on the agent's success message.
