Security as proof

Last updated: 2026-07-13

The moment a brain is writable from the outside (a synced notes folder, a marketplace pack, an agent) it becomes the target of memory-poisoning attacks. RepoOps answers that risk with code you can point at, and a standing red-team suite that attacks that code in CI on every change. Every claim below links to the exact shipped module that backs it. No claim ships here that does not resolve to code, the same truth-audit discipline behind our Verified Memory page.

Encrypted vault, not a plaintext .env

A known weakness in comparable tools is storing secrets in a plaintext .env file that any process on the machine can read. RepoOps does not. Connector credentials and app secrets are encrypted at rest with AES-256-GCM before they reach storage, and encryption fails closed when the key is unconfigured in production, so a misconfigured deploy never silently falls back to plaintext.

Every posture claim, linked to code

Each row states a claim and names the module that implements it. The module paths are the receipts.

The memory-poisoning red-team suite

A standing suite (lib/security/redteam/redteam.test.mjs) runs in our required CI checks job. It builds four adversarial fixtures the way a real poisoning campaign would shape them and asserts each defense fails closed: the poison is rejected, redacted, or held for an explicit human approval, and never becomes an active memory. A regression that opens any gate fails the build before it can merge.

What the suite does not test. Truth-audit discipline means naming the boundary, not just the coverage:

• The hosted website's TypeScript personal-write-trust guard (website/lib/personal-write-guard.ts) has its own test suite (personal-write-guard.test.ts + the me-brain integration suite); this Node suite covers the desktop/aggregator .mjs defenses.
• Network-level attacks (TLS, DoS, SSRF) and infrastructure hardening are out of scope; see the vulnerability-disclosure policy on /security.
• The cryptographic soundness of ed25519 itself (delegated to the audited noble-curves primitive), as opposed to our correct use of it.
• Social-engineering of the human approver at the HELD gate: the suite proves the gate exists and fails closed, not that a human always decides correctly.

Vulnerability disclosure

RepoOps is operated by PromptReports LLC, an Illinois limited liability company. We take the security of the desktop app and the hosted surfaces at repoops.ai seriously. The rest of this page describes how to report a vulnerability responsibly.

1. Reporting a vulnerability

If you believe you have found a security vulnerability in RepoOps, please email security@repoops.ai. Include enough detail for us to reproduce the issue: the affected surface, a description of the impact, and step-by-step reproduction instructions or a proof of concept. If you need to share sensitive details, ask us for a way to exchange them securely and we will arrange one.

Please report privately and give us a reasonable chance to fix the issue before any public disclosure. Do not open a public GitHub issue for a suspected vulnerability.

2. Our response commitments

• Acknowledgement of your report within 3 business days.
• Triage and severity assessment within 7 business days, with an initial view of whether we can reproduce the issue.
• Remediation timeline shared once triage is complete. We prioritize by severity and aim to resolve critical issues as quickly as we can.
• Coordinated disclosure. We will keep you updated on our progress and coordinate a disclosure timeline with you once a fix is available. With your permission, we are happy to credit you.

3. Scope

In scope for this policy:

• The hosted surfaces at repoops.ai and its sub-domains (marketing site, sign-in, billing, team management, hosted dashboard).
• The hosted API endpoints under repoops.ai.
• The RepoOps desktop app published as repoops-desktop, including its local server and Electron shell.

Out of scope:

• Findings that require a compromised device, physical access to a user machine, or a malicious browser extension already installed.
• Denial-of-service testing, automated volumetric scanning, and load testing against the hosted surfaces.
• Social engineering of RepoOps staff, contractors, or users, and physical attacks.
• Reports from automated scanners with no demonstrated, exploitable impact.
• Issues in third-party sub-processors (Stripe, hosting providers, and the Anthropic API), which should be reported to those vendors directly. Our sub-processor list is in the Data Processing Agreement.

4. Safe harbor

We will not pursue or support legal action against researchers who, in good faith, discover and report a vulnerability in accordance with this policy. To stay within safe harbor:

• Act in good faith to avoid privacy violations, data destruction, and any interruption or degradation of our services.
• Only interact with accounts you own or have explicit permission to test. Do not access, modify, or exfiltrate other users’ data.
• Stop testing and report immediately if you encounter user data, and do not retain, share, or use it beyond what is needed to document the finding.
• Give us a reasonable time to remediate before publicly disclosing.

If legal action is initiated by a third party against you for activity that complied with this policy, we will make it known that your actions were authorized. This policy does not authorize testing that violates applicable law.

5. What to expect from a good report

The most actionable reports include: the exact URL or surface, the type of issue (for example, injection, broken access control, or token handling), the impact if exploited, reproduction steps, and any supporting logs, screenshots, or a short proof-of-concept. Please do not include real third-party personal data in your report.

6. Our security posture

The desktop app runs entirely on your machine and does not transmit the content of your repos to RepoOps servers unless you explicitly bind the install to a hosted team. Brain Dreaming and Ask synth call the Anthropic API directly from your machine using your own API key (BYOK), so we never see your prompts or completions. For the hosted surfaces we apply encryption in transit (TLS 1.2+), encryption at rest (provider-managed), least-privilege access, audit logging, and vulnerability management. Full data-handling terms are in the Data Processing Agreement and the Privacy Policy.

A machine-readable version of our security contact is published at /.well-known/security.txt per RFC 9116.

See also: Terms of Service · Privacy Policy · Data Processing Agreement.