Encrypted under your key. Enforced in the server. Checkable by you.

1. A key per organization, not a key per company

   Every piece of your content at rest, in the databases and in object storage, is encrypted with AES-256-GCM under a key belonging to your organization alone. No shared key covers two customers.

2. The keys are not kept with the data

   Keys live in a separate service, under a root key protected by a secret held outside the platform by named people. A stolen disk, a copied snapshot or a leaked backup is a stolen disk, not a stolen platform.

3. Ciphertext that only opens where it belongs

   Every encrypted value is cryptographically bound to the exact place it was written. Moved somewhere else, or into another customer's data, it simply does not open. Reading the database and rearranging it are different attacks, and the second one gains nothing.

4. Search that never reads

   Sealed text stays searchable through an index derived under a key separate from the one that decrypts content, so the platform can find your document without being able to read it. One key never does both jobs.

5. Rotation without an outage

   An organization's key can be replaced while the product keeps answering, and the old key is retired only once every row has been proven to open under the new one.

1. Isolation by organization

   Every token carries the organization it belongs to. Handlers derive the organization from the token and never from a field the client can set, so one customer cannot address another's data.

2. Roles map to a permission catalogue

   A role in an organization mints exactly the scopes its permissions allow. Platform operators are a separate, narrow role that lives outside every organization.

3. The interface is not the control

   The console hides what you may not do, and every backend validates the token's scope again before it acts. The check that matters is the one on the server.

4. Service to service is explicit

   Backends authenticate to each other with signed tokens validated against a key set, authorized by a declared grant matrix rather than by network position.

1. Passkeys first

   A passkey is two factors at once and the browser releases it only to this deployment's own origin, so a convincing copy of the sign-in page collects nothing worth having.

2. An authenticator app, and codes you use once

   The fallback is a standard authenticator app, with ten recovery codes issued once and kept only as hashes. A code is spent the moment it is used, so a glance over a shoulder is worth exactly one sign-in.

3. Your organization sets the rule

   An organization can require a second factor of everybody, with a grace window so turning it on is not a lockout. Platform operators are required regardless, and that is not an organization's decision to make.

4. Guessing fails closed

   Attempts are counted across every replica, and both that counter and the policy lookup fail closed. A component nobody can reach refuses the sign-in rather than waving it through.

5. The token says how somebody proved themselves

   Applications read how and when a person signed in, and can demand a fresh, phishing-resistant authentication before a sensitive action. A stale session goes back through the front door.

6. Every attempt is on the record

   Sign-ins, refusals, lockouts, factors added or removed and recovery codes spent are all rows in your audit trail, with the address and browser encrypted inside them.

1. Append only trails

   Inference, knowledge, web search, code execution, agent runs, data operations and privileged administration each keep their own trail. Records are added, never edited.

2. Hash chained agent runs

   Each step in a run carries the hash of the one before it, so a record removed or altered after the fact breaks the chain and shows up as a break.

3. Evidence pack per run

   A single run can be exported with its steps, inputs, outputs, approvals and correlation, which is the artefact an auditor actually asks for.

4. Cost is part of the record

   Tokens and price are recorded with the request, so a bill can be reconciled against the trail rather than trusted.

1. In the European Union

   Databases, object storage and trails are hosted in the EU on European infrastructure.

2. No training on your data

   Prompts, documents and produced files serve your requests and nothing else.

3. Request bodies are not stored by default

   The trail keeps metadata, token counts and cost. Storing full bodies is an organization's decision, with its own retention.

4. Two retention clocks and a hold

   The payload is scrubbed on the first clock, the record is deleted on the second, and a legal hold suspends both. Files produced by the platform have a clock of their own.

1. A window to change your mind

   Deleting an organization suspends it first. Sign-in stops and no token is minted, but nothing is destroyed, and a restore inside the window puts everything back exactly as it was.

2. Every service, not just the obvious one

   When the window closes, the deletion fans out to every service that ever held a row or a file for you, and each one reports what it removed. The report is readable afterwards.

3. Then the keys are destroyed

   Last of all, your keys are destroyed. Anything anybody missed, including copies inside backups nobody can reach any more, becomes permanently unreadable. That is the strongest deletion guarantee this platform can give, and we demonstrate it by restoring an old backup and showing that it no longer opens.

4. People erased, history intact

   Deleting a person erases the person rather than the record. Their tasks and conversations still resolve to an identity that names nobody, so the trail an auditor reads does not develop holes.

5. Invoices stay, because the law says so

   Accounting records survive a deletion. Everything else goes.

6. A legal hold stops all of it

   A hold suspends the clocks and the deletion, and says plainly which organization is held and why, rather than quietly skipping it.

1. Customer code has no network

   Code runs in an isolated sandbox whose network is cut inside the runner itself rather than by a rule somewhere upstream of it.

2. Tools run through a broker

   An agent never holds a credential. It receives a capability minted for one call, and the broker performs the call and records it.

3. Secrets come from the environment

   Nothing sensitive is written to a config file or a log line. Configuration secrets are encrypted at rest, and API keys are stored as hashes.

4. Approval before consequence

   An effect that changes something in the world can require a second person before it runs, and the approval is part of the record.

Ask for the control mapping, the drill results and a processing agreement at any point in a review.

security@neurifly.com

https://neurifly.eu