This document outlines security procedures and general policies for the Visa Vulnerability Agentic Harness (vvaharness) project.

• Reporting a Vulnerability
• Disclosure Policy
• Security considerations

Thank you for improving the security of our software. We appreciate your efforts and responsible disclosure and will make every effort to acknowledge your report.

Please report security vulnerabilities by emailing the security team at:

• vvaharness@visa.com

For coordinated disclosure and additional reporting channels, see:

• Visa Vulnerability Disclosure Program: https://usa.visa.com/about-visa/vulnerability-disclosure.html

Please do not report security vulnerabilities through public GitHub issues.

The security team will acknowledge your email and follow up with next steps in handling your report. We will keep you informed of progress toward a fix and full announcement, and may ask for additional information or guidance.

When reporting, please include as much of the following as you can to help us triage quickly:

• The version (or commit) of vvaharness affected.
• The profile/backend in use (via: cli, via: sdk, via: openai, or via: deepagents plus its provider) and OS.
• A description of the issue and its security impact.
• Step-by-step instructions to reproduce.
• Proof-of-concept or exploit code, if available.
• Any known mitigations or workarounds.

Report security vulnerabilities in third-party dependencies to the party that maintains the affected component.

When the security team receives a vulnerability report, it is assigned to a primary handler. This person coordinates the fix and release process, involving the following steps:

• Confirm the problem and determine the affected versions.
• Audit code to find any potential similar problems.
• Prepare fixes for all releases still under maintenance. These fixes are released as quickly as possible.

Public disclosure is coordinated with the reporter; please give us reasonable time to remediate before any public discussion of the issue.

TL;DR: vvaharness reads repository content and forwards excerpts to the configured model endpoint. SDK/OpenAI tool results and read-only DeepAgents tool results are scrubbed, but redaction is not a universal pre-egress guarantee for every prompt or backend. On-disk reports are redacted on every backend. Keep scan credentials and config outside the repositories you scan, restrict tool access in CI/CD, and scope batch jobs to repositories your team is authorized to scan.

File reads through the sandboxed tool loop and the s1 inventory are confined to the repository root — symlinks and path traversals that point outside it are rejected. Redaction — masking of credentials, private keys, and payment card data — is applied at the report write boundary (Markdown and SARIF, on every backend). Sandboxed via: sdk / via: openai tool results are scrubbed before returning to the model, as are filesystem reads in read-only DeepAgents sessions such as validation. DeepAgents fix-mode remediation permits writes and does not promise that same read-result redaction. The default via: cli detection route drives the claude CLI's own filesystem tools, so quoted source on that path is masked only at the report boundary, not before it reaches the model. API keys and git tokens are kept in environment variables and sent as request credentials; they should not appear in prompts. For full detail see docs/security.md.

Batch mode clones each repository into an isolated workspace directory and scans it. Unless you pass --keep-clones, the clone is removed when the scan completes, preserving only folders listed in output.preserve_on_cleanup. All shipped profiles currently preserve both security-scan and security-remediation. See docs/security.md for details.

For a full description of redaction patterns, backend TLS settings, and credential handling, see docs/security.md.

• Only scan repositories you trust. The scanned repository is an input to the pipeline; treat it with the same caution as any other untrusted input to a privileged process.
• Keep scan infrastructure separate from scan targets. Store config and credentials in directories outside the repositories you scan. Run scans from a working directory that is not inside the target repository.
• Restrict tool access in CI/CD. Review and restrict tool access, and ensure sandboxing to reduce risk.
• Keep batch manifests under security-team control and restrict the git host to your internal domain.

As with any analysis tool, vvaharness processes repository content as part of its normal operation. Findings and artifacts are produced for human review. With remediation enabled, a plain default-profile scan can also edit target source when S10 has findings, credentials, and a successful fix-mode session; use --stop-after s9 for detection-only operation. Apply the same judgement to SARIF and generated patches that you would to any automated tool result.

• Repositories your team is not authorized to scan.
• Repositories whose committers you do not fully trust.
• Large monorepos without first scoping the scan using vvaharness estimate, --stop-after, or --auto-step1.
• Directories containing only binaries, generated code, or vendored dependencies — exclude these via exclude_dirs in your config to keep results focused.