At Tightknit, we take data security and privacy seriously. We implement industry-standard encryption, retention policies, and access controls to ensure customer data remains secure at all times.
Customers have 30 days to export their data after subscription cancellation. After this period, Tightknit is not obligated to retain customer data and may delete all related records.
Tightknit takes a security- and privacy-first approach to integrating AI into our platform. We apply rigorous controls and transparency around how AI models interact with customer data, ensuring all AI usage aligns with our broader privacy and security policies.
Tightknit uses a combination of third-party and open-source AI models, which are run exclusively on our own managed infrastructure. This gives us full control over where and how models are used, ensuring customer data never leaves our environment without consent.
We leverage select third-party models under contractual agreements that explicitly prohibit training on customer data. These models are accessed in a way that enforces inference-only behavior, and we work exclusively with providers who offer training-disabled APIs or compute isolation to preserve privacy.
For scenarios where open-source models are used, we host and run them locally on Tightknit infrastructure. This ensures full visibility and auditability, and that customer data never leaves Tightknit’s systems during AI inference.
Tightknit does not use customer data to train, fine-tune, or adapt AI models—whether proprietary, open source, or third-party. Your data is not used to improve models for other users or for future model development by Tightknit or our partners.
To ensure the safety, quality, and reliability of AI-powered features, Tightknit logs evaluation data related to AI model behavior. These logs may include anonymized prompts and outputs and are used strictly for testing, monitoring, and improving the safety of AI features. Logs are stored securely, access-controlled, and subject to strict internal handling policies.We do not link AI evaluation logs to individual users unless it is necessary for debugging with explicit customer involvement. All logging practices are aligned with our data retention and privacy policies.
To ensure seamless service delivery, Tightknit engages select subprocessors for specific functionalities. A complete list of subprocessors is available in our Trust Center, where users can sign up for updates regarding any changes.
Data breaches are an unfortunate reality that can threaten organizations.As a result, Tightknit is committed to taking all commercially reasonable measures to secure your customer data. This is why we are overwhelmingly transparent and about our security practices to give you the confidence in our infrastructure, processes, tooling, and policies to safeguard your data.Tightknit has not had an identified data breach since commencing operations. In the unlikely event of a data breach, Tightknit is prepared to take steps to limit the effects of any data breach and to assist any customers potentially affected by a data breach with meeting their obligations under law.
Tightknit will notify customers without undue delay after becoming aware of a data breach. Customers will be contacted by email, Slack (when available), and phone (when provided), and followed by multiple periodic updates throughout each day addressing progress and impact.
Tightknit utilizes a multi-tenant architecture where all customers share the same computing resources. Logical separation of data between customers and correct access is enforced through PostgreSQL Row Level Security (RLS). Transaction-scoped configuration variables are leveraged in RLS policies to ensure the correct access permissions.
Tightknit maintains documented Software Development Life Cycle (SDLC) policies and procedures to guide developers in implementing and documenting application and infrastructure changes.
All code is deployed and tested in a staging (development) environment that is functionality equivalent to production environments. Tightknit performs testing and quality assurance procedures in this staging environment before releasing to the production environment that is used by customers. No customer data is ever used or accessible from staging or local development environments.
Tightknit employs Git version control to maintain source code versions and manage the migration of source code through the development process through to release. Using a decentralized version control allows multiple developers to work simultaneously on features, bug fixes, and new releases; it also allows each developer to work on their own local code branches in a local environment. Git maintains a history of code changes, supports rollback capabilities and tracks changes to individually identifiable developers.All code is written, tested, and saved in a local repository before being synced to the origin repository. Writing code locally decouples the developer from the production version of the Tightknit code base and insulates Tightknit from accidental code changes that could affect users. Any changes involving the persistence layer (database) are performed locally when developing new code, where errors or bugs can be spotted before the change is deployed to users.
Code changes are managed and reviewed through Git pull requests. Every pull request is manually reviewed and approved by two developers before it can be merged. Automatic and integrated testing is also performed with each pull request, and all tests must pass before a code change can be merged.Developers are trained in evaluating code for security defects as part of code review, and automatic testing is employed to test against common security defects.
Security bugs represent key issues and should be resolved quickly to maintain the security, confidentiality, privacy, processing integrity, and availability of the Tightknit service. Tightknit has SLAs in place to enforce compliance with resolving security bugs within reasonable timelines.