Trama Privacy Policy
This English version is a translation provided for convenience. The Portuguese text prevails. Read the Portuguese original
Version: 2026-10-28 · In force: from 28 October 2026
This Policy explains which personal data Trama processes, for what purpose, on what legal basis, with whom it is shared, how long it is kept and how you exercise your rights under Brazil's General Personal Data Protection Law (Law no. 13.709/2018, "LGPD") and the Civil Rights Framework for the Internet (Marco Civil da Internet, Law no. 12.965/2014).
1. Who we are and how to reach us
Trama is offered by Hallen Consultoria Tecnológica Ltda., CNPJ 45.106.125/0001-39, with its head office at Rua Juscelino Kubitscheck de Oliveira, 890, Jardim Boa Vista, Barra Mansa (RJ), CEP 27350-130 ("Hallen Tech" or "we").
Data Protection Officer (encarregado) for the processing of personal data: Eddwan Hallen da Silva · dpo@trama.sh
It is through this channel that you exercise your rights, ask questions about this Policy and talk to us about privacy.
2. How Trama is designed, because it decides almost everything here
Trama has two parts, and only one of them is ours.
| The Core, on the customer's machine | The Platform, with Hallen Tech | |
|---|---|---|
| Where it runs | On a server, VPS or computer that the customer administers | On Hallen Tech's own servers, in São Paulo (SP), Brazil |
| What it keeps | Card text, prompts, turn transcripts, conversations with the agents, attachments, working copies of the repositories (source code), tracker and repository credentials, licence and the deciders' public keys | Accounts, organisations, members, invitations, roles, sessions, billing, the register of each core, usage totals, budgets, alerts and the audit trail |
| Who decides about this data | The customer | Hallen Tech or the customer, as set out in section 3 |
| Who has access | The customer; Hallen Tech does not | Hallen Tech, to operate the service, and the suppliers in section 9 |
What the Platform never keeps: the text of the cards (the title only passes through it, section 5), the prompts, the transcripts, the conversations, the attachments, the source code, the diffs, the tracker, repository or AI provider credentials, the private key of whoever decides, or a copy of a core's database. An automatic check refuses the Platform's database schema if it gains a column to keep any of these things.
The AI talks directly to the provider, on the customer's account. The AI agent runs on the core's machine, authenticated with the customer's own account with the AI provider the customer chose (for example, Anthropic). The card text, the prompts and the code go from the customer's machine to the AI provider, without passing through Hallen Tech. That relationship is between the customer and the provider, under the provider's terms and privacy policy, including as to keeping that content or using it to train models.
3. Each party's role
- Hallen Tech is the controller of the account, access, security, access log, audit and billing data, of the website data, of the emails it sends and of data subject requests (sections 4.1 to 4.4, 7 and 8). It decides how this data is processed and is responsible for it.
- Hallen Tech is a processor, and processes the data on the customer's behalf and according to the customer's instructions, when it: relays the core's work to the screen (section 5); passes on incoming webhooks and sends outgoing ones (sections 5 and 6); and keeps the configuration and the work data that the organisation puts on the Platform (projects, clients, budgets, alerts, state of the cores, usage, section 4.5). The organisation also decides who joins it, with what role, which clients each person has access to and the budget of each. For this data, the organisation is the controller; Hallen Tech is the controller only of the identity and of the security of access.
- The customer is the controller of everything its core processes on its machine: cards, code, conversations and the data of the people who appear on its clients' boards. The choice of AI provider, tracker and repository is also the customer's. Hallen Tech has no access to this data and cannot delete it.
4. The data we process
4.1. Account, access and security
| Data | For what | Legal basis |
|---|---|---|
| Name, email, language and interface theme | Identify you, sign you in, communicate | Performance of a contract (art. 7, V). For a member invited by an organisation, also its legitimate interest and ours in giving the team access (art. 7, IX) |
| Sign-in with Google: the Google account identifier, the email, whether it is verified, and the name (we do not read the photo; Google's access token is used once and is not kept) | Sign in with Google | Performance of a contract |
| Sign-in with GitLab: the identifier and the email | Sign in with GitLab | Performance of a contract |
| Organisation SSO (OIDC or SAML): the identifier and the email that your organisation's identity provider reports | Sign in through the SSO your organisation has set up | Performance of a contract |
| Password: we keep only a hash (scrypt), never the password | Sign in with a password | Performance of a contract |
| Second factor: the TOTP seed, encrypted, and the recovery codes, only as a hash | Protect the account | Performance of a contract; legitimate interest in security (art. 7, IX) |
| Magic links, password resets and invitations: only the token's hash | Sign in and invite securely | Performance of a contract |
| Sessions: IP address, browser (user agent), when it started, when it was used and how you signed in | Keep you signed in, show and end sessions, investigate improper access | Performance of a contract; legitimate interest in security |
| Application access logs: IP address, date and time, with time zone | Comply with the mandatory 6-month retention and respond to court orders | Compliance with a legal obligation (art. 7, II; Marco Civil, art. 15), kept for 6 months under confidentiality, with restricted and recorded access (Decree no. 8.771/2016, art. 13) |
| Approximate location from the IP, computed locally with the DB-IP database (the IP is not sent to third parties) | Show where each session comes from | Legitimate interest in security |
| Profile photo, if you upload one: re-encoded, which removes the location and camera data | Show who you are to the members of your organisations | Consent (art. 7, I); you can remove it whenever you wish |
| Rate limiting: a hash of the address or of the person, from which the value cannot be recovered | Prevent the guessing of passwords, codes and invitations | Legitimate interest in security |
| Personal trail: second factor turned on, turned off or changed, password changed, sessions ended, with IP and browser | Investigate the compromise of an account | Legitimate interest in security |
4.2. Organisation and members
| Data | For what | Legal basis |
|---|---|---|
| Which organisations you belong to, with what role, since when and until when; which clients you are limited to | Give each person the right access | Performance of a contract; for the configuration made by the organisation, we process it as a processor (section 3) |
| Invitations: the invited email, who invited and the validity | Bring people into the organisation | Legitimate interest of the inviting organisation and ours (art. 7, IX) |
| Decider public key and member signing key, and which member each belongs to | Show who started or approved something (the decision is valid by the signature verified on the core's machine) | Performance of a contract; legitimate interest in security |
| Spending budget per person and spending per signing key per day | Apply the cost limits that your organisation has defined | We process it as the organisation's processor |
| Refused attempts to invite, promote, demote or remove members, with the IP | Detect abuse | Legitimate interest in security |
4.3. Audit
| Data | For what | Legal basis |
|---|---|---|
| Who requested each operation from a core, which operation, a hash of the parameters (never the parameters), the result, when, the IP and the browser. Reads are not audited | Prove what was done and by whom and settle disputes about irreversible acts | Legitimate interest; regular exercise of rights (art. 7, VI) |
4.4. Purchase and billing
| Data | For what | Legal basis |
|---|---|---|
| Email given at purchase, language, cores purchased, amount, payment method and the Stripe identifiers | Send the founding invitation and link it to the purchase | Preliminary procedures and performance of a contract (art. 7, V) |
| Subscription, periods, statements, charges, Stripe identifiers, payment events and the version of the Terms accepted | Bill, reconcile, prove payment and acceptance, comply with the tax obligation | Performance of a contract; compliance with a legal obligation (art. 7, II) |
| Card details | Pay by card | Do not reach Hallen Tech: they are typed into Stripe's environment. We keep only the identifiers that Stripe uses to charge the saved card |
| Boleto payer: CPF or CNPJ, name, email and address. Requested only when someone chooses boleto and kept encrypted (AES-256-GCM) in the organisation's billing profile for subsequent boletos; the owner or an administrator can edit or delete them | Stripe only issues a payable boleto with this data | Performance of a contract; when the payer is another person (for example, the company's finance department), legitimate interest in enabling the chosen payment |
| Data for the tax invoice (CNPJ, corporate name, address), when the customer provides it | Issue the service tax invoice | Compliance with a legal obligation |
| Bank details to refund a boleto, when you ask for a refund: account holder, CPF or CNPJ and the Pix key or the account, kept encrypted | Make the refund transfer | Compliance with a legal obligation (Consumer Protection Code, CDC, art. 49) and performance of a contract |
4.5. The cores and the organisation's work
In this section, Hallen Tech is the organisation's processor, except for the core register and the licence, which we use to license the service.
| Data | For what |
|---|---|
| Register of each core: identifier, fingerprint, version, platform, when it was seen, hash of the connection credential, licence validity | Know which machines belong to the organisation and issue and renew the licence |
| State of the machine reported by the core: number of CPUs, load, memory, health checks, turns in progress | Show the core's health in the panel and raise alerts |
| Usage of the AI provider subscription that the core reads on the machine: a status indicator and, when available, the percentage used of the 5-hour and 7-day windows | Show in the panel how much of the subscription is left |
| Usage totals per day and per project: turns, estimated cost, cards delivered, tokens. The project's name is text that the customer wrote itself | Show usage and apply the budgets |
| Projects and clients: name, type and address of the tracker | Organise the work in the panel |
| Budgets of the organisation and of the projects | Apply the limits that the organisation has defined |
| Alerts: that a condition occurred (core offline, consecutive failures, budget at 80%), about which core or turn, and from when to when | Warn the organisation |
This data is about machines and work, and not about people. It becomes personal when the customer is an individual or when the name of a project or of a client identifies someone. We recommend not using a person's name as the name of a project or of a client.
5. What passes through the Platform without staying
For the panel and the app to show a core's work, the Platform relays in real time, in memory only and without recording, what the core sends to the screen of whoever is connected: card titles, the progress and text of the turns and the lines of the conversations. Likewise, the Platform receives webhooks from GitHub, GitLab, Linear or another source configured by the customer and passes them on to the core, without recording the content: we keep only the event name, the delivery identifier and the result, for 30 days. The tracker and repository credentials typed in the browser cross the Platform encrypted to the core's key, and only the core can open them.
In this transit, Hallen Tech acts as the customer's processor.
6. Outgoing webhooks
The organisation can register addresses (including Slack ones) to receive notices of alerts and deliveries. The messages carry identifiers and fixed words, never the text of a card, a prompt, a diff, or the name of a branch or of an agent. The addresses and the secrets are kept encrypted. The delivery history is kept for 30 days, and the destination's response is not stored.
7. The trama.sh website
| Data | For what | Legal basis |
|---|---|---|
| Notification list: only the email, kept at Resend, when you sign up | Let you know when there is news about Trama | Consent (art. 7, I). Each notice carries a link to leave the list |
| Visit counting by PostHog, through the site's own domain, with no cookie, without storing anything on your device, with no profile and no session recording; it respects the Do Not Track and Global Privacy Control signals. For sign-ups, it counts the result, the language and the country, without the email. The visitor's IP address is not passed on to PostHog nor kept by it | Know how many visits the website receives | Legitimate interest (art. 7, IX) |
8. Emails we send
We send through Resend: magic links, password resets, invitations, the founding invitation, billing and late-payment notices, and notices about the account. Billing emails go to the organisation's owner. We do not send advertising to anyone who has not signed up to the notification list.
9. Who we share with
We do not sell personal data and we do not use it for advertising. We share it only with the suppliers we need to operate Trama:
| Supplier | For what | Data | Where |
|---|---|---|---|
| Stripe | Card and boleto payments | Buyer's email, card details (typed directly into Stripe), boleto payer's data, organisation name, amounts | Brazil and USA |
| Resend | Sending emails and the website's notification list | Email, name where there is one, content of the email | Sending through the São Paulo region (Brazil); company and other services in the USA |
| Cloudflare | DNS, hosting of the trama.sh website and of the core downloads (R2); storage of the Platform's encrypted backups (R2, US jurisdiction, 30 days) | IP address and technical data of whoever visits the website or downloads the core; the encrypted backups, which Cloudflare cannot open | Global and USA |
| PostHog | Counting website visits | Technical data of the visit and country, with no cookie and no email | USA |
| ViaCEP | Filling in the address from the CEP, in the purchase on the website | Only the CEP typed, sent by your browser | Brazil |
Sign-in providers. When you choose to sign in with Google or GitLab (both in the USA), or when your organisation configures an SSO (OIDC or SAML) or its own GitLab instance, that provider receives the sign-in request and returns to us what section 4.1 describes. It processes your data as an independent controller, under its own privacy policy.
Stripe as an independent controller. Besides processing the payment for us, Stripe processes data as a controller for its own purposes, such as fraud prevention and the legal obligations of a payment institution, under its own privacy policy. Deleting the billing profile on the Platform does not delete what Stripe has already received in a boleto or in a payment.
Webhook destinations. They receive what section 6 describes, because the organisation registered them.
The customer's AI provider, tracker and repository do not receive data from Hallen Tech: they are contracted and accessed by the customer itself, from its own machine.
We also share data when the law or a competent authority requires it, or to exercise rights in judicial, administrative or arbitral proceedings. Access logs are provided only by court order (Marco Civil, art. 10).
10. International transfer
The Platform's data stays in Brazil. The suppliers in section 9 process part of it outside Brazil, mainly in the United States. These transfers rely on:
- the standard contractual clauses approved by the ANPD (LGPD, art. 33, II, "b"; Res. CD/ANPD no. 19/2024), incorporated into the contracts with the suppliers; and
- where the transfer is necessary to perform the contract at your request, as in card payment or in the sign-in through Google or GitLab that you chose, art. 33, IX, of the LGPD.
You may ask the DPO for the full text of the clauses used.
When the customer's core sends cards, prompts and code to the AI provider (for example, Anthropic, in the USA), that transfer is made by the customer, as controller, and not by Hallen Tech.
11. How long we keep data
Each Platform table has a period declared in the database schema itself. The daily clean-up routines apply these periods.
| Data | Period |
|---|---|
| Account (name, email) and sign-in methods | While there is any active membership of an organisation; 12 months after the last one |
| Session | Deleted on sign-out; expires in 30 days, or in 14 days without use |
| Application access logs | 6 months (Marco Civil, art. 15) |
| Magic link, password reset | Replaced by the next one; 24 hours |
| Member invitation | 30 days from issue, whether accepted or not |
| Founding invitation | 12 months after it is used, revoked or expired |
| Purchase made on the website | 12 months after the organisation is created; a purchase that never became an organisation is kept until it is resolved (invitation or refund) |
| Profile photo | Until you change or remove it; deleted when the account is deleted |
| Membership of an organisation | 5 years after leaving, with the identification replaced by an anonymous marker when the person is erased |
| Audit | Identifies the person for 5 years (signed decisions, billing, changes to who can decide and to SSO) or for 12 months (other operations). After that, or when the person is erased, the record is kept without identification: the anonymous marker takes the place of the person, and the IP and the browser are deleted |
| Personal security trail | 24 months, then anonymised |
| Refused attempts | 12 months, then deleted |
| Rate limiting | About 10 minutes |
| Data subject request | 5 years after it is closed, keeping the requester's email, as proof that we answered |
| Boleto payer | While the organisation exists, or until the owner or an administrator deletes it |
| Bank details for refunds | Deleted when the transfer is recorded |
| Statements and charges | For the period set by tax and accounting legislation: at least 5 years counted from 1 January of the year following payment and, if there is a dispute, until it ends |
| Core register | 90 days after the last contact |
| Usage totals | 24 months per day, then summed per month and kept without personal data |
| Alerts | 12 months after they are closed |
| Webhook history (incoming and outgoing) | 30 days |
| Platform backups | 30 days, encrypted |
| Website notification list | Until you leave the list |
Organisations without a subscription continue to exist, with their data, until the owner requests closure (section 13).
The core's data stays on the customer's machine for the period the customer configures. By default, the core deletes nothing on its own: the customer chooses the periods (for example, for transcripts and conversations). Hallen Tech cannot guarantee or enforce any period on data that is on someone else's machine.
12. Security and incidents
We adopt technical and administrative measures to protect the data (LGPD, art. 46), among them:
- Signed decisions: operations that change what a core may do require the signature of a device enrolled on the core's machine. Each signature is valid once, for five minutes. Hallen Tech cannot enrol a decider or approve on the customer's behalf.
- Secrets kept only as a hash: passwords (scrypt), invitation, magic-link and reset tokens, each core's connection credential.
- Encrypted data: boleto payer data, bank details for refunds, second-factor seed, SSO and webhook secrets.
- Customer credentials encrypted to the core, which cross the Platform without it being able to read them.
- Backups encrypted before they leave the server; the key that opens them is held by Hallen Tech, outside the server and outside the account where the backups are stored. Production backups are not restored in a test environment, except in restore drills, in an isolated environment deleted immediately afterwards.
- Screening against manipulation of the agent (prompt injection): the text of a card is examined on the core before it becomes an instruction for the agent, and a suspicious card is held until a person decides. Only the rule's identifiers reach the Platform, never the passage.
- The agent's fence: on every turn, the core forbids the agent's reading tools from opening credentials, the database and the backups.
- Rate limiting, second factor, sessions with an expiry, logs without free text, security headers in the browser.
- Restricted internal access for the Hallen Tech people who need it to operate the service, under a duty of confidentiality.
No measure is infallible. If there is a security incident that may entail relevant risk or harm to people, we will notify the ANPD and the affected people within the time and in the manner set by the LGPD (art. 48) and Res. CD/ANPD no. 15/2024. If the incident affects data we process as processor, we will notify the customer organisation so that it can make the notifications that fall to it.
13. Your rights
Under the LGPD (arts. 18 to 20), you may ask, free of charge, for:
- confirmation that we process your data and access to it;
- correction of incomplete, inaccurate or outdated data;
- anonymisation, blocking or deletion of unnecessary or excessive data, or data processed in breach of the law;
- portability;
- deletion of the data processed with your consent, and withdrawal of consent;
- information about whom we share your data with and about the possibility of not consenting, with the consequences;
- objection to processing carried out on another legal basis, where the law is not complied with;
- review of decisions taken solely on the basis of automated processing (section 16).
How to ask:
- From the panel, in Settings → Profile: export your data as a JSON file and ask for the deletion of the account. The export includes the account, the memberships, the audit trail that mentions you, the photo, the personal security trail and, if you manage billing, the masked billing profile. It can gather all your organisations into a single file. The request identifies you by your session, so nobody can make it about someone else.
- By email, to the DPO (section 1).
Period: we answer within 15 (fifteen) days. When we cannot comply, we say why.
How deletion works: when you ask, access ends at once, on every device: the sessions are deleted and the membership is suspended. The data is deleted 30 days later, by a daily routine; the wait exists so that a request made by mistake can still be undone. Some information is not deleted, and we say which:
- the audit trail continues to exist without identifying you, so that a dispute about an irreversible act can be settled;
- statements and charges are kept for the legal period;
- access logs are kept for the 6 months of the Marco Civil;
- the record of your request, with the email you used, is kept for 5 years.
The sole owner of an organisation that has other members must transfer ownership before asking for deletion. The closure of an entire organisation is requested by the owner through the contact indicated in the Terms of Use.
If you appear on a card on the board of a Trama customer, or in other data kept on a customer's core: we do not have that data. We acknowledge receipt of your request, forward it to the customer it concerns within 5 business days and record the forwarding. The customer is obliged, by contract with us, to answer you within the legal period. The same applies to the data we process as an organisation's processor (section 3): the request is forwarded to it, and we help as far as is within our reach.
You may also complain to the National Data Protection Authority (ANPD) and to consumer protection bodies.
14. Cookies and browser storage
- Panel: we use a single, strictly necessary cookie, which ties a sign-in attempt to the browser that started it and lasts only for that attempt. The session and your display preferences (theme, chosen projects, first steps) are kept in the browser's local storage, and are removed when you sign out of the account or clear the browser's data. All of them are necessary for the panel to work. The panel does not use advertising or analytics cookies, nor any third-party analytics tool.
- trama.sh website: no cookies and nothing stored on your device.
15. Minors
Trama is not intended for people under 18, and we do not knowingly collect data from children or adolescents. If we learn that an account belongs to a minor, it will be closed.
16. Automated decisions
Hallen Tech does not profile people or take decisions based on profiling. Some contract rules are applied automatically, with criteria described in the Terms of Use: the subscription becomes past due when a period is not paid by its due date; the core's licence stops being renewed 14 days after the due date of the oldest unpaid period; and the core refuses new turns 14 days after the licence expires. You may ask for a review of any of these decisions through the DPO channel (LGPD, art. 20).
The screening against manipulation of the agent runs on the customer's core, decides about the text of a card and not about a person, and the one who configures it and is responsible for it is the customer.
17. Artificial intelligence and your data
- Hallen Tech does not use Platform data to train AI models.
- The content of the work (cards, code, conversations) does not reach Hallen Tech: it goes from the customer's machine to the AI provider that the customer chose.
- Whether the AI provider keeps that content or uses it to train models depends on the customer's plan and settings with the provider. We recommend that the customer check these settings.
18. Changes to this Policy
We may change this Policy. Relevant changes are announced by email and in the panel 30 days in advance, and the version and the effective date at the top are updated. Previous versions remain available on the website.
19. Contact
Hallen Consultoria Tecnológica Ltda. · CNPJ 45.106.125/0001-39 · Rua Juscelino Kubitscheck de Oliveira, 890, Jardim Boa Vista, Barra Mansa (RJ), CEP 27350-130
DPO: Eddwan Hallen da Silva · dpo@trama.sh
The approximate IP location uses data from IP geolocation by DB-IP (https://db-ip.com), under the Creative Commons Attribution 4.0 licence.