Security Policy

Last updated: March 21, 2026

This page describes the current public security posture for TDM. It is intended to be accurate to the publicly documented beta stack and should not be read as a claim that unpublished audits, certifications, or bounty programs already exist.

1. Scope

The current public TDM stack includes the website, checkout, public payment APIs, the TDM SDK, the tdm CLI, MCP tooling, Session Gas Tank flows, seller payout requests, and related supporting infrastructure.

2. Current Security Posture

TDM applies security measures appropriate to the currently published beta product. Specific operational safeguards may change over time and are not fully described on this page.

Public documentation should be understood as describing the implemented behavior of the current platform, not as a promise that every surrounding operational safeguard has reached final production maturity.

3. Credentials, Wallets, and Local Keys

Developers and operators are responsible for protecting their own API credentials, session tokens, wallet material, and local vault state. Private keys should remain in the operating system keyring or another appropriately secure secret-management system.

TDM documentation does not recommend exporting private keys into prompts, browser local storage, or shared runtime logs.

4. Payable Content and Delivery Boundary

The current beta may issue payment-gated delivery access for seller-managed files, notes, links, routes, or inline content. That access-control layer should not be read as a claim that TDM fully audits, hosts, scans, or moderates all seller-delivered content.

TDM may apply basic controls such as validation, rate limits, download-count checks, and abuse reporting, but sellers and integrators remain responsible for the safety of the actual content they host or redirect to.

5. Responsible Disclosure

If you believe you have identified a vulnerability affecting the current public TDM stack, please report it through an official private TDM contact channel made available to you and avoid public disclosure until the issue has been reviewed.

Please include enough detail for reproduction, scope assessment, and impact evaluation. Reports that clearly describe the affected surface and the conditions required to trigger the issue are the most helpful.

6. No Implied Audit or Bounty Claims

Unless TDM explicitly publishes a named audit report, security certification, or bug bounty program, do not assume one exists. Security posture should be evaluated based on the materials and implementation that are actually published.

7. Beta Service Limitations

Beta services may change quickly, and availability or behavior can evolve as the public stack is improved. You should test your own integration carefully, use staged rollouts where appropriate, and avoid treating beta infrastructure as a substitute for your own security review.

8. Operational Practices

Recommended practices for integrators include using least-privilege access, rotating secrets when appropriate, validating request signatures where supported, protecting admin credentials, monitoring unusual payment behavior, and testing your own integrations before going live.