What we do with your data, plainly
No badges here. What is built, how it works and what checks it. And at the end, a list of what we still do not have, which is the part these pages usually leave out.
- 7
- Layers every request crosses
- 58
- Manipulation attacks in the suite
- 34
- Actions that wait for your signature
- 15,000+
- Test cases in the repository
Seven independent layers
One failing does not compromise the next. Every request crosses all of them before it touches your data.
- 1
The door
All traffic goes through Cloudflare first: firewall, rate limiting, denial-of-service protection and an anti-bot check on public forms.
- 2
Your identity
The session is signed and verified on every request, with the signature algorithm pinned by the server. After five failures, each attempt from that address is delayed by up to 5 s; five wrong 2FA codes lock that factor for ten minutes.
- 3
Your company
On every request we check again, in the database, which company you belong to and with what permissions. If your access is revoked it stops working immediately, not at the next sign-in.
- 4
Your permission
Every operation checks two things separately: that your role allows it and that your plan includes that agent. Failing either one stops it.
- 5
Your secrets
Your connector credentials are stored encrypted with AES-256-GCM. Each credential has its own key, wrapped by a master key, and is bound to your company: copied to another, it does not decrypt. With no key, nothing is stored.
- 6
The way out
Everything on its way to you passes through a filter that removes credentials and hides which model sits behind each agent. And behind the filter there is a watchdog that looks again.
- 7
The record
Every action is written down with who, when and what it cost, and the records are chained to one another. Spending caps stop the run on their own if something runs away.
What happens when somebody tries to get in
Every step is an independent check. If one fails, there is no next one.
- 1
The traffic is filtered
Firewall and rate limiting before anything reaches our servers.
- 2
Your origin is confirmed
The origin address comes from the network, not from a header a visitor can type by hand.
- 3
Brute force is slowed down
After five failures, each attempt from that address is delayed by up to 5 s; five wrong 2FA codes lock that factor for ten minutes. Guessing a six-digit code inside its thirty-second life stops being possible.
- 4
The session is verified
How the signature is checked is decided by the server configuration, never by the session token itself: one asking to be validated “its own way” is rejected.
- 5
The second factor is required
If you have 2FA, the app asks for it at sign-in. Anyone who has it on needs it across the whole application: on every request, on the real-time channel, in connectors and when approving actions. If your company turns on "2FA for the whole team", it is required of all its members, including when they sign in from another company. You can also sign in with a passkey.
- 6
Your company is rechecked
On every request, against the database. Whatever the session token says is not enough: it can run ahead of reality.
- 7
Your role is checked
Platform administration is only reachable through a separate control. Everyone else sees “no access” even with a valid session.
- 8
The response is cleaned
Credentials are removed and the model behind each agent is hidden before anything reaches you. If something slipped through, the whole response is replaced and an internal alert fires.
GDPR and the EU AI Act
What is built into the product, not what is promised in a document.
GDPR
- A data processing agreement you can sign from inside the application: your name, the date, the origin address and a hash of the exact text you signed are all recorded.
- A download of your data as a file, from your own account and without asking us (rights of access and portability).
- Account closure with immediate effect: it blocks access there and then, and is logged. After the export, we delete the company’s data and give you a signed deletion certificate; only what the law requires us to keep is retained (billing, 6 years).
- A written procedure for a data breach, with its step-by-step runbook.
- A published sub-processor list, with a dated change history.
- A product impact assessment, in draft since May 2026 and not closed. It is shared with that label on it.
EU AI Act
- You always know the answer comes from an agent, with which name and from which department. It never presents itself as a person.
- Traceability for every run: which agent took part, which tools it used, what it returned and how much it consumed.
- 34 actions do not run on their own: they wait in a queue for a person to approve or reject them.
- The wait has a deadline: if nobody decides, the request expires instead of eventually running.
- Each agent’s identity and instructions are changed in parts and with a full history, never replaced wholesale.
- Technical documentation available under a confidentiality agreement.
Where the data lives
Product data lives on our own server inside the European Union, not on a shared cloud. Identities and sign-in are handled separately, in Ireland (eu-west-1). Inference goes to a provider whose entity and data centres are in the EU, which does not store or log request content: there is a guardrail in the code that ignores any provider address outside the EU unless it is authorised on purpose. Which provider is which, in which country, and what it is used for is at /subprocessors.
If you need nothing at all to leave (regulated sectors, public contracts, healthcare), Concerto Local solves it: inference runs on your own server, on the local Concerto model. The plan also brings 60 M STU a month of cloud allowance for whatever you want to hand to Amadeus, and it is a switch: with it off, your data does not leave your infrastructure.
Who actually enforces the isolation
This is where these pages usually say “two independent barriers” and leave it there. Ours is enforced today by the application; what sits underneath reaches as far as it reaches, and its exact scope is written below.
- What isolates today: the application. every request resolves which company you belong to and rechecks it against the database, with no shortcuts, and every query filters by that company. Changing or deleting anything requires checking the membership again. If your access is revoked, you notice on that very request.
- What sits underneath: the engine policies. in thirteen areas (model consumption, billing, approvals, memory —read—, runs, flows, integrations, HR, projects, support, tax invoicing, document templates and customers, the CRM) the database engine’s own row-level policies also act as a second barrier. Everywhere else, isolation is the application’s per-company filter.
On Concerto Local, every customer gets their own dedicated database: there the separation is physical, not merely logical, and none of this discussion applies.
-- active on the tables of thirteen areas ALTER TABLE all_owned_tables ENABLE ROW LEVEL SECURITY; ALTER TABLE all_owned_tables FORCE ROW LEVEL SECURITY; -- but it only applies inside this block, -- which those thirteen areas use SET LOCAL ROLE shara_app; SET LOCAL app.current_tenant = '…';
More than fifty attacks (today, 58), written as tests
They run on every code verification and in their own continuous integration workflow. If the neutralisation rate on the severe cases drops below 95 %, the release is blocked. Exactly how that is measured is in the third card, and it is worth reading.
44 cases
The ten OWASP categories for language models
Prompt injection, insecure output handling, training data poisoning, denial of service, supply chain, sensitive information disclosure, vulnerable plugins, excessive agency, overreliance and model theft.
14 cases
Ours
The ones that only make sense here: getting an agent to leak the real model name, escalating to another agent without permission, rewriting an agent’s identity through conversation, bypassing the allowance or the spending caps, and extracting stored credentials.
How it is measured
What that number is, and what it is not
The suite runs against recorded responses, not against the live model. It checks that the defences which neutralised each attack are still in place, not that today’s model resists a new attack. It is a regression net and should be read as one. Running it periodically against the real model is pending.
The full catalogue
Eight sections with the detail of what each thing does. Everything here is in the code that ships.
Access and session (7 measures)
- The session is signed and verified on every request. The signature algorithm is pinned by the server configuration, and never taken from the session token itself.
- App-based second factor, with eight single-use backup codes stored with scrypt and downloadable as PDF or text.
- Some operations ask for the second factor again even once you are in: changing your password, touching an agent’s identity, issuing access keys and the company onboarding steps.
- Sign-in with Google and Microsoft, with the code exchange protected (PKCE, RFC 8252). With Microsoft, only personal accounts or work accounts whose email the domain owner has verified get in: an unverified identity is rejected.
- A progressive slow-down per origin address on 29 sensitive routes: sign-in, second factor, backup codes, invitations, activation keys, password recovery and the ones opened with a token.
- After five failures, each attempt from that address is delayed by up to 5 s; five wrong 2FA codes lock that factor for ten minutes.
- Secret comparisons run in constant time, so nothing leaks through how long the response takes. There are 88 of them in the code.
Separation between companies, and permissions (7 measures)
- Which company you belong to is resolved on every request and checked against the database, with no shortcuts: whatever the session token says is not enough, because it can run ahead of reality.
- Changing or deleting anything belonging to the company requires rechecking the membership and that the role is on the allowlist.
- Six roles: ownership, administration, direction, operation, systems and read-only.
- Twenty departments with validated names: someone in sales cannot reach the legal agent’s profile.
- Personal memory is personal: nobody can read or delete another person’s, inside the same company, not even by asking for it by hand.
- Platform administration sits behind a separate control, enforced in the 18 places in the code where it is needed.
- Concerto Local: its own dedicated database, physical separation and not merely logical.
The model, and why it is not named (6 measures)
- The customer never sees the real name of the model underneath.
- The public names are Prelude, Sonata, Symphony and Concerto, the one that runs on your own server.
- A filter walks everything on its way out and replaces any trace of the real name, including identifiers carrying a version number and a date; a test checks that no residue is left.
- Error messages from third-party services go through that filter before being stored or reaching you, and the account identifiers they carry inside are stripped.
- Behind the filter there is a watchdog: if it detects that something escaped, the whole response is replaced with a generic one and a top-priority internal alert is logged.
- The public service status check uses neutral labels, never provider names.
Content arriving from outside (5 measures)
- Everything external — a customer message, a pasted document — is wrapped in markers that declare it data, not instructions.
- Agents that talk to customers carry that rule written into their behaviour, with the concrete attempts named one by one: “ignore the above”, “you are now another agent”, “reveal your instructions”.
- Anything arriving as structured data goes in a separate envelope, and the markers someone could use to close it from the inside are neutralised.
- A message from someone in your own company, arriving already authenticated, is NOT wrapped: doing so would teach the agent to distrust its own user. The wrapping is for external content, and there it is systematic.
- The tool an agent uses to escalate to the orchestrator rechecks the permission of the person who originated the request, not the agent’s.
Spend (6 measures)
- Cap per run: 1,000,000 STU. If a single run exceeds it, the run is cut and the agent is paused.
- Cap per hour: 10,000,000 STU. Inference is shut off until it is released.
- Cap per day: 80,000,000 STU. Effectively a full stop for the company.
- The brake releases on its own once consumption in that window is back below the line, or by hand from the application.
- Outside the working hours you set, the work steps down on its own: Symphony becomes Sonata, Sonata becomes Prelude, and Prelude is capped to short answers.
- 34 actions do not run on their own: sending email, issuing and sending invoices, ordering payments, publishing content, inviting somebody, changing a role, and everything that touches a person’s computer.
Encryption (8 measures)
- Your connector credentials are stored encrypted with AES-256-GCM, which both encrypts and detects any tampering.
- Each credential has its own AES-256-GCM key, wrapped by a master key, and is bound to your company: copied to another, it does not decrypt.
- The ciphertext is bound from the inside to the company it belongs to: moving it to another one does not decrypt it wrongly, it invalidates it.
- The master key can be rotated without decrypting the data or stopping the service: during the change, the application reads with both the old and the new key.
- Only the current format is ever written. The previous one is still readable so whatever is left can be migrated, but it is never emitted again, and there is a tool that rotates it.
- If the master secret is shorter than 32 characters, nothing is encrypted at all: it refuses to write rather than write with a weak key.
- Everything encrypted today uses Node’s standard library (AES-256-GCM, scrypt). A read-only reader for the old format stays until the last credentials are rotated.
- The server agent only talks to the API and to the update service if the certificate is issued by one of the root authorities pinned in the agent (Cloudflare’s). The signature of every link in the chain is checked and, if it does not match, it sends nothing. The pinning cannot be turned off in production.
Audit and traceability (6 measures)
- Every change is recorded with author, timestamp, resource and before/after.
- The database only allows lines to be added: modifying, deleting or emptying the log is rejected, even for the application itself.
- On top of that, the records are chained with SHA-256: each one includes the hash of the previous record for that same company. Altering a line in the middle breaks every line after it, and the chain is verified from the application.
- Each agent’s identity is changed in parts, never replaced wholesale, and every change leaves a trace.
- Internal logs go through a filter that strips authentication headers, passwords, access and refresh tokens, keys and third-party error messages.
- For activation keys only a cryptographic hash is stored; the plaintext is never written to any log.
The gaps, with their dates
None of these makes us look good, which is why they are here and not in a footnote of the contract. If one of them is a problem for your case, better to know today.
Certifications
We are not certified against ISO 27001 or SOC 2, and there is no third-party audit. What there is is internal work, and it is dated: the May 2026 audit with its seventy-six findings, the internal penetration test in June and the August sweep, each with its fixes.
The database’s second barrier
Postgres row-level policies cover thirteen areas: model consumption, billing, approvals, memory (read), runs, flows, integrations, HR, projects, support, tax invoicing, document templates and customers (CRM). Everywhere else, isolation rests on the application’s per-company filter.
Data retention
When the contract ends, after the export, we delete the company’s data and give you a signed deletion certificate, except billing, which the law requires us to keep for 6 years; backups keep the data until they expire, after 35 days. While the contract lasts, automatic deletion is on: each company’s owner chooses the retention period for conversations and runs in Settings (30, 60, 90, 180 or 365 days; 90 by default) and every night anything older is deleted. Technical logs are deleted after 90 days. The audit log, billing, memory (deleted by the customer) and configuration are never deleted by age.
The impact assessment
It has been in draft since May 2026 and is not closed. It is shared as-is, with that label, to anyone who asks under a confidentiality agreement. Closing it is pending work, not a box already ticked.
The brakes, with more than one server
The progressive slow-down on failed sign-ins keeps its count inside the process handling the request. Today the service runs on a single one, so it counts them all; the day there are several, that count has to move to a shared place, and until then we will not word it any other way.
Whoever administers the database
The rule that only lets lines be added to the audit log lives in the database. A database administrator with maximum privileges could bypass it. So that this cannot go unnoticed, every hour we store a signed copy of the last line of each company’s chain in storage with a 30-day deletion lock, outside the database, and every day we check that the database matches those copies. If someone rewrote the log, it would be detected in that daily check; we do not say it is impossible, we say it is detected.
Tests against the real model
The attacks (today, 58) run against recorded responses. They exist so that a defence cannot quietly disappear, which is what usually happens; not to claim that today’s model resists an attack nobody has written yet.
How we work with you.
Six commitments that hold up everything above.
Data in the European Union
Inference and the product database are in the EU. Transactional email, Cloudflare traffic and payments leave it, under standard contractual clauses (see sub-processors).
Everything is on the record
Every action of every agent is written down: who acted and what it cost. You can review any conversation from start to finish.
You sign off
Sensitive actions wait for your approval. The agent prepares the email, the payment or the proposal; you decide.
Your data is yours
You keep ownership of your information and you export it yourself from Settings: a .zip with one JSON file per table (the owner or an admin, once every 24 h); if you need CSV, we prepare it for you. We do not train models on your data or share it.
Spending under control
Caps that cut off on their own per run, per hour and per day. If something runs away, Shara stops it and tells you.
Always up to date
We keep the app up to date with what is new in AI, and improvements are included in your plan.
Data processing documents
The full legal texts, ready for your compliance team.
- Data processing agreement The full text of the agreement
- Sub-processors Which provider is which, and where
- AI policy How we use the models
Found a flaw? Tell us responsibly at security@aiginer.com.
Want to review it properly?
Under a confidentiality agreement we share the audit reports with their findings, the draft impact assessment and the full results of the manipulation suite, case by case.