Privacy Policy

Last updated: 16 October 2026

This policy explains what WhyStack collects, where it lives, how long we keep it, who can reach it, and how you get rid of it. It is written to be checked against the product rather than read once: where a claim is architectural, we say where it is enforced.

WhyStack (formerly RootPilot) is operated by Sunny Systems Ltda. ("Sunny Systems", "we", "us"), a company incorporated in Brazil under CNPJ 40.185.842/0001-80.

The architecture comes first, because it decides most of the answers

WhyStack runs in two halves. The Agent runs inside your infrastructure and holds your credentials; the control plane runs in ours and holds the intelligence. That split is not a deployment preference. It is what makes most of this policy short.

  • We never hold your credentials. The Agent reads them from your secret manager at boot and keeps them in memory only. Nothing of yours is stored in our systems, our images, or our database. There is no configuration in which this changes.
  • Personal data is redacted before it reaches us. Redaction happens at the Agent's edge, inside your network, before any result crosses the boundary. It is a single enforcement point, not a promise repeated in several places.
  • The half that touches your credentials is constrained by construction. The Agent is delivered as a container image. It opens no inbound port: it connects out to our control plane. It executes only a closed catalog of read operations, plus writes to Jira, Slack and GitHub issues that require explicit confirmation and are audited. The categories of read you deny are removed in the Agent itself, and it reports back what it applied.

The practical consequence: the majority of your production data never enters our systems at all. What this policy governs is mostly metadata and derived findings, after redaction.

Two different roles, and the difference matters

Under the LGPD we act in two capacities, and conflating them would make this policy misleading.

As controller, for the data of people who use the product: your team's names, email addresses, sign-in activity, IP address and browser user agent recorded in audit logs, the network address each access token last connected from, and billing details where applicable. We decide how that data is handled.

As operator (processor), for everything the product observes in your environment: service and resource names, topology, metrics, incident records, investigation traces. You remain the controller of that data. We handle it to deliver the service, on your instructions, and the controls described below are how you give those instructions.

What we hold about your environment

After edge redaction, the control plane keeps:

  • Investigation records: which tools an investigation called, the arguments it used, and a truncated, redacted summary of each result (not the full payload). We do not receive or store the prompts your team writes: our server sees tool calls, not conversations.
  • Discovered inventory: names of services, repositories, queues, DNS records, cloud accounts and resources, and the relationships between them. This is the map that lets an investigation start from knowledge instead of from zero.
  • Learned baselines: normal ranges for your metrics, by hour and day of week.
  • Incident records and diagnoses, including the original alert payload from your incident management tool. Alerts arrive directly at our webhook rather than through the Agent, so edge redaction does not apply to them. This channel only exists for an organization once you request it.
  • Post-incident reports: prose written by the product about what broke, including service names, commits and identifiers that make the report verifiable.
  • Context your team attaches to a post-incident report, such as a war-room transcript, if an owner or administrator has enabled it. It reaches us through the product rather than through the Agent, so edge redaction does not apply. We redact it on arrival (credentials, email addresses, IP addresses, keys, card numbers, phone numbers and the Brazilian tax IDs CPF and CNPJ) and keep only the redacted text, inside the report. The original is not stored. This redaction does not detect names written in prose.
  • Audit logs of actions taken in the product, with actor, IP address and user agent.
  • Operational telemetry of our own systems, exported to a collector inside our private network. It never leaves for a third-party service.

If you install the Profiler

The WhyStack Profiler is a separate, optional component. If you install it, behavioural signatures cross the boundary that include the function name, file and module of the code that allocated memory.

We state this plainly because it cannot be redacted: removing the symbol destroys the only thing that makes the signature useful, so offering a mask would be worse than the exposure. If that class of data may not leave your boundary, the correct answer is not to install the Profiler. The rest of WhyStack works without it.

What never leaves, in any configuration: request or response bodies, log contents or any payload; plaintext of TLS connections; peer IP addresses; process arguments and environment variables.

What never reaches us

  • Your credentials, keys or tokens for any system.
  • Raw production personal data, which is redacted at the Agent's edge before crossing.
  • The contents of objects in your storage buckets. No operation reads an object body.
  • Your prompts and conversations with your own AI assistant.

Your systems' text reaches a model, and it can carry instructions

To investigate anything, the product puts text your systems produced in front of a language model: log lines, monitor and alert names, issue titles, resource tags, commit messages. That is the point: it is what lets an investigation reason about your environment rather than about nothing.

It has a consequence worth stating plainly: anyone who can write into those systems can write into a prompt. A monitor named to read as an instruction, or a log line crafted to look like one, arrives at the model along with everything else. So does the title of an alert, which reaches us from your incident management tool rather than through the Agent.

What we do about it:

  • Anything derived from your systems is enclosed and labelled as untrusted data, with the model told that the text inside is a symptom to analyse and never an instruction to follow.
  • The enclosure cannot be forged by what it contains. Text that tries to close the marker early is neutralised before the prompt is assembled, so injected instructions cannot escape into the part of the message the model reads as ours. This is checked on every change in our test suite rather than asserted here.
  • We test the behaviour, and we do not promise it. The enclosure is structural and always applies; whether a model resists a well-crafted instruction is behaviour, and behaviour changes when models change. We measure it against deliberately hostile cases, and we will share what we measured, dated, on request.

The containment that does not depend on the model getting it right is the architecture. The Agent executes only a closed catalog of read operations. The few writes it can perform (a Jira issue, comment or status change, a Slack message or channel, a GitHub issue) are records in tools your team already uses, never changes to your infrastructure; the ones an investigation initiates require explicit confirmation, and all of them are audited. A model that had been successfully steered still could not alter anything in your environment, because no part of the product can.

If this class of risk is unacceptable for your environment, model processing is a switch (see Your controls below): turned off, nothing derived from your environment reaches a model through us.

Where your data lives

In Brazil. Our database is hosted on managed PostgreSQL in a Brazilian region, and our application runs on Magalu Cloud, a Brazilian provider. Everything this policy describes as stored is stored in Brazil.

Some data is transmitted abroad for processing, and we name the three cases rather than leave the sentence general:

| Recipient | Purpose | What it receives | | --- | --- | --- | | Anthropic | Analysing investigations and writing incident diagnoses | Investigation traces and incident material, after edge redaction | | Resend | Transactional email: verification, two-factor codes, invitations | Name and email address of your team members | | GitHub | Product-improvement issues raised from generic findings | Scrubbed finding text and your organization identifier |

Under Anthropic's commercial API terms, inputs and outputs are not used to train models. If you prefer that nothing of yours reaches a model provider through us, you can turn model processing off for your organization (see Your controls). We can also forward a zero-retention request to Anthropic on your behalf, though that agreement requires their approval and is not ours to grant.

Sub-processors

| Sub-processor | Role | Location | | --- | --- | --- | | Supabase | Managed database | Brazil | | Magalu Cloud | Application hosting | Brazil | | Anthropic | Model inference | United States | | Resend | Transactional email | United States | | GitHub | Source hosting, CI, product issues | United States | | Stripe | Billing, where applicable | United States | | Google | Optional sign-in | United States |

Slack and Jira are not our sub-processors. When the product writes to them it uses your credential, from your Agent. We never hold that token.

We will give reasonable advance notice of a new sub-processor.

How long we keep it

| What | Retention | | --- | --- | | Investigation records | 90 days | | Live investigation state | Deleted when the session ends | | Discovered topology, DNS, resources and tenant notes | No longer used after 30 days without being observed again; deleted after 10 years | | Learned baselines, service-to-repository mappings, queue roles, business flows | Kept until deletion is requested; baselines are replaced on recompute | | Incident records, diagnoses and post-incident reports, including attached context | Kept until deletion is requested | | Audit logs | Kept until deletion is requested | | Last connection origin of each access token | Replaced on every use; cleared on revocation; discarded after 90 days unused (see Your controls) | | Profiler signatures | Latest signature per process kept until deletion is requested; earlier captures 90 days | | Agent connection history | 7 days after disconnect | | Record of certificates issued to your Agents | 90 days after each certificate expires | | Operational telemetry of our own systems | Traces and logs 15 days, metrics 30 days | | Anonymized cross-organization aggregates | Retained (see Aggregated learning) |

Removal runs in periodic passes, so an item is removed at the first pass after its period ends. Retention periods are configured per installation, not per organization. If you need a different period, tell us before you start and we will confirm whether we can commit to it.

Aggregated learning, and what survives deletion

WhyStack can learn generic patterns across customers: for example, that services of a certain role commonly depend on services of another role. Two things about this deserve to be stated directly.

It is anonymized by construction, not by policy. Service names are converted to categorical roles and metric keys to metric kinds before anything is contributed. The record type that carries a contribution has no field a name could occupy, so a name cannot pass through it.

It is off by default, and a contribution already made cannot be withdrawn. These pooled tables carry no organization identifier. That is deliberate, and it means we cannot locate or remove one customer's past contribution. Because there is no "after", the consent has to happen before: contribution is opt-in, it starts off, and turning it off stops future contributions rather than undoing prior ones.

Your controls

All of these are self-service for owners and administrators, and every change is written to your audit log.

  • Model processing. Turn it off and nothing derived from your environment reaches any model provider through us. You lose learned memory, incident synthesis and autonomous investigation; the tools your agent calls are unaffected.
  • Aggregated contribution. Off by default, for both learned aggregates and product findings.
  • Context on post-incident reports. Off by default. When on, your team can attach context such as a war-room transcript to a report; it is redacted on arrival and deleted with the report. While it is off, a request to attach context is refused and nothing is published.
  • Tool denylist. Restrict which categories of read the Agent may perform: for example, allow metrics and logs but not security-group configuration. Composed here, enforced in your Agent, and reported back so you can verify what is actually applied.
  • Network origin allowlist. Restrict which network ranges may open a session, so a leaked access token is not enough on its own.
  • Connection origin. To help you build that allowlist without locking your team out, we record the network address each access token last connected from: one value per token, overwritten on every use, visible only to your owners and administrators. Revoking a token clears it, and addresses not seen for 90 days are discarded when your allowlist settings are next read, not on a fixed schedule. It is on by default; turning it off stops recording and erases what was already recorded.
  • The Profiler is opt-in twice. It is a separate artifact you choose to install, and it also has to be enabled for your organization by an owner. That switch gates the certificate the privileged agent needs in order to connect at all, and it starts off. Switching it back off stops renewal too, so a running Profiler stops when its current certificate expires: minutes, not instantly. We say that rather than present it as an immediate kill switch. The list of processes it may observe stays yours: a capture request names a workload, and what that name resolves to is decided inside your infrastructure, against a list that is never sent to us.

Who can reach your data, on our side

There is no support impersonation, no cross-customer administration panel, and no "view as customer" mode in the product. A user only ever sees the organizations they belong to.

Operational access to the database and servers is held by a named, deliberately small group of permanent staff, granted on least privilege and reviewed as roles change. We use no outsourced support or contractors for operations, and we do not grant standing access to anyone outside that group.

We will tell you who currently holds it, in writing, on request. That answer is dated, because it changes as the company does, and a number printed on this page would quietly stop being true. On request we will also enable and export the platform access log for your review.

Deletion

An owner can delete an organization from its settings page. Deletion removes investigation records, post-incident reports, Profiler signatures, discovered inventory, audit logs, tokens and certificates. The sensitive categories are erased explicitly and the erasure is recorded, rather than disappearing silently as a side effect.

  • We complete a deletion request within 10 business days.
  • Backups expire on their own within 7 days, so a deletion is fully propagated within 17 calendar days.
  • At the end of a trial without a contract, we delete your data within 30 days and confirm it. This is our obligation, not a button you have to remember to press.
  • Anonymized aggregates are the one exception, for the reason given above.

Your rights

Under the LGPD you may request confirmation that we process your data, access to it, correction of incomplete or outdated data, anonymization or deletion, portability, and information about with whom we share it. Where we act as operator for your environment data, we support your own responses to the people whose data you control.

Write to contato@sunnysystems.com.br. We answer within the periods the law requires.

Our data protection officer (encarregado) is Bruna Cursini, reachable at bruna@sunnysystems.com.br.

Security

Data is encrypted in transit throughout: mutual TLS between your Agent and our control plane against our internal certificate authority, and TLS on every other path. Data is encrypted at rest by our database provider. Our own application secrets are held in a managed secret store with access control, versioning and audit.

We do not currently hold an ISO 27001 certificate or a SOC 2 report. We maintain an internal controls assessment mapped to the SOC 2 Trust Services Criteria and will share it under NDA on request. We would rather tell you that than imply a certification we do not have.

Changes

We will post material changes here with a new date, and give notice to active customers before they take effect.