Security and compliance

Shara’s principle: your data is yours and is protected by default, not by configuration. Security is organized in layers, from isolation between clients to human control of every relevant action. Nothing an agent does escapes the record, and nothing with real impact runs without a person approving it.

The seven layers

1. Multi-tenant isolation: every query is filtered by your organization, and in thirteen areas the database adds its own row-level policies (RLS).
2. Authentication and access: signed session tokens with short expiry, control by role and department, and optional two-step verification: whoever turns it on needs it across the whole application, and the company can require it of the whole staff.
3. Encryption: in transit (TLS 1.2 or higher); secrets and credentials encrypted with AES-256-GCM, with their own key for each item; backups encrypted with AES-256 before leaving the server; and strict headers (HSTS for two years with preload, CSP, X-Frame-Options).
4. Anti-prompt-injection: every release is tested against 58 adversarial cases (OWASP LLM Top 10 plus our own) on recorded responses; if the share neutralized drops below 95%, the release is blocked.
5. Output redactor: reviews every response before returning it to prevent leaks (for example, the real provider behind an alias).
6. Human control (approvals): no action with relevant effects runs without human approval.
7. Verifiable audit log: the actions of your company are recorded in a chain of hashes that you can check.

Each layer is independent: if one fails, the others stay standing. An attacker who got past authentication would run into tenant isolation; if they bypassed isolation, the redactor would still filter the output; and whatever happens, the action would be left in the audit log. It is defense in depth, not a single wall.

Multi-tenant isolation

Each client is a tenant with its own logical space. As soon as your request enters through the API, the context middleware fixes your organization as a mandatory filter on every later query. It is not an optional check the code could forget: without tenant context, the query returns no rows.

On top of that, in thirteen areas (model consumption, billing, approvals, reading of memory, runs, flows, integrations, HR, projects, support, tax invoicing, document templates and customers, the CRM) the database enforces its own row-level policies (RLS) as a second, independent barrier. The rest of the data is isolated by the company filter on every query.

The practical consequence is simple: one organization’s data is not visible to another. An agent of your company can’t read the CRM, emails or documents of any other Shara client. And when Amadeus delegates to a specialist, it passes only the context that task needs, without opening up the rest of your data.

In Concerto Local isolation is physical as well as logical: the platform runs on your own infrastructure, and in local-only mode no inference call leaves. Read Concerto Local.

Roles and permissions

Access is governed by six roles: owner, administrator, director, operator, IT and viewer. The role decides which surfaces a person reaches and what they can do. It is the same model in the desktop app and in the backend, so there are no back doors: if a role doesn’t have a permission, it doesn’t have it anywhere.

The single table with what each role can do is in Roles and permissions.

The role is the source of truth for permissions, and it is read at the moment: if you downgrade someone from Administrator to Viewer, they lose access immediately on their next request, without waiting for their session to expire. Detail of agents by department in the catalog.

Two-step verification (2FA)

A password alone is not enough for operations with power. Two-step verification (TOTP) is optional, with two exceptions: the company can require it of its whole staff, and those who administer (owners and administrators) need it for operations with power: inviting the team, API keys, the agents’ identity, the administration panel, changing the password and removing their own 2FA. Without a configured second factor, those operations don’t run until it is enrolled. Anyone who has 2FA turned on needs the second factor (or a passkey sign-in) across the whole application: on every request, on the real-time channel, in connector settings and when approving actions, not only on sensitive operations. Anyone who does not have it on, and whose company does not require it, signs in with a password. It is set up with any standard authenticator app (Google Authenticator, Authy, 1Password), and when you enable it you receive a set of single-use recovery codes so you aren’t locked out if you lose your phone. Passkeys are also supported.

The company can require two-step verification of its whole staff from Settings → Security (Require 2FA for the whole team). With that setting on, it is required of every member, including when they sign in from another company.

Against guessing attempts: after 5 failures, every attempt from that IP address is delayed by up to 5 seconds; and five wrong 2FA codes lock that factor for 10 minutes. Internally, all comparisons of codes, tokens and signatures are done in constant time so as not to give clues to an attacker.

Encrypted vault for secrets

The secrets Shara needs to work for you (your connectors’ tokens, API keys, OAuth credentials) are not stored in the clear anywhere. They are encrypted with AES-256-GCM, using its own key for each item (envelope encryption). That key is in turn wrapped by a master key that lives outside the code and outside the database.

Each encrypted item is also bound to your company through associated data (AAD) that includes your organization’s identifier. A ciphertext can’t be “moved” from one tenant to another: decryption fails if the context doesn’t match. The cryptography relies only on standard platform primitives, never on home-made implementations.

The master key can be rotated without decrypting the data and without stopping the service: during the change, the application reads with both the old and the new key. We do not commit to a rotation schedule.

Internal golden rule: Shara never logs in the clear an activation key, an OAuth refresh token, a password, a session token or a vault key. If something needs to be traced, only a prefix of a few characters is stored.

Human approval

It guarantees that nothing critical runs without review, keeping speed for everything else. They require approval: sending email to external recipients; payments and transfers; HR decisions with effect; changes to critical data; posts and replies to clients; and calls to external tools outside what was marked safe.

In the Approvals inbox you see the requesting agent, the action in natural language, the context and the Approve/Reject buttons. Whoever approves leaves a trace in the audit log. Time limits and what happens when a request expires are in Approvals and audit.

Spending caps

Besides human control, three automatic caps stop execution without anyone’s intervention as soon as a spending threshold is exceeded. They are a seat belt against an unexpected loop, a malicious prompt or a badly calibrated task.

Cap	Default
Per run	1M STU
Per hour	10M STU in the last 60 minutes
Per day	80M STU in the last 24 hours

The windows are rolling, not clock-based. An owner or administrator can edit the values or switch any cap off in Settings → Limits & alerts. The hourly and daily caps lift on their own when their window drops below the threshold; the per-run one, after an hour. An administrator can lift them earlier, or leave a manual pause that doesn’t lift on its own.

They are defense, not billing: a halted run doesn’t charge you extra. More context in Approvals and audit and in STU and quotas.

Audit log

Your company’s actions are left in the audit log: who did it, what they did, on which resource, and the state before and after.

Anti-tampering: the database only allows lines to be added to the log: modifying, deleting or emptying it is rejected, even for the application itself. On top of that, each record is chained with a SHA-256 hash to the previous one. You don’t have to take our word for it: there is a chain check you can launch yourself (GET /audit/verify-chain). It detects that a record in the middle was altered and returns the first invalid one. In addition, every hour we store a signed copy of the last line of your 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. See Approvals and audit for the fields.

The corporate identity (IDENTITY.md) is also auditable: it evolves through versioned patches, never by replacement, and each change is logged with its before/after. Read Corporate identity.

Your data leaves when you want

An owner or administrator can export all the company’s data from Settings, as a .zip with one NDJSON file per table and a manifest.json, at most once every 24 hours. In CSV, on request. Each person also has a personal export and a deletion request (/me/data-export and /me/delete-request). The detail is in No vendor lock-in.

Retention

Automatic deletion by age is on. Your company’s owner chooses in Settings how long conversations and runs are kept (30, 60, 90, 180 or 365 days; 90 by default) and every night anything older is deleted. If you shorten it, the app asks you to confirm and the new period applies after 7 days; until then the previous one still holds. Technical logs are deleted after 90 days. The audit log, billing, memory (you delete it) and configuration are never deleted by age. When the contract ends, after the export, we delete your company’s data and give you a signed deletion certificate. Before that, the subscription and pending charges are cancelled. Only what the law requires us to keep is retained: billing, 6 years (art. 30 of the Commercial Code). Backups keep the data until they expire, after 35 days. If the service were ever suspended, there are thirty calendar days of read-only access to take your data out.

The output redactor

Before any response reaches you, a log or a client, it goes through a redactor. Its job is to prevent internal information from leaking: the name of the real provider behind each model alias, raw error messages from external SDKs, database schema details or any technical residue that shouldn’t get out.

You work with four models by public alias (Prelude, Sonata, Symphony, Concerto), and those aliases are the only thing you, your team or the API will see. The redactor applies to everything: every response, every execution plan and every line of context.

The real provider behind each alias is confidential. It can be disclosed only to Max and Concerto Local clients, under an NDA, through support@aiginer.com. Read No lock-in.

Where your data is

Inference and the database are in the European Union. A few services outside the EU take part, under standard contractual clauses: transactional email, Cloudflare (network and delivery) and payments. Concerto Local runs on your own infrastructure.

Backups: four a day, encrypted (AES-256, GPG) and stored outside the server, kept for 35 days with a deletion lock of 30. A real restore test runs every week. File attachments do not have a backup yet.

Certifications

Shara has no certification today: no ISO 27001, no SOC 2 and no external audit. What this page describes is what the product does, and you can check part of it yourself (for example the audit chain).

Regulatory compliance

Framework	What we cover
GDPR	Only necessary data is processed; record of processing activities; subprocessor list with the DPA (article 28, in every plan); data-subject rights by endpoint; breaches notified within 72 h.
Data in the EU	Inference and the database are in the EU; the exceptions are listed above. Concerto Local runs on your own infrastructure.
NIS2-type technical measures	Two-step verification available for all accounts and enforceable for the whole company, role-based control, encryption in transit, encryption of secrets and credentials and of backups, and incident management with a runbook. NIS2 binds certain types of entity: if it applies to you, these measures help you, but they don’t release you from your own obligations.
EU AI Act (limited risk)	Transparency (you know you are talking to an AI agent), traceability (audit log) and human oversight (approvals).

GDPR is not an appendix, it is part of the design. You have the list of subprocessors in the data processing agreement (DPA) you accept when activating the account, and the rights of your data subjects (access, rectification, erasure, portability) are exercised through specific endpoints. The legal documents are the Terms, the DPA and the SLA.

Best practices for your organization

Shara provides the security infrastructure; you make the most of it with a few simple habits:

• Enable two-step verification on all accounts, not only the administration ones, and save the recovery codes in a password manager.
• Apply least privilege. Give each person the lowest role that lets them work: a profile that only consults should be Viewer, not Administrator.
• Review the approvals inbox daily. It is your real control point; an unattended request expires and the action does not happen.
• Configure your business hours. Outside them saving mode applies and it is easier to detect anomalous activity.
• Treat any spending cut as a signal to investigate, not as noise. You can adjust the caps, but a cap that trips with normal use is telling you something.
• Remove whoever leaves. Withdraw former employees’ access the same day; the role is revoked instantly. The step-by-step is in Account, team and access.
• Review the audit log periodically and run the chain check from time to time.
• Connect only the tools you use and review the OAuth permissions granted; the fewer secrets you store, the smaller your exposure surface.

Anti-prompt-injection

All data that comes from outside (an incoming email, the content of a ticket, a document) is treated as potentially hostile. Shara wraps that content with markers that separate it from the system instructions, so a text can’t pass itself off as a legitimate order. It is the defense against prompt injection attacks, where someone tries to hijack an agent by hiding instructions in the data.

Every release is subjected to a battery of 58 adversarial cases (those of the OWASP LLM Top 10 plus our own), checked against recorded responses. If the percentage of attacks neutralized drops below 95%, publication is blocked automatically.

Reinforced security add-on

For reinforced needs, the agent Kerckhoffs acts as a virtual CISO: security policies, OWASP-based checks and runbooks. It is an AI agent, not a human service. It is an additional agent, hireable from Max at €99/month and 15M STU, and it comes included in Concerto Local.

Security questions or responsible disclosure: seguridad@aiginer.com. Legal documents: Terms, DPA and SLA. The detail of the approvals flow and the log is in Approvals and audit.