Product security and reporting status

Controlled-preview security boundary, implementation evidence, and the current vulnerability-reporting intake.

CONTROLLED PREVIEW. This page describes the current reporting boundary and implementation approach. It is not a certification, penetration-test report, service-level promise, bug-bounty offer, or proof that a generally available release exists.

Report a suspected Shielda vulnerability

Send an initial, non-sensitive description to security@shielda.ai. This is the security intake address designated in Shielda's current repository policy. Mail delivery, escalation coverage, and response timing have not been published as verified service commitments.

Include:

• the affected Shielda surface, URL, or version you observed;
• a concise impact summary;
• safe, minimal reproduction steps;
• whether you believe customer data or active exploitation may be involved.

Ask before sending logs, attachments, exploit code, source code, credentials, customer data, or other sensitive evidence.

Responsible testing boundary

Only test systems you own or are explicitly authorized to assess. Do not access or alter customer data, disrupt service, use high-volume testing, target third-party providers, or expand beyond the authorized target.

Give Shielda a reasonable opportunity to assess the report and coordinate any publication. This page does not promise a fixed acknowledgment, triage, remediation, or disclosure deadline.

Program status

• No public PGP fingerprint has been established.
• No public bounty or payment schedule is offered.
• No expanded safe-harbor promise is created by this page.
• No public scope list should be inferred from source repositories, package names, subdomains, or planned products.

Product-security approach

Shielda maintains implementation-level work around tenant scoping, bounded inputs, untrusted-content handling, approval custody, redaction, and evidence-oriented verification. Threat models and local tests can support a scoped technical review. They do not replace exact-release testing, deployment evidence, monitoring, incident ownership, external review where appropriate, or a release approval.

Read the current trust status or responsible-disclosure page for the corresponding public boundary.