Acceptable Use Policy

All security work must have an identifiable defensive purpose: reducing risk to the platform we operate and to the customer data it holds. Curiosity, capability demonstration, and competitive advantage are not defensive purposes on their own.

Where a technique has both offensive and defensive application — analysing how a vulnerability is exploited in order to detect or patch it, for instance — it is performed only in service of a specific, documented defensive outcome on a system within the scope below.

Our defensive work is performed against systems Technical Dost owns and operates:

• the Technical Dost platform, its source, and its public API;
• its third-party dependencies and build pipeline;
• the infrastructure the platform runs on; and
• the messaging, campaign, and automation features we operate.

No system outside that boundary is tested, scanned, accessed, or assessed without prior written authorisation from the party that owns it. Where such authorisation is ever obtained, it must name the systems in scope and those excluded, the techniques permitted, the testing window, and a contact empowered to halt the work immediately.

A verbal go-ahead, a permissive-sounding email, or a public bug bounty page that does not cover the system in question is not sufficient authorisation.

The following are refused outright. There is no client, contract value, research framing, or engagement structure under which we perform them.

We use commercial AI models to assist defensive analysis. That use is governed by the same rules as any other work, plus the following:

• We operate within each provider’s usage policies. Where a provider restricts a dual-use capability behind a verification program, we obtain access through that program rather than attempting to work around the restriction.
• We do not attempt to bypass, jailbreak, or otherwise circumvent a model’s safety controls. If a model declines a task we believe is legitimate, the route is the provider’s verification process, not a workaround.
• Model output is reviewed by a named human before it is acted on. No finding is treated as real and no change reaches production on the basis of unreviewed model output.
• Customer messaging content and personal data are excluded or redacted from model context unless the analysis genuinely requires them. The default is to work against code, configuration, and schema rather than live records.

Where work uncovers something beyond the systems we operate — a defect in an upstream dependency, or a weakness in a third-party service we integrate with — investigation stops at that boundary. The finding is reported to the vendor under coordinated disclosure; it is not explored further against their systems without written authorisation.

Where a customer or prospect asks us to perform security work against a system they own, we do not proceed on the strength of the request alone. Where a request appears to indicate intent to cause harm to a third party, we decline it in full.

Findings in our own platform are fixed and, where they affected customer data, disclosed to the customers concerned. Defects in third-party software are reported to the vendor and disclosed on a coordinated timeline. We do not sell, trade, publish for effect, or stockpile vulnerability details, and we do not retain working exploit code beyond what is required to validate a fix.

Our own coordinated disclosure terms — for reports about our systems — are published separately in the responsible disclosure policy.

Breach of this policy by any person acting on our behalf is grounds for immediate removal from the engagement and termination of the working relationship. Suspected breaches — including by us — should be reported to the security contact:

support@technicaldost.com