What we do with your data, mechanism by mechanism
No badges on this page. What is built, how it works and what checks it. And it ends with a list of what we still do not have, which is the part these pages usually leave out.
- 7
- Layers every request crosses
- 54
- Manipulation attacks in the suite
- 34
- Actions that wait for your signature
- 15,000+
- Test cases in the repository
Defence in layers
Seven independent layers
One failing does not compromise the next. Every request crosses all of them before it touches your data.
- 01
The door
All traffic goes through Cloudflare first: firewall, rate limiting, denial-of-service protection and an anti-bot check on public forms.
- 02
Your identity
The session is signed and verified on every request, with the signature algorithm pinned by the server. After five failed attempts the response slows down, and then the account locks for ten minutes.
- 03
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.
- 04
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.
- 05
Your secrets
Your connector credentials are stored encrypted with AES-256-GCM and a different key per company: one company's ciphertext cannot open another's. With no key, nothing is stored.
- 06
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.
- 07
The record
Every action is written down with who, when and what it cost, and the records are chained to one another. Spend caps stop the run on their own if something runs away.
The anatomy of a sign-in
What happens when somebody tries to get in
Every step is an independent check. If one fails, there is no next one.
- 01
The traffic is filtered
Firewall and rate limiting before anything reaches our servers.
- 02
Your origin is confirmed
The origin address comes from the network, not from a header a visitor can type by hand.
- 03
Brute force is slowed down
After five failures the response slows down progressively, and the lock reaches ten minutes. Guessing a six-digit code inside its thirty-second life stops being possible.
- 04
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.
- 05
The second factor is required
If your account has 2FA, no code means no entry. And some operations ask for it again even once you are in.
- 06
Your company is rechecked
On every request, against the database. Whatever the session token says is not enough: it can run ahead of reality.
- 07
Your role is checked
Platform administration is only reachable through a separate control. Everyone else sees “no access” even with a valid session.
- 08
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.
Compliance
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. The final physical erasure is still done by hand.
- 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 NDA.
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, with zero retention: 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 /sub-encargados.
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 quota for whatever you want to hand to Amadeus, and it is a switch: with it off, your data does not leave your infrastructure.
Separation between companies
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. every owned table has row-level security enabled — and forced — in the database engine itself, and an automated test walks the entire migration history and fails if anyone creates a table without it. But only two product paths run today as the restricted user those policies apply to; everything else runs as a user that bypasses them. So: a real second barrier on those two paths, and on the rest the net that switches on as they are migrated. That migration is pending, which is why you will see it again further down.
On Concerto Local, every customer gets their own dedicated database: there the separation is physical, not merely logical, and none of this discussion applies.
-- enabled and forced on EVERY owned table 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 two product paths use today SET LOCAL ROLE shara_app; SET LOCAL app.current_tenant = '…';
Agent manipulation
Fifty-four attacks, 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.
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.
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 quota or the spend caps, and extracting stored credentials.
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.
Technical measures
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).
- A progressive slow-down per origin address on 24 sensitive routes: sign-in, second factor, backup codes, invitations, activation keys, password recovery and the ones opened with a token.
- A ten-minute lock after five failures, counted per person and per method, on top of the per-origin slow-down.
- 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, the body of an inbound notification, 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.
Inbound notifications and signatures (7 measures)
- HMAC SHA-256 or SHA-512 signature, verified in constant time.
- With no secret configured nothing is accepted: it fails closed instead of letting things through.
- A five-minute window: a notification dated outside ±300 seconds is dropped even if the signature is correct.
- Each event is processed once per company, with two nets: memory and a constraint in the database itself.
- The secret belongs to each company. There is never one global secret shared between customers.
- When you connect a tool, the exchange token is deleted on read and bound to whoever started the process.
- Calls leaving the tool gateway cannot point at private addresses or at the hosting metadata services.
Encryption (6 measures)
- Your connector credentials are stored encrypted with AES-256-GCM, which both encrypts and detects any tampering.
- Each company derives its own key from the master secret with scrypt: one company’s ciphertext does not open another’s.
- 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.
- 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.
- No home-made cryptography: only what the system standard library provides.
Audit and traceability (6 measures)
- Every change is recorded with author, timestamp, resource and before/after.
- 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.
- That makes tampering provable, which is not the same as impossible: we do not prevent the write, we prove nothing was touched. There is a function in the database that walks the chain and verifies it.
- 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.
What we still do not have
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
Row-level security is enabled and forced on every owned table, with a test guarding it. But only two product paths run as the user those policies apply to; the rest leans on the application. Migrating the others is invasive and pending.
Final erasure
Closing your account blocks access immediately and is logged, and exporting your data is instant. The sweep that physically deletes everything associated is done by hand today; the automatic one is pending.
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 NDA. 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.
Key custody
The master secret each company’s key is derived from lives in the server configuration. The dedicated custody service is designed and unbuilt. The encryption itself does not change when it arrives: what changes is where the master key is kept.
Tests against the real model
The fifty-four attacks 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.
Want to review it properly?
Under NDA we share the audit reports with their findings, the draft impact assessment and the full results of the manipulation suite, case by case.
Documentation
Data processing documents
The full legal texts, ready for your compliance team.
Data processing agreement
The full text of the agreement
Read the documentSub-processors
Which provider is which, and where
Read the documentAI policy
How we use the models
Read the documentFound a flaw? Tell us responsibly at [email protected].