Privacy policy

1. Who we are

Akeso is provided by:

Registered at the Amtsgericht München under HRB 253849. VAT ID: DE328163137. Managing directors: Kristi Kristo and Daniel Kazani. Legal notice: www.softup.co/en/impressum.

For any question about this policy or about your data, write to info@softup.co.

2. What this policy covers

This policy covers the Akeso service at akeso.softup.co: its public pages, the dashboard, the service's side of the widget, its GitHub App, and the runs and integrations it operates.

It does not cover:

• Softup's company website, softup.co, which has its own privacy policy at www.softup.co/en/datenschutz;
• the websites and apps of our customers that include the widget: their operators are responsible for them;
• GitHub, Google, Anthropic and Slack when you use them directly: they process data under their own terms.

3. Our two roles

We process personal data in two roles.

As controller (Art. 4(7) GDPR), we decide how and why data is processed for: accounts and sign-in, organizations, their members and invitations, the acceptance of our terms, audit logs, rate limiting, the security and technical logs of the service, and messages you send us.

As processor (Art. 28 GDPR), we process data on behalf of our customer, the business that uses Akeso, for the customer's content: its repositories and code, GitHub issues and comments, requests and attachments sent through the widget, error logs from its systems, the results and evidence of runs, and the settings and credentials it stores. For that content the customer is the controller. We process it only to provide the service, on the customer's instructions as given in the dashboard and in our terms of service.

A data processing agreement under Art. 28 GDPR is available on request at info@softup.co.

If you are a user of a customer's product, for example someone who sent a report through its widget, please contact that customer about your data first. Requests that reach us about a customer's content are passed on to that customer.

4. Accounts and sign-in

You sign in to the dashboard with Google. Only Softup's staff and people with an invitation get an account.

What we process

• From Google, at each sign-in: your email address, your name, whether Google has verified the address, and for a Google Workspace account the domain that manages it.
• In your account: your email address, your name, when the account was created and when you last signed in.
• In the service's own log of events: each sign-in and sign-out, and each change to an account, with the email address and the time.

Why, and on what legal basis

To let you sign in and stay signed in, to show your organization who its members are, and to know who had access to the service and when. The legal basis is Art. 6(1)(b) GDPR where you are our contracting party or act for one; otherwise Art. 6(1)(f) GDPR, our legitimate interest, which our customers share, in giving the people a customer invites access to the service and in keeping it secure.

You need a Google account for the address you were invited with; without one you cannot sign in. The address does not have to be a Gmail address.

5. Organizations, members and invitations

What we process

• The organization's name and short name (slug), its settings and its limits.
• Its members, each with their role and last sign-in.
• Invitations: the invited email address, the role, who created the invitation, when it expires and whether it was used. The invitation link itself is stored only as a digest. Akeso sends no email: whoever creates an invitation passes the link on.
• The version of the terms an owner accepted for the organization, when, and by whom.
• The organization's audit log: every change made in the organization, with who made it and when, including changes made by Softup's operators.

Why, and on what legal basis

To run the organization, to give each member the access their role allows, to show the organization's admins what changed, and to record that the terms were accepted. The legal basis is Art. 6(1)(b) GDPR, and Art. 6(1)(f) GDPR for the audit log and the record of acceptance: our legitimate interest, and our customers', in security and in being able to show who did what.

6. Your organization's content

We process this content as a processor, on behalf of the customer (section 3).

Code and runs

The customer installs our GitHub App on the GitHub repositories it chooses. Through it, the service reads the repositories of the customer's projects. It writes only to branches it creates (akeso/…), and to issues, comments, commit statuses and draft pull requests.

For each run, the repository is copied onto a machine started for that run alone, which is deleted when the run ends. By default this is an isolated machine in Softup's AWS account in Frankfurt, Germany. For a project the customer switches to GitHub Actions, it is a GitHub-hosted machine in the customer's own repository.

We store each run's record, log and result (the proposed change), and its evidence, such as screenshots. The run's log and its text evidence pass through redaction before they are stored; screenshots and videos are stored as they are.

GitHub issues

The service reads the issues and comments in those repositories, with their authors' GitHub user names, to turn issues into requests and to act on comments that start with @claude.

Error logs (optional)

