Security and trust
We attack our own products.
Regulated customers ask what someone could do if they set out to manipulate the platform. We answer with attacking tests: each one plays an attacker against the real code, and runs on every change.
Who we test against
Attackers who have read the source.
An insider with a modified clientOur source is not published, but we never rely on that: we assume an employee with a valid account, API key or agent token has read the source, runs a modified client and sends requests the real apps never would. Every control is enforced on the server.
An AI agent escaping its policyAn agent that writes to its own policy, hooks or audit folder, chains a forbidden command behind an allowed one, or follows hostile instructions in a repository file.
Another organisationA signed-in user of one organisation trying to read, change or even detect the existence of another organisation's data.
A compromised extension or windowA malicious editor extension, or a window compromised through a crafted file, trying to reach audit records, approvals, policy or local sockets.
A local user without admin rightsSomeone who edits files in the app's data folder or the repository, sets environment variables or starts the app with debugging flags.
Replay and rollbackRestoring an older policy bundle, audit ledger, signed checkpoint or approval to undo a decision.
How the tests work
Every defence has a test that tries to break it.
An attacking test per scenarioEach attack is written as an automated test that tries to break a control against the real code. On the server, the tests run as the same restricted database role the product uses, against PostgreSQL.
Proven to catch the attackEach test is shown to fail when the defence it targets is removed, so a passing test means the defence works, not that the test is weak.
Run on every changeThe suites run in continuous integration on changes to the code they protect, and a failure blocks the change.
Fixed, not filedWhat the attacks found was fixed in the product, and each fix has its test. A module's security review maps every threat to its control and the test that proves it.
Neural Inverse Govern
What the server refuses.
Approvals and two-person rulesA requester cannot approve their own request, move an approval onto a different action, choose their approver, approve with an API key, or vote after a request expires.
Agent policy and the kill switchAPI keys cannot loosen policy or release a kill switch; leaving a field out never loosens a rule; decisions from the edge are re-checked, not trusted as sent.
Tenant isolationTests try to read and write across organisations as the runtime database role; row-level security refuses them and fails closed.
Context and shared knowledgeEvidence is append-only; decisions such as approving, sharing and legal holds need a person, not an API key; a missing item and an item you may not see answer the same way.
The audit recordFirst-party apps can only record events for the signed-in person and their own organisation; a request naming anyone else is refused.
Neural Inverse Build
What the Editor, Agents app and CLI refuse.
Audit and approvals on the desktopAn extension or a crafted message tries to append, read or erase audit events, sign an approval or change policy. Decisions and keys never live in a window or an extension.
Rollback and tamperingA local user swaps in an older valid policy bundle, edits or restores the audit ledger, deletes the outbox or edits approval records in the repository. Each attempt is refused or detected and recorded.
AgentsAn agent writes to its policy, hooks, git hooks or the audit folder, or chains commands behind an allowed one.
Sign-in, vault and contextAccount files, sign-in location binding, vault commands and agent runs, context sharing, team memory and agent instruction files are each attacked in the Editor, the Agents app and the CLI.
What we do not claim
The limits, stated plainly.
Your own administratorsA local administrator can do anything on their own machine; we make tampering detectable, not impossible. A compromised administrator account can do what that account is allowed to do, and every action is recorded.
Whoever holds the keysSomeone with the database owner role or the audit signing keys can change records. Verifying the chain detects the change; it cannot prevent it. That is why your deployment's keys and database access matter.
What a person already copiedContent copied out by someone who was allowed to read it.
Instructions you approvedAn approved instruction file that is hostile is labelled, delimited and recorded, but an agent may still follow it.
Two accounts, one personSeparation of duties works by account; the platform cannot know that two accounts belong to the same person.
Independent assessmentThis is our own testing. It does not replace an assessment by your security team or an independent tester, which you can run against your own deployment under our vulnerability disclosure policy.
For your review
The threat models and tests, under NDA.
Under a non-disclosure agreement, your security team can read our threat models, the security review of each module and the attacking tests themselves, and run them.
Talk to our team.
Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation.