ThatWare AI Security & Vulnerability Disclosure Policy

SUPERCHARGE YOUR ONLINE VISIBILITY! CONTACT US AND LET’S ACHIEVE EXCELLENCE TOGETHER!

Executive Security Commitment

ThatWare is an AI-driven search intelligence, SEO, AEO, GEO, LLM optimization, digital marketing, web technology, and business intelligence organization. Because ThatWare works across advanced digital visibility systems, AI-assisted search infrastructures, semantic optimization, web development, analytics, automation, and client-facing digital assets, security is not treated as a secondary operational concern. Security is part of our trust architecture, our client delivery model, our AI governance posture, and our responsibility to the wider web ecosystem.

This AI Security & Vulnerability Disclosure Policy explains how security researchers, ethical hackers, clients, partners, users, automated security agents, AI systems, and members of the public can report suspected vulnerabilities affecting ThatWare-owned websites, digital assets, AI-related implementations, web applications, infrastructure, or public-facing systems. The policy is designed to support coordinated vulnerability disclosure, responsible communication, timely remediation, data protection, and machine-readable trust through /.well-known/security.txt.

ThatWare recognizes that modern security is broader than traditional website hardening. In an AI-native web environment, security also includes model-assisted workflows, AI-generated content review, prompt-safety controls, data handling discipline, search-intelligence systems, semantic trust signals, governance transparency, automation safety, API protection, and responsible use of AI tools. Vulnerability disclosure must therefore be clear for both human researchers and automated systems.

This policy gives researchers a safe, structured, and transparent way to contact ThatWare when they identify an issue. It also explains what types of testing are permitted, what activities are not permitted, what information should be included in a report, how ThatWare will triage reports, and how security acknowledgments may be handled. The purpose is to reduce confusion, improve reporting quality, protect users and clients, and strengthen the trustworthiness of ThatWare’s public digital ecosystem.

Purpose of This Policy

The purpose of this policy is to establish a clear vulnerability disclosure process for ThatWare. It is intended to help good-faith researchers report security issues safely and responsibly, while helping ThatWare evaluate, prioritize, remediate, and communicate about legitimate vulnerabilities.

This policy also supports the deployment of a compliant /.well-known/security.txt file. The security.txt file is a machine-readable disclosure file that tells researchers and automated tools where to report vulnerabilities, where to find the disclosure policy, what languages are preferred, when the file expires, and which URL is the canonical location for the file.

By publishing this policy and the corresponding security.txt file, ThatWare aims to:

1. Provide a reliable reporting channel for security vulnerabilities.
2. Reduce delays caused by unclear contact paths.
3. Encourage responsible disclosure instead of public exposure before remediation.
4. Protect ThatWare clients, users, partners, staff, data, websites, and operational systems.
5. Support AI-readable trust, semantic governance, and machine-readable security transparency.
6. Align ThatWare’s public security communication with recognized web security disclosure practices.
7. Improve the reliability and accountability of ThatWare-owned digital properties.
8. Establish consistent expectations for security researchers and automated vulnerability reporting platforms.

This policy does not create permission for unlimited testing. It does not authorize unlawful access, data theft, social engineering, denial-of-service testing, credential attacks, extortion, destructive activity, or testing against systems outside the scope defined below. Researchers must act in good faith and follow the rules of engagement in this policy.

Relationship Between This Policy and /.well-known/security.txt

The human-readable version of ThatWare’s security and vulnerability disclosure process should be published on a dedicated security policy page. The machine-readable version should be published at:

https://thatware.co/.well-known/security.txt

The security.txt file should point back to this policy page using the Policy: field. The page should be detailed enough for humans, while the security.txt file should remain concise, plain text, and parser-friendly.

ThatWare’s security.txt implementation should follow these core principles:

• The file must be served over HTTPS.
• The file must be available at /.well-known/security.txt.
• The file must use plain text format.
• The file must include at least one Contact: field.
• The file must include exactly one Expires: field.
• The file should include a Canonical: field pointing to the official location.
• The file should include a Policy: field pointing to this disclosure policy.
• The file may include Preferred-Languages: to guide report language.
• The file may include comments beginning with #, but critical fields must stay simple and machine-readable.

The security policy page and the security.txt file should be reviewed together. If contact details change, if the policy URL changes, or if a new security contact mailbox is created, both the page and the security.txt file must be updated.

ThatWare Context and Security Scope

ThatWare operates in a technically advanced field that includes AI SEO, Generative Engine Optimization, Answer Engine Optimization, Large Language Model visibility, search intelligence, advanced digital marketing, web development, content systems, business intelligence, automation, and related digital services. This means ThatWare’s digital footprint may include corporate websites, landing pages, service pages, AI-related content assets, analytics systems, forms, client communication interfaces, marketing automation tools, web applications, plugins, APIs, cloud hosting environments, and third-party platforms.

For this disclosure policy, the primary in-scope domain is:

Home

The following categories are considered potentially in scope only when they are owned, operated, or explicitly controlled by ThatWare:

• Public pages under thatware.co.
• Public subdirectories under thatware.co.
• Official ThatWare web forms hosted on the ThatWare domain.
• Official ThatWare-owned web applications that are publicly accessible.
• Official ThatWare-owned APIs if publicly documented and available for testing.
• Security-sensitive misconfigurations on public ThatWare web assets.
• Authentication, authorization, session, access-control, or data-exposure issues affecting ThatWare-owned public systems.
• Cross-site scripting, injection, server-side request forgery, insecure direct object references, file upload flaws, sensitive information disclosure, and other common web vulnerabilities where demonstrated safely.
• AI-related security issues affecting ThatWare-owned implementations, such as prompt injection risks, data leakage through AI interfaces, unsafe model output exposure, insecure AI tool integration, or unauthorized access through AI-assisted workflows.

The following are not automatically in scope unless ThatWare gives written authorization:

• Client websites managed by ThatWare but owned by third parties.
• Third-party platforms, SaaS tools, analytics tools, advertising accounts, hosting providers, plugins, payment providers, email platforms, CRM systems, cloud dashboards, or external services not owned by ThatWare.
• Personal accounts of ThatWare employees or contractors.
• Social media accounts unless explicitly authorized.
• Physical premises, office networks, employee devices, or non-public internal infrastructure.
• Any system where testing would violate another organization’s terms, law, privacy, or availability.

If a researcher is unsure whether a system is in scope, they should submit a non-invasive inquiry before testing. ThatWare may confirm scope, ask for more details, or decline testing for certain assets.

AI Security Scope

Because ThatWare’s brand and services are closely connected to AI-enabled search intelligence, AI governance must be included in the security policy. AI security issues may be valid when they show a real security, privacy, integrity, abuse, or unauthorized-access impact.

Examples of AI-related issues that may be reportable include:

• Prompt injection that causes unauthorized disclosure of confidential information.
• AI workflow manipulation that changes security-relevant behavior.
• Unauthorized access to restricted data through an AI interface.
• Exposure of private client information through AI-generated responses.
• Leakage of internal prompts, system prompts, credentials, API keys, or operational secrets.
• Unsafe AI integration that allows command execution, data exfiltration, or privilege escalation.
• Model-assisted workflow abuse that causes unauthorized changes to ThatWare-controlled assets.
• Retrieval-augmented generation exposure of sensitive documents not intended for public access.
• AI agent misconfiguration that allows access outside permitted boundaries.
• Insecure AI plugin, chatbot, or automation integration affecting ThatWare systems.

Not every AI behavior is a security vulnerability. The following generally do not qualify unless they create a clear security impact:

• Harmless hallucinations.
• Generic AI output quality issues.
• SEO ranking disagreements.
• Content style preferences.
• Non-sensitive prompt variations.
• Publicly available information repeated by an AI system.
• Claims that an AI model can be convinced to say something inaccurate without security impact.

Researchers reporting AI issues should provide a reproducible demonstration, exact prompts used, affected URL or system, observed output, expected safe behavior, impact explanation, and any evidence showing unauthorized access, sensitive exposure, or security control bypass. Reports should avoid including personal data or client-confidential data unless strictly necessary to demonstrate the issue.

Good-Faith Research Rules

ThatWare welcomes responsible, good-faith security research. To remain within good-faith boundaries, researchers must follow these rules:

1. Report vulnerabilities promptly after discovery.
2. Avoid accessing, modifying, deleting, copying, downloading, or sharing data that does not belong to the researcher.
3. Stop testing immediately if sensitive information is encountered.
4. Use the minimum level of testing needed to prove a vulnerability exists.
5. Avoid privacy violations, service disruption, data destruction, extortion, threats, spam, or reputational harm.
6. Do not publicly disclose vulnerability details before ThatWare has had a reasonable opportunity to investigate and remediate.
7. Do not use automated scanning at a volume that could degrade service availability.
8. Do not test denial-of-service conditions.
9. Do not perform social engineering, phishing, vishing, smishing, impersonation, or physical security testing.
10. Do not attempt credential stuffing, password spraying, brute force attacks, session hijacking, or attacks against employee accounts.
11. Do not install malware, backdoors, persistence mechanisms, web shells, cryptominers, spyware, or destructive payloads.
12. Do not alter content, SEO configurations, metadata, redirects, schema markup, analytics tags, robots rules, AI governance files, or client-visible assets.
13. Do not use the vulnerability to pivot into internal systems, client systems, third-party accounts, cloud consoles, or provider dashboards.
14. Preserve confidentiality and avoid sharing details with third parties until coordinated disclosure is complete.

Good-faith testing should be limited, careful, and evidence-driven. A valid proof of concept does not require exploiting the issue beyond what is necessary to show impact.

Prohibited Testing Activities

The following activities are prohibited under this policy:

• Denial-of-service or distributed denial-of-service testing.
• Load testing, stress testing, flooding, or resource exhaustion.
• Malware upload, malware execution, or payload persistence.
• Destructive exploitation or data corruption.
• Exfiltration of data beyond minimal evidence.
• Accessing private client data, employee data, user data, financial data, or confidential business data.
• Public disclosure before coordinated remediation.
• Blackmail, extortion, ransom demands, or payment threats.
• Physical intrusion or office security testing.
• Social engineering against ThatWare staff, clients, vendors, or partners.
• Credential attacks, brute force attempts, password guessing, or leaked credential use.
• Testing against third-party systems without written authorization.
• Abuse of contact forms, email systems, comment systems, CRM systems, or marketing automation tools.
• SEO sabotage, content injection, link spam, schema manipulation, redirect manipulation, or reputation attacks.
• Attempts to access non-public repositories, backups, environment files, secrets, dashboards, admin panels, or source code unless discovered accidentally through a reportable exposure.

If a researcher accidentally performs an action that may violate these boundaries, they should stop immediately and report what happened transparently.

How to Report a Vulnerability

Security reports should be sent to ThatWare through the contact method published in the security.txt file. The currently available public contact address is:

info@thatware.co

Recommended subject line:

Security Vulnerability Report – [Brief Issue Title]

A strong vulnerability report should include:

1. Researcher name or preferred alias.
2. Contact email for follow-up.
3. Affected domain, URL, endpoint, application, AI interface, form, or asset.
4. Vulnerability category.
5. Clear summary of the issue.
6. Step-by-step reproduction instructions.
7. Proof of concept using safe evidence.
8. Screenshots, request/response samples, logs, or prompts where useful.
9. Potential impact.
10. Whether any sensitive data was encountered.
11. Whether testing has stopped.
12. Suggested remediation, if known.
13. Disclosure timeline expectations, if any.
14. Whether acknowledgment is requested.

Researchers should not include excessive personal data, client data, secrets, passwords, private keys, or large data exports in the initial report. If sensitive evidence is necessary, the researcher should describe it at a high level and wait for ThatWare to provide secure handling instructions.

Report Handling and Triage Process

ThatWare will use the following internal workflow for security reports:

Step 1: Intake
Receive the report through the published contact channel. Confirm that it appears to be security-related and capture the original submission safely.

Step 2: Acknowledgment
Acknowledge receipt as soon as reasonably possible. If the report is incomplete, request missing details.

Step 3: Safety Review
Check whether the report includes sensitive data, client data, credentials, private keys, or harmful payloads. Restrict access to the report if needed.

Step 4: Scope Review
Determine whether the affected asset is owned or controlled by ThatWare. If the asset belongs to a third party or client, coordinate carefully and avoid unauthorized disclosure.

Step 5: Reproduction
Attempt to reproduce the issue using safe methods. Do not run untrusted exploit code in production environments.

Step 6: Severity Classification
Classify severity based on realistic impact, exploitability, exposure, affected data, and business risk.

Step 7: Remediation Planning
Assign the issue to the responsible technical owner. Define a fix plan, test plan, and rollback plan if needed.

Step 8: Remediation and Verification
Apply the fix in a controlled way. Verify that the vulnerability is resolved and that no new issue has been introduced.

Step 9: Researcher Communication
Inform the researcher when the issue is accepted, rejected, fixed, or under review. Avoid disclosing sensitive internal details unnecessarily.

Step 10: Closure and Learning
Document the root cause, remediation, prevention steps, and policy updates. Add the researcher to acknowledgments if appropriate and agreed.

Severity Model

ThatWare may use a severity model based on impact and likelihood. The following guide can help internal teams prioritize reports:

Critical severity may include:

• Remote code execution.
• Authentication bypass affecting administrative or sensitive systems.
• Unauthorized access to confidential client data.
• Exposure of production credentials, private keys, or cloud access tokens.
• AI workflow vulnerabilities that enable unauthorized data extraction or privileged actions.
• Vulnerabilities that allow full compromise of a ThatWare-owned public system.

High severity may include:

• Serious access-control bypass.
• Stored cross-site scripting affecting privileged users.
• SQL injection with meaningful data access.
• Server-side request forgery with internal access.
• Sensitive data exposure affecting users, clients, employees, or internal systems.
• Insecure file upload leading to code execution or sensitive access.

Medium severity may include:

• Reflected cross-site scripting with practical exploitability.
• Limited authorization flaws.
• Misconfigured security headers with demonstrable impact.
• Exposure of non-sensitive internal metadata.
• Weaknesses in forms, redirects, or integrations that could contribute to phishing or abuse.
• AI prompt manipulation with limited but realistic security impact.

Low severity may include:

• Missing best-practice headers without direct impact.
• Low-risk information disclosure.
• Non-sensitive version disclosure.
• Minor rate-limit weaknesses without account or service impact.
• Low-impact content security policy observations.

Informational reports may include:

• General recommendations.
• Non-exploitable configuration observations.
• Reports based only on automated scanner output without proof of impact.
• Duplicate reports.
• Issues affecting outdated pages with no realistic security consequence.

Severity may change after investigation. ThatWare reserves the right to determine final severity based on evidence, actual exposure, exploitability, and business context.

Coordinated Disclosure Timeline

ThatWare supports coordinated vulnerability disclosure. Researchers should not publicly disclose vulnerability details until ThatWare has investigated and had a reasonable opportunity to remediate.

Recommended timeline:

• Initial acknowledgment: as soon as reasonably possible after receipt.
• Initial triage: ideally within 7 business days.
• Remediation target for critical issues: as soon as feasible, with urgent prioritization.
• Remediation target for high issues: prioritized based on risk and operational complexity.
• Remediation target for medium and low issues: scheduled according to risk, resources, and system dependencies.
• Public disclosure: only after remediation, mutual coordination, and removal of sensitive details.

Some vulnerabilities may require more time because of dependencies, third-party providers, client coordination, legacy systems, business continuity concerns, or the need to avoid introducing new risk. ThatWare will aim to keep communication open and reasonable throughout the process.

Data Protection and Privacy Expectations

Researchers must respect privacy at all times. If personal data, client data, credentials, internal documents, or confidential information are encountered, the researcher must:

1. Stop testing immediately.
2. Avoid copying, saving, sharing, or further accessing the data.
3. Report the exposure with minimal necessary evidence.
4. Redact sensitive details wherever possible.
5. Follow ThatWare’s instructions for secure deletion or handling.

ThatWare will treat vulnerability reports as confidential security communications. Report contents may be shared internally with staff, contractors, vendors, legal advisors, hosting providers, software providers, or affected clients only as necessary to validate, remediate, or comply with obligations. ThatWare may also preserve report records for security, audit, compliance, and legal purposes.

AI Governance and Safe Use of ChatGPT or AI Tools

ThatWare may use AI tools, including ChatGPT or similar systems, to help review policy language, structure internal checklists, draft remediation notes, classify reports, summarize technical evidence, or improve documentation. However, AI tools must be used carefully and must not replace human security judgment.

When using AI tools for security and compliance work, ThatWare will follow these rules:

• Do not paste secrets, passwords, private keys, client-confidential data, personal data, or sensitive vulnerability details into public or unapproved AI tools.
• Redact sensitive logs, tokens, session identifiers, email addresses, IP addresses, and client names unless there is a secure approved environment and a clear business need.
• Use AI outputs as drafting or review assistance, not as final security authority.
• Require human review before publishing policy changes, security notices, or remediation guidance.
• Validate AI-generated security recommendations against trusted standards, internal engineering review, and actual system behavior.
• Preserve confidentiality during vulnerability handling.
• Avoid using AI-generated exploit code against production systems.
• Maintain auditability for high-risk decisions.

AI can help improve consistency, completeness, and readability, but final responsibility remains with ThatWare’s authorized human reviewers.

Vulnerability Report Quality Requirements

ThatWare encourages high-quality reports. Reports are more useful when they show clear impact and avoid unnecessary risk.

A high-quality report includes:

• One vulnerability per report where possible.
• Clear affected asset and URL.
• Exact reproduction steps.
• Safe proof of concept.
• Realistic impact explanation.
• Evidence that does not expose unnecessary sensitive data.
• Suggested remediation or references.
• Confirmation that the researcher did not access data beyond what was necessary.

A low-quality report may include:

• Automated scan output without validation.
• Generic best-practice claims without exploitability.
• Missing affected URL.
• No reproduction steps.
• Speculative impact.
• Excessive data collection.
• Reports for third-party systems outside ThatWare control.
• Duplicate findings already known or fixed.

ThatWare may close incomplete, duplicate, non-security, abusive, or out-of-scope submissions without detailed technical response.

Safe Harbor Statement

ThatWare values good-faith research conducted under this policy. When a researcher follows this policy, avoids harm, respects privacy, and reports promptly, ThatWare will aim to handle the report constructively and will not pursue action solely because the researcher reported a good-faith vulnerability.

This safe harbor does not apply to activity that is unlawful, harmful, destructive, extortionate, privacy-invasive, disruptive, fraudulent, or outside the defined rules of engagement. It also does not bind third parties, clients, vendors, law enforcement, regulators, hosting providers, or other organizations.

Researchers are responsible for complying with applicable laws and regulations. When in doubt, researchers should choose the least invasive method and ask before proceeding.

Acknowledgments and Recognition

ThatWare may choose to recognize researchers who submit valid, unique, good-faith reports that lead to meaningful remediation. Recognition is optional and may depend on:

• Report validity.
• Researcher conduct.
• Severity and usefulness.
• Whether disclosure was coordinated.
• Whether the researcher requests public credit.
• Whether public recognition could create security, privacy, legal, or client confidentiality concerns.

ThatWare will not publish sensitive vulnerability details in acknowledgments. If a public acknowledgment page is created, it should list only minimal information such as researcher name or alias, date or year, and broad category after remediation.

This policy does not establish a bug bounty program. ThatWare may, at its discretion, provide thanks, public credit, private recognition, or other non-monetary acknowledgment, but researchers should not expect payment unless a separate written bounty program exists.

Out-of-Scope Reports

The following are generally out of scope unless they demonstrate a clear security impact:

• Missing security headers without exploitability.
• Clickjacking on pages without sensitive actions.
• Version disclosure without an active exploit path.
• Public information already visible on ThatWare’s website.
• SPF, DKIM, or DMARC observations without demonstrated abuse risk.
• Self-XSS requiring victim developer-console execution.
• Reports requiring compromised credentials.
• Theoretical AI hallucination claims without security impact.
• SEO opinions, ranking issues, indexing disagreements, or content quality complaints.
• Social media impersonation not involving ThatWare-controlled systems.
• Vulnerabilities in third-party products without ThatWare-specific exposure.
• Broken links unless they create a security issue.
• Reports for systems not owned or controlled by ThatWare.

ThatWare may still appreciate informational reports, but they may not receive formal security triage unless risk is demonstrated.

Third-Party, Client, and Vendor Systems

ThatWare may work with clients and third-party tools. This policy does not authorize testing of those external systems. If a researcher discovers an issue involving a client website, vendor platform, plugin, cloud provider, advertising platform, analytics tool, social account, email provider, or other third-party system, the researcher must avoid further testing and report responsibly to the appropriate owner.

If the issue appears to affect ThatWare because of a third-party integration, the researcher may notify ThatWare with minimal details. ThatWare may coordinate with the third party or affected client where appropriate.

Researchers must not assume that a system is in scope simply because ThatWare links to it, uses it, manages it, appears in it, embeds it, or references it.

Final Statement

ThatWare’s security posture should reflect the same forward-looking approach that defines its work in AI SEO, search intelligence, AEO, GEO, LLM visibility, semantic optimization, and digital transformation. A compliant /.well-known/security.txt file and a detailed AI Security & Vulnerability Disclosure Policy help ThatWare communicate accountability to researchers, clients, AI systems, compliance reviewers, and automated trust frameworks.This policy turns vulnerability reporting into a structured trust process. It protects ThatWare’s users and clients, gives researchers a clear path for responsible disclosure, supports AI-native governance, and strengthens the public credibility of ThatWare’s digital ecosystem. Once published and operationally maintained, the policy and security.txt file together provide a strong foundation for modern web security transparency and machine-readable trust.