If the customer connects AWS CloudWatch, the service reads events from the log groups the customer chooses, with a read-only AWS key the customer provides. Each event passes through a redactor before it is stored, sent to Claude or written to GitHub. The redactor replaces email addresses, phone numbers, IP addresses, tokens, keys, card numbers, IBANs and any patterns the customer adds. We keep redacted samples of each error and the analyses of new errors. Redaction can miss something: an analysis that sees personal data cannot be turned into an issue until someone has checked it.

Claude

The analyses of errors and the work of each run (reading the request and the code, changing the code, reviewing a pull request) use Claude, a model made by Anthropic. Every Claude call for a customer uses the customer's own Anthropic API key. So the content of those calls (code, the text of issues and requests, redacted log samples and whatever else a run needs for its work) goes to Anthropic under the customer's own agreement with Anthropic, and Anthropic charges the customer directly for that use. We check a new key with Anthropic before saving it.

Settings and credentials

Projects and their settings; environment profiles, which describe how to install, build, start and test the customer's product; the web addresses the widget may be used on; and the credentials the customer stores: Anthropic API keys, AWS keys for log intake, Slack webhook addresses and each project's widget secret. Credentials are stored encrypted.

Slack (optional)

If the customer sets a Slack webhook for a project, the service posts alerts about new errors to it: the project, a title, the severity, how often the error occurred and a link to the dashboard. Alerts never contain log text.

7. People who use the widget

A customer can add a Request a change button, the widget, to its own product, so that the product's users can report bugs and ask for changes. For this data we act as processor for that customer, which is responsible for informing its users.

What a request holds

Its kind (bug, feature or change), title, description and steps, the path of the page it was sent from, the browser it was sent with (its user agent), the product's release, and any screenshots or videos the user attaches. Each request becomes a GitHub issue in the customer's repository with this information, the attachments as links, and the identifier of whoever sent it (below).

Who sent it

• Anonymous use. The first time someone opens the widget, it gets a random identity token from the service and keeps it in the browser's local storage, so the person can see their own requests from that browser. We store the token only as a digest, together with a keyed digest of the IP address it was requested from, and any display name or id the customer's product passes along.
• Verified users. The customer's product can instead pass an id for the signed-in user, signed with the project's secret. We store that id with each request. Our documentation asks customers to use an opaque id, never an email address.

The widget never sends the product's cookies to the service.

Rate limits

To protect the service from abuse, we count calls per IP address in hourly windows. We store only keyed digests of addresses, never the addresses themselves; an IPv6 address is counted by its /64 network. This is our own processing as controller, on the basis of Art. 6(1)(f) GDPR: our legitimate interest in keeping the service available and secure.

8. Security, logs and messages

• The service's own log of events records sign-ins, sign-outs, changes to accounts, invitations to create an organization and the deletion of organizations, with who and when.
• Technical logs record the service's own events and errors. Error entries of the web server can include the IP address of the request that failed. They are kept on the server and rotated by size, so older entries are overwritten.
• We keep no access log of visits to the service's pages, and use no analytics.

The legal basis is Art. 6(1)(f) GDPR: our legitimate interest in keeping the service secure and stable, in detecting and investigating misuse, and in being able to show who did what. Where the law requires us to keep or disclose data, the basis is Art. 6(1)(c) GDPR.

When you write to us, we use your message and your contact details to answer it, on the basis of Art. 6(1)(b) GDPR where it concerns a contract, and Art. 6(1)(f) GDPR otherwise.

The contact form on our landing page collects your name, your email address and your description, to answer your request: on the basis of Art. 6(1)(b) GDPR where you ask about using the service, and Art. 6(1)(f) GDPR otherwise. The service stores them for up to 30 days and then deletes them, and emails them to Softup's mailbox through Resend (Resend, Inc., USA), which sends from its EU region under its data processing agreement and the European Commission's standard contractual clauses (section 10). To stop misuse it counts the messages sent from each IP address, by a keyed digest; it does not store the address with your message.

9. Who else processes data

We do not sell personal data. We share it only as described here.

Softup's staff who are operators of the service can open any organization, to run and support the service. Every change they make appears in that organization's audit log. Other Softup staff see only the organizations they are members of.

We disclose data to authorities only where the law requires us to.

10. Transfers outside the EU

We host the service and its data in the EU, in Frankfurt. AWS is a US company; for the service's data we use only its Frankfurt region.

Google, GitHub, Anthropic, Resend and Slack belong to companies based in the United States and can process data there. Each relies on its own safeguards for such transfers, such as the EU-U.S. Data Privacy Framework or the European Commission's standard contractual clauses, as set out in its terms; for Resend, its data processing agreement with those clauses. For content that GitHub, Anthropic and Slack process under the customer's own agreements with them, those agreements apply.

11. How long we keep data

When an organization is deleted

An owner can delete the organization in its settings. It is suspended at once and deleted 7 days later; during those days Softup can cancel the deletion if the customer asks. The service then removes the organization's projects, requests, runs, evidence and attachments, members, invitations, audit log, GitHub connections and Anthropic API keys. It keeps one record that the organization was deleted: its name and slug, when, who asked, and the GitHub accounts it was connected to. Copies in database backups are gone at the latest 37 days later.

Deleting an organization does not remove anything the service created in the customer's GitHub repositories, and it does not uninstall the GitHub App: the customer does that on GitHub.

When an account is deleted, its memberships, sessions and tokens go with it. The audit logs keep its email address as the author of the changes it made.

12. Cookies and similar storage

The dashboard uses two cookies, and the contact form one, each strictly necessary for the service you ask for. We use no analytics, advertising or tracking cookies and no third-party scripts, and the public pages, this one included, load nothing from other hosts.

The widget, on a customer's product, sets no cookies. It uses the browser's storage only once someone opens it:

• in local storage, the anonymous identity token (section 7), until the browser's storage is cleared. The token stops working after 180 days without use;
• in session storage, a random key that stops a request from being filed twice when it is sent again, until the service confirms the request or the tab is closed.

The legal basis for this storage is § 25(2) no. 2 TDDDG (the German Telecommunications Digital Services Data Protection Act): it is strictly necessary for a service you asked for. The customer that includes the widget in its product decides whether to use it, and informs its users.

13. How we protect data

• Encrypted connections. Every connection to the service uses HTTPS.
• Organizations kept apart. Each account sees only the organizations it is a member of; another organization's pages and data answer as if they did not exist. Roles limit what members, admins and owners can do.
• Sign-in. Only Google accounts with a verified email address can sign in. Sessions end after 12 hours, and their cookies are HttpOnly, Secure and SameSite.
• Credentials. API keys, AWS keys, Slack webhook addresses and widget secrets are encrypted with AES-256-GCM, with a key kept outside the database. The dashboard shows only the last characters of a key, and audit entries record that a credential changed, never its value. Session, invitation and identity tokens are stored only as digests, and IP addresses only as keyed digests.
• Isolated runs. On Softup's AWS, each run has its own new machine, which is deleted when the run ends; no two runs or organizations share one. It accepts no incoming connections, has no AWS permissions and an encrypted disk, and can reach only GitHub, the npm registry, Anthropic, the service and the hosts the customer lists. Its GitHub token can only read the one repository, for that run.
• Checked results. Only the service writes to GitHub, after checking what a run returned. It never merges and never deploys.
• Redaction. Error logs, run logs and text evidence pass through redaction before they are stored.
• Audit. Every change in an organization, including changes by Softup's operators, is recorded in its audit log, which its admins can read.
• Backups. The database is backed up every night to storage in Frankfurt.

14. Your rights

Under the GDPR you have the right to:

• get a copy of your personal data and information about how it is processed (Art. 15);
• have incorrect data corrected (Art. 16);
• have your data deleted (Art. 17), or its processing restricted (Art. 18);
• receive data you gave us in a structured, machine-readable format (Art. 20);
• object at any time, on grounds relating to your particular situation, to processing based on Art. 6(1)(f) GDPR (Art. 21).

To use these rights, write to info@softup.co. We may ask you to confirm your identity, and we answer within the time the GDPR sets, normally one month. For content we process on a customer's behalf, we pass your request to that customer and help it to answer.

We do not make decisions about you based solely on automated processing that have legal or similarly significant effects on you (Art. 22 GDPR).

15. Complaints

You can lodge a complaint with a data protection supervisory authority, in particular in the EU member state where you live or work, or where you believe an infringement took place. The authority responsible for us is:

www.lda.bayern.de

16. Changes to this policy

We update this policy when the service or the law changes. The date and version at the top of this page show which version you are reading. When a change matters for how we process data, we show the new version to the owners of every organization in the dashboard.