Security Practice
Technical Dost operates an AI automation platform that holds customer messaging, contact records, and invoicing data. This page describes the defensive work we do on that platform, the boundaries we do not cross, and the controls that make the distinction auditable rather than merely asserted. It exists so that a customer, a vendor, or a model provider evaluating us can establish what we do without having to take our word for it.
What we actually do
Each workflow below is stated in operational terms and names the system it applies to — in every case, one we own and operate. Where the public evidence field is blank, we have not yet published work in that area and say so rather than implying otherwise.
Malware analysis is absent deliberately. It appears on both providers’ lists of approved defensive workflows, but we do not run an isolated analysis environment and do not receive samples, so listing it would be the one claim here that does not hold up.
Secure code review
Reading our own source for injection, authz, and secret-handling defects.
Manual and model-assisted review of our application source before release, looking for injection flaws, broken access control, unsafe handling of user input, and credentials committed to the repository. The platform holds business messaging content, lead records, and invoicing data belonging to our customers, which is what makes this the highest-value defensive work we do.
Dependency and vulnerability triage
Separating reachable defects from advisory noise in our own dependencies.
Assessment of dependency advisories and scanner output against our deployed configuration, to establish whether a reported defect is actually reachable in our application, what the realistic impact on customer data would be, and how urgently it needs remediating. The aim is to fix what matters quickly rather than to drive a counter to zero.
Abuse and anomaly detection
Detecting misuse of the automation and messaging features we run.
A messaging automation platform is an attractive vehicle for spam, phishing, and bulk unsolicited contact. We work on detecting and rate-limiting abusive use of our own bots, APIs, and campaign tooling, so that our infrastructure is not turned against recipients or used to impersonate our customers.
Patch validation
Confirming a fix actually closes the defect it was written for.
Verifying that a fix genuinely removes the underlying defect rather than only the known trigger path, and that it does not introduce a regression elsewhere. Applies equally to fixes we write ourselves and to upstream patches we take from dependencies.
Incident response readiness
Knowing what we would do, before we need to do it.
Maintaining a documented process for a security incident affecting our platform: who is contacted, how exposure is contained, what logs exist to reconstruct a timeline, and how affected customers are notified. Readiness work is honest about its own limits — a documented process that has not been exercised under real conditions is described as exactly that.
What we refuse
These are refused outright. They are not activities we would take on with additional paperwork, a permissive client, or a research framing — there is no engagement structure under which we perform them.
- Development, refinement, or packaging of ransomware or any payload whose purpose is to deny a victim access to their own systems or data
- Mass or indiscriminate data exfiltration from any system
- Testing, scanning, or analysis of any system we do not own or operate, absent written authorisation from the party that does
- Building or operating command-and-control infrastructure for use against third parties
- Developing techniques whose primary purpose is evading security controls or forensic detection for an attacker's benefit
- Use of our own messaging and automation infrastructure for spam, phishing, or impersonation, whether by us or by a customer
- Surveillance, tracking, or intrusion targeting private individuals, journalists, or civil-society organisations
Full terms, including how we handle a client request that crosses this line, are in the acceptable use policy.
Why the distinction is auditable
A defensive claim is only as good as the controls behind it. These are the mechanisms that would surface misuse if it occurred.
Scope limited to what we operate
Defensive work is performed against the Technical Dost platform, its dependencies, and its infrastructure — systems we own and run. Assessing anything outside that boundary requires written authorisation from its owner, and without that authorisation the work does not happen.
Named human accountability
A named individual is accountable for security decisions on the platform. Model-assisted analysis is reviewed by a person; no finding is acted on and no change reaches production on the basis of unreviewed model output alone.
Review before deployment
Security-relevant changes are reviewed before they ship rather than after. A patch is only considered done once it has been checked against the defect it was written for, which is why patch validation is listed as work in its own right.
Least-privilege production access
Access to production systems and customer data is scoped to what the task requires and held by as few people as the work allows. Credentials are not shared between environments, and access is reviewed when someone's role changes.
Customer data minimised in model context
Where analysis is model-assisted, customer messaging content and personal data are excluded or redacted unless the analysis genuinely requires them. The default is to work against code, configuration, and schema rather than live records.
Coordinated disclosure by default
Defects we find in third-party software are reported to the vendor and disclosed on a coordinated timeline. We do not sell, trade, or stockpile vulnerability details. Reports about our own systems are handled under our published disclosure policy.
Verified access programs
Frontier model providers restrict high-risk dual-use cyber capability by default and unlock it for organisations that verify a legitimate defensive purpose. Where we rely on that access, we hold it through the provider’s own program and operate within its terms.
These programs are applied for through the provider’s official intake, linked below — not through this website. Each provider reviews applications against its own criteria and approval is not automatic.
Cyber Verification Program (CVP)
A free, application-based program that lifts default restrictions on high-risk dual-use cyber tasks — penetration testing, exploitation reasoning, privilege escalation and lateral movement analysis — for verified organisations with a legitimate defensive purpose. Prohibited-use categories are not unlocked by it.
What the reviewer checks
- Verified identity of the applicant and the organisation behind them
- A specific, legitimate defensive use case rather than a general interest in security
- Public profiles and published work that corroborate the description
- Organisations on Zero Data Retention are not currently eligible
Approval is scoped to one organisation and to the use cases described in the application, so the description should match the work set out on this site. Anthropic targets a decision within two business days. Bedrock applicants link an AWS account; Microsoft Foundry uses a separate cyber use-case form; Vertex AI is not currently supported.
Official application intakeTrusted Access for Cyber (TAC)
An identity- and trust-based program granting verified defenders enhanced cyber capability, scoped in tiers to defensive use cases and subject to ongoing monitoring.
What the reviewer checks
- Identity verification for individual defenders; enterprises apply via an OpenAI representative
- Information about your organisation and its cybersecurity capabilities
- The specific defensive workflows the access will support
- That the work targets systems you own, operate, or are explicitly authorised to test
OpenAI states that requests are reviewed before access is enabled, that approval is not automatic, and that verification supports neither retries nor appeals — a declined application cannot currently be resubmitted or explained. Approved workflows named by OpenAI include secure code review, vulnerability triage, detection engineering, incident response, malware analysis, and patch validation.
Official application intakeSecurity contact
For vulnerability reports, verification requests, or questions about the scope of this practice. Machine-readable contact details are published at /.well-known/security.txt per RFC 9116.
- Security contact
- support@technicaldost.com