# Red-team testing > How Neural Inverse attacks its own products: the attackers we assume, the attacking tests that run on every change, and what we do not claim. Source: https://neuralinverse.com/trust/security-testing/ --- 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 client:** Our 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 policy:** An 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 organisation:** A signed-in user of one organisation trying to read, change or even detect the existence of another organisation's data. - **A compromised extension or window:** A 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 rights:** Someone who edits files in the app's data folder or the repository, sets environment variables or starts the app with debugging flags. - **Replay and rollback:** Restoring 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 scenario:** Each 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 attack:** Each 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 change:** The suites run in continuous integration on changes to the code they protect, and a failure blocks the change. - **Fixed, not filed:** What 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 rules:** A 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 switch:** API 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 isolation:** Tests try to read and write across organisations as the runtime database role; row-level security refuses them and fails closed. - **Context and shared knowledge:** Evidence 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 record:** First-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 desktop:** An 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 tampering:** A 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. - **Agents:** An agent writes to its policy, hooks, git hooks or the audit folder, or chains commands behind an allowed one. - **Sign-in, vault and context:** Account 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 administrators:** A 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 keys:** Someone 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 copied:** Content copied out by someone who was allowed to read it. - **Instructions you approved:** An approved instruction file that is hostile is labelled, delimited and recorded, but an agent may still follow it. - **Two accounts, one person:** Separation of duties works by account; the platform cannot know that two accounts belong to the same person. - **Independent assessment:** This 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. [Request security documents](https://neuralinverse.com/trust/documents/) [Vulnerability disclosure policy](https://neuralinverse.com/trust/vulnerability-disclosure/) ![](/photos/team.jpg) ## Talk to our team. Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation. [Request access](https://neuralinverse.com/contact/?topic=access)[Contact us](https://neuralinverse.com/contact/)