How we protect
your Datadog and your data

Each common security-questionnaire topic points to the section that answers it.

What holds today, in production, for every organization.

• Hosted in Brazil. The application runs on Magalu Cloud, region br-se1 (Southeast Brazil), and the database on Supabase, region sa-east-1 (São Paulo). The third parties that receive data outside Brazil are in the subprocessor list.
• Every connection uses HTTPS, with HSTS. Sunshine's calls to the Datadog API are HTTPS too, and only to the Datadog site you picked from the list of official sites. At rest, the database is encrypted by its provider (Supabase), and credentials get a second layer in the vault.
• Your Datadog keys (API key and application key) are kept encrypted in the database vault (Supabase Vault), and only the backend reads them. Once saved, they never go back to a browser — not yours, not our staff's: screens show only the last few characters. Integration tokens (GitHub, Jira, Linear) follow the same rule.
• Each organization sees only its own data. On every request, the backend checks that the user has an active membership in the organization being asked for. The database has row-level security (RLS) on every table and denies direct access to the public roles.
• Sign-in with email and password always requires a second factor (authenticator app or emailed code); passwords are stored with bcrypt, and an account locks for 15 minutes after 5 wrong attempts. You can also sign in with Google, under the second factor of your Google account. The session lives in an HttpOnly, Secure cookie. SSO/SAML is not available yet.
• Three roles per organization: owner, admin and member. Only owners and admins register credentials, approve actions that write to your Datadog account and see the audit log.
• Sunshine writes to your Datadog account in only two cases: when an owner or admin approves an action (a proposal in the queue, a tag edit), or when an automation you explicitly turned on acts within the limit you set. Automations start in simulation mode, and real execution must be enabled separately. Write scopes on the application key are optional: without them, Sunshine only reads.
• Sunny's operations team is a restricted list of accounts. For support, it opens your organization's screens in observer mode, read-only: the system refuses any write in that mode. The team's administrative actions (plan, enabled features, archiving) are recorded in our audit log.
• Your organization's audit log, visible to owners and admins, records sign-ins, organization changes, members, roles and invitations, and every creation, change or removal of the Datadog credential.
• Scheduled jobs authenticate with short-lived OIDC tokens issued by GitHub Actions, bound to the repository, the workflow and the job.
• The image is built in CI and released by tag, and application secrets come from a secrets manager. Every PR and deploy runs static analysis (Semgrep), a secrets and misconfiguration scan (Trivy), an image scan (Trivy) and a passive application scan (OWASP ZAP). Findings are reviewed; today they do not block the deploy yet. Dependencies are updated weekly (Dependabot).
• The application's own telemetry (traces, metrics and error logs) goes to an observability instance run by Sunny, on the same cloud in Brazil. It may contain a user's email in authentication errors and the addresses of Datadog API calls.

Security here is split. What is ours, and what is yours:

Third parties that process data so Sunshine can work.

Not on the list, because you are the one who connects them: Datadog itself, and Slack, GitHub, Jira and Linear when you set up alerts or ticket creation. In those cases the data goes to your company's own account in that service.

The model is never the detector. Patterns, costs, findings and proposals are computed by deterministic code; the model only names, explains or triages what the code found, and no automatic decision reads what it says. Turning an AI feature off leaves the rest of the product working.

• Provider: Anthropic (Claude models), through its commercial API. There is no other AI provider.
• Never sent to the model: the real log message, attribute values, your organization's name or identifier, monitor names and messages, cost, credentials.
• What is sent is structure: the service, the status, the log template with emails, IPs, UUIDs, numbers and identifiers replaced by placeholders, and field names. Before it leaves, the value of any field with a sensitive name (password, token, tax ID, email…) and any known secret shape (cloud keys, JWT…) become placeholders.
• From the model, the database keeps only a value from a closed list (the label or the verdict), with the model and prompt version. Explanatory text lives only in the cache. Requests and responses are not logged.
• Each feature is measured before it reaches you: a synthetic example set, reviewed blind by a person, and a CI gate that fails on a quality drop. The product refuses to use a model that gate has not measured.
• Each feature can be turned off for your organization alone: ask through the contact at the end of this page. It applies from the next run.

What masking does not catch, and why each feature can be turned off: a person's name in free text ("order from Maria Silva") and a password with no known shape outside a field with a sensitive name. If your policy does not accept that risk, ask us to turn the feature off.

What we keep, where, and for how long.

Personal data in your logs. A deterministic detector checks the shape of every candidate before calling it sensitive (Luhn for cards, check digits for Brazilian CPF and CNPJ, mod-97 for IBAN, published credential formats) and redacts the log example before storing it: <CPF>, <CARD>, <EMAIL>, <SECRET>. Of what it finds, only the structure is stored: class, field and count, never the value. One exception, named: the query of an "accidental debug statement" finding keeps the literal snippet of the log line that defines it; it stays in your organization's database and never goes to the model.

Deletion. Today nothing is deleted on a schedule: data stays while the organization exists. An owner can delete the organization in the app, which removes its data from the database. To also remove credentials and cache, or to receive a copy of your data, write to the contact below.

Sunshine does not have a formal certification (SOC 2, ISO 27001) or a third-party pentest report yet. What exists is on this page, and the rest is available on request:

• We answer your company's security questionnaire.
• We sign a data processing agreement (DPA) with you.
• We hold a technical architecture session with your security team.

To request any of these, or to request deletion, a copy of your data or turning an AI feature off: contato@sunnysystems.com.br

Found a vulnerability? Write to the same address with "security" in the subject. We will reply and agree on disclosure with you.