Three sentences for a security review
- We query your production data; we don’t load it into our database. What learning your system reads from production is deleted within eight days of the run, and the Runbook keeps none of it.
- We never push to your branches. Only a feature branch and a PR you review.
- Every job runs in a virtual machine destroyed when it finishes.
- The records a ticket cites travel with that ticket, so the fix can be tested against them.
Each credential, its scope and its worst case
- Production database. Read-only by its grants, with the grant statement generated for your engine and measured at connect. Worst case: data read, limited by the egress allowlist.
- Staging database. Read-write, disposable. Worst case: staging data destroyed.
- Logs. Read-only and log-scoped. Worst case: log contents read.
- Third-party services. Test mode only; a live key that can move money or send messages is refused. Worst case: test-mode objects created.
- Package registry. Pull only. Worst case: your private packages read.
- Git push. Never in an agent. The orchestrator alone pushes, with a one-hour installation token, and only to a feature branch; your branch protection keeps it off yours.
Isolation
- A microVM per task, never reused across customers or tickets.
- Your own VPC, with egress through your own address and a domain allowlist; web search is off.
- Your own key and roles, with no cross-tenant path.
- Ephemeral storage.
- Your database is queried, not copied into ours; what’s kept, and for how long, is below.
- The support desk. Its widget runs in a frame on Winnfield’s own origin, embedded only on the sites you register. Its first-line assistant sees only your approved articles, the conversation and the signed-in user’s details your product sends. Only Winnfield’s read-only investigation touches code and data, and nothing a model writes reaches a customer without the checks and approvals your trust stage sets.
Prompt injection
Tickets, conversations and wiki pages are untrusted input, scrubbed on the way in. The egress allowlist is the control, and no agent holds a push credential or a live third-party key.
Our staff
Metadata only, with a stated reason, every look audited. No impersonation.
These controls bind Winnfield’s own software and staff roles. The owner of the AWS account that runs Winnfield, through the account’s root user, its administrator and one named break-glass role, sits outside them and could change them.
What’s kept, and for how long
- Runbooks and settings: while you’re a customer, and 90 days after.
- Build transcripts, checkouts and test records: 30 days, unless the current Runbook relies on them.
- Production data read while learning: deleted within eight days of the run.
- Downloaded dependencies: until a newer Runbook replaces them.
- Runtime images: until replaced, and at most 7 days after you leave.
- Checkpoints: until their run ends.
- Credentials: until you remove them, and at most 30 days after you leave.
- Our own database: metadata only, never your content.
When you leave
Export any time: the Runbook and Brief as Markdown, the audit log as CSV, job history as JSON.
- Day 0: no new work starts; running jobs finish, except learning and account enrollment, which stop.
- Day 1: the conversation service stops.
- Day 7: your infrastructure is deleted, each resource verified gone by ARN; what’s kept longer is recorded with its date.
- Day 30: your credentials are destroyed, your outbound address (once shown to you) is released, and we send you the statement to revoke your read-only database role.
- Day 90: your data is deleted, and your encryption key is scheduled for deletion.
Known limits
- On Postgres, the default PUBLIC privileges let a role create temporary tables and large objects of its own, which never touch your tables’ rows; we give your DBA the statements that remove them.
- An allowed shared host, such as github.com, or a CDN admits more than your part of it.
- A database address that a cloud provider shares between its customers can’t tell them apart.
- Scanning your repositories for secrets, and scrubbing them from output, find only the patterns they know.
- You confirm that staging is separate from production: the checks can’t see replication your database doesn’t report.
- Removing a person’s GitHub access doesn’t by itself remove Winnfield’s access: that comes from your organization’s installation, which your organization changes.
Documents
We’ll fill in your security questionnaire, and you can talk to the engineer who built the isolation. Winnfield holds no SOC 2 report or ISO 27001 certification.
Questions: write to us through the early-access form.
Questions
Does Winnfield write to our production database?
No. Winnfield reads production through a role your DBA creates with read-only grants. We generate the exact grant statement for your database engine and measure the credential’s privileges when you connect it. Read-only is enforced by your database, not by a prompt.
Can it push to main or merge?
No. Every code change arrives as a feature branch and a pull request that your engineers review and merge. Winnfield has no merge capability, and the credential that pushes a branch never enters the environment where the AI works.
What does it need from us?
Slack; your code on GitHub; Jira Cloud on Standard, Premium or Enterprise with Rovo turned on, or Linear; a read-only production database role and a disposable staging database; a read-only, log-scoped credential for your cloud; read-only access to your docs; and test-mode keys for the third-party services your code calls. The production credential never shares a machine with your running code.