Security & Vulnerability Disclosure

Last updated: 27 August 2026

We build automation for small businesses, and security is part of the product rather than an afterthought. If you have found a vulnerability in one of our systems, we want to hear about it. This page tells you how to reach us, what we will do, and what falls outside the scope.

Reporting a vulnerability. Email security@guerraaiautomations.com with “Security” in the subject line, or book a call if you would rather talk it through. We aim to acknowledge reports within three business days.

In scope

guerraaiautomations.com and its subdomains
aitoolsearch.ai
tastebudslbk.com
Automation workflows and integrations we operate on behalf of our clients

What to include

A report is far more useful when it contains enough for us to reproduce the issue:

The affected URL, endpoint, or workflow
Clear steps to reproduce, and what you expected versus what happened
Your assessment of the impact
Any proof-of-concept request or payload

Safe harbour

If you make a good-faith effort to comply with this policy, we will not pursue legal action against you for your research. Please give us a reasonable opportunity to fix the issue before disclosing it publicly.

Testing must stay within these bounds: do not degrade or interrupt our services, do not run automated scanning that generates significant load, do not access, modify, or exfiltrate data belonging to us or our clients, and do not use social engineering, phishing, or physical attacks against our staff or providers. If you encounter personal data, stop and tell us immediately rather than continuing to explore.

Out of scope

The following are reported to us frequently and we have already assessed them. Submitting one of these is unlikely to receive a substantive response:

Missing SPF, DKIM, or DMARC records on domains that send no mail — our non-sending domains are deliberately sealed with p=reject and a null MX
DMARC policies currently set to p=none on domains where we are actively collecting aggregate reports before enforcing
Missing security headers, cookie flags, or clickjacking reports on pages that carry no session and no user input
DNS records that intentionally resolve to a vendor rather than to us, including third-party CNAMEs required for email tracking and CRM white-labelling
Mail hostnames served DNS-only rather than proxied — this is required for IMAP, POP, and SMTP to function at all
Publicly documented software version numbers, absent a demonstrated exploit
Output from an automated scanner with no verified, reproducible impact
Rate limiting or brute-force concerns on endpoints already protected by authentication
Reports conditioned on payment before the details are shared

What we do not offer

We are a small business and we do not run a paid bug bounty. We are glad to credit researchers who report genuine issues, and we will say so publicly if you would like us to.

This policy is published in machine-readable form at /.well-known/security.txt in line with RFC 9116.