Canonical page: https://tellenze.com/legal/security

# Security measures

Document version

Version: 2026-10-10.draft-1

The application controls behind workspace access, private files and sensitive records, plus the operational evidence needed for a service agreement.

Good security combines software controls with careful day-to-day operation. This draft explains the controls found in the current Tellenze implementation and the operational details that still need confirmation.

This is a review summary, not a completed production security audit, certification or service-level promise. A customer's agreed measures must be recorded with its data processing agreement.

## 1. What these measures cover

At a glance: Assess the service and your intended use together.

The application controls described here concern Tellenze workspace processing and selected central platform records. They do not show how every deployed server, network account, backup or external provider is operated. Those details need current evidence from the service owner.

The appropriate measures depend on the information, the purpose and the possible harm to people. An ordinary work-planning workspace has different needs from a service handling medical records or important decisions about individuals. Agree any sensitive or high-risk use before putting that information in Tellenze.

This page is a starting point for Annex B of the Data processing agreement. The agreed version and customer-specific measures should be kept with that agreement.

## 2. Workspace and member access

At a glance: The application checks the workspace and the current person's permissions.

The multi-workspace design selects the workspace from its registered address and applies a workspace database boundary. It also separates the workspace's cache, authentication context and background-job context. The database boundary rejects a workspace connection that shares the central platform database.

Access to work, documents, forms and other resources is checked through the relevant permissions. Being linked to another workspace or knowing a resource identifier does not grant access to that resource. Connected apps have grants that are checked together with the current owner's access.

Production browser-session settings use host-only cookies with the secure and HttpOnly protections and SameSite=Lax. Workspace sessions have workspace-specific cookie names. These settings help separate browser sessions; they do not replace the checks for each requested resource.

The operator portal has a separate authentication boundary. Operational access still needs an agreed purpose, appropriate authorisation and review of actual personnel and infrastructure access.

## 3. Private files and upload checks

At a glance: Uploads are checked and workspace file access is controlled.

The attachment flow checks allowed file types, file sizes and upload allowances, and requires a conclusive clean malware-scan result before storing a new file. It writes attachments with private visibility. A clean scan reduces a known risk; it cannot prove that a file is harmless in every use.

New workspace files use a path tied to the workspace's fixed identifier. Private-storage checks reject paths belonging to another workspace, and legacy unscoped files are restricted to the original installation.

Downloads and previews require access to the source record, such as the task, document, form response or Looper conversation. The attachment must also be eligible for download. Preview responses use restrictive content-security and content-type handling.

Private visibility does not establish disk encryption, backup protection or the identity and country of the storage operator. The production storage contract, configuration and operational access must be confirmed separately.

## 4. Sensitive records and credentials

At a glance: Selected fields are encrypted; do not assume every record is encrypted in the same way.

The application encrypts selected sensitive fields at the application layer. Examples include integration and email credentials, Looper conversation titles and message content, tool arguments and results, and private email draft content. Central website-request contact data and notification addresses also use encrypted fields.

Encryption is not applied to every field in the database. Work titles, ordinary collaborative content, identifiers and other operational fields can have different protection. This summary therefore makes no claim that all data is encrypted at rest or that the service provides end-to-end encryption.

The service can decrypt protected fields to perform authorised actions, such as sending a reviewed email or building an AI request. The resulting content is then subject to the receiving provider's processing. Protecting a stored field does not prevent every authorised disclosure.

API credentials are used on the server, and secret credential fields are hidden from normal model output. The production design separates model credentials into the Looper worker role. Key custody, credential rotation, recovery of encryption keys and access to runtime secrets still need operational confirmation for the actual deployment.

## 5. Connected apps and reviewed actions

At a glance: Permissions and review controls help limit what a connection can do.

Customer apps and agents act through granted access. The application intersects those grants with the responsible member's current permissions. Revocation or loss of access can stop future authorised calls; it does not remove copies a connected provider has already received.

The main Looper chat proposes supported changes for approval and rechecks permissions when applying them. AI email preparation creates a draft; sending requires a separate review and Send action. Current connection and content versions are checked so an old draft cannot silently reuse changed access or instructions.

Delivery records distinguish accepted, rejected and uncertain outcomes. An uncertain send must be checked before a new attempt, and provider acceptance does not prove that a recipient's inbox received the message.

These controls help prevent mistaken actions. They do not replace customer review of recipients, provider agreements, sensitive content or the scope of app and automation permissions.

## 6. AI requests

At a glance: AI can receive authorised content, and technical minimisation has limits.

Built-in AI requests can include the member's instructions, selected authorised work context, recent conversation history, tool-read results and images or PDF files attached to the current request. The request builder asks the model API not to store the response for later retrieval by setting store to false.

The main Looper chat also replaces matching email-address text before sending the payload. This is a limited text rule, not an anonymisation process. Other identifying information can remain, and encoded images or PDFs are not scrubbed by that rule.

Provider security logs, retention exceptions, regional processing and other account controls are separate from the request setting. They must be checked against the actual provider agreement and account. The AI and connected agents notice explains the relevant data flow and customer choices.

## 7. Public tools and separate statistics

At a glance: Temporary room content and durable usage observations are different records.

Public planning poker, retrospective and prioritisation rooms are separate from private workspaces. Their participation and sharing rules need a separate assessment. Avoid sensitive or identifying writing in a guest room, even where a feature uses anonymous display or voting.

Their durable usage snapshots are designed to contain counts, times and grouped observations with independent random analytics identifiers. The defined analytics fields exclude participant names and identifiers, invitation codes, IP addresses, user-agent strings, written room content and individual ballots.

The temporary room still needs data to run the tool. Web-server, network, security and backup records are separate from the reduced analytics snapshot. Excluding information from the snapshot is not a whole-service promise of untraceable participation or complete anonymity.

## 8. Operational measures to confirm

At a glance: The service owner must provide evidence beyond the application design.

The following areas remain part of the security review. They must be confirmed for the actual service before they are treated as agreed measures. A deployment script, policy target or configurable feature does not prove that a process is active or effective.

| Area | Evidence needed |
| --- | --- |
| Personnel and support | Who can access customer data, their confidentiality duties, support approval, access reviews and removal when access is no longer needed. |
| Hosting and network | Providers and countries, deployed transport settings, network restrictions, administrator account protection and private-file access configuration. |
| Monitoring and maintenance | Active monitoring and alert response, log content and retention, dependency and vulnerability review, and security testing relevant to the service. |
| Backups and restoration | Actual protected copies of databases and files, backup locations and access, encryption-key recovery, restoration test results and any agreed recovery objectives. |
| Incident handling | A working escalation route, responsible people, investigation and evidence handling, customer notification and follow-up practice. |
| Retention and deletion | Active-system and provider schedules, backup expiry, lawful holds, deletion confirmation and reapplication of deletions after restoration. |
| Provider oversight | Executed processing terms, provider-role assessment, relevant assurances, transfer arrangements and a complete provider schedule. |

## 9. Your part in protecting the workspace

At a glance: Use access and sharing choices with care.

Keep member, agent and connected-app access limited to the work each needs. Review access when people leave or change roles. Protect accounts and credentials, review public sharing and published material, and check recipients before sending information.

Use only the personal information needed for the task. Do not place passwords or secret keys in work content, attachments or AI messages. Agree sensitive processing and any extra measures before starting it.

Your organisation must assess whether the service and agreed measures fit its risk and legal duties. The presence of security controls does not make every use lawful or suitable.

## 10. Security contact and assurances

At a glance: Ask for current evidence and report a concern without sharing unnecessary data.

Contact general@tellenze.com for the security review or to report a concern. Include enough information to identify the affected feature or workspace, while avoiding passwords, secret keys or unnecessary personal data. Customer-specific incident contacts belong in the agreed DPA.

This draft does not claim an independent certification, completed penetration test, guaranteed uptime, fixed incident-response period or agreed recovery time. Any such assurance needs a defined scope, current supporting evidence and an agreed contract.

## Sources used for this document

- [GDPR Article 32: security appropriate to risk](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng)
- [Official OpenAI documentation: API data controls and retention limits](https://developers.openai.com/api/docs/guides/your-data)

Contact: general@tellenze.com