Security is the architecture, not a feature bolted on after.

Evodira does not ingest your files. The local agent extracts and redacts on the device, and what synchronises onward is typed claims and the redacted quotes behind them. There is no central index of your raw documents for an attacker to reach, because the product is not built around one. That removes an entire class of exposure that ranked-search products carry by construction.

Stated precisely: there is an index, and it holds claims, redacted quotes, and their embeddings. The claim is about what is not in it. Uploading raw source content is off by default and requires an administrator to enable it on a deployment profile.

The local agent runs on the endpoint and redacts sensitive content before any model processes it. Deterministic redaction runs first and single-threaded over credentials, private keys, tokens, contact details, financial, health, and privilege-marked material, so the text a model ever sees is already minimised.

The honest limit on that: the redaction rule set is a pattern library, and a pattern library is only as good as its coverage. It is a control we keep extending, not a guarantee that no sensitive string can ever pass. Treat it as defence in depth alongside the sync-mode ceiling and the policy gate, not as a proof.

Access controls are enforced before retrieval, not after. Evidence carries its ACL, the filter is applied inside the query rather than over the results, and an answer is assembled only from evidence the requester is entitled to see.

The property worth testing is the failure direction. Evidence carrying no ACL is quarantined and returned to nobody, rather than treated as visible across the tenant. Tenant isolation is enforced with explicit installation filters on each joined table rather than trusted to the joins. There is no relaxed permission mode to fall back to.

Where an ACL comes from matters, so here is each case. Evidence captured by the local agent is always scoped to its device owner and to administrators, and it is additionally workspace-readable unless the extraction is marked confidential or higher. Since “internal” is the default, that covers most of it. Evidence pushed through the authenticated ingestion API carries the permissions the caller supplies. Evidence pushed without permissions is given an explicit installation-wide read grant. No packaged connector mirrors a third-party system’s own permission model yet; that mapping is built with you per source during onboarding.

The local agent signs every request with a device-bound Ed25519 key over a canonical timestamp, nonce, method, path and body digest; nonces are persisted and replays rejected, with a bounded clock skew. A request is admitted only when the device, the installation, the membership, and the user are all active. Where evidence moves between a device, an edge relay, and the data plane, each hop is signed, so chain of custody is verifiable rather than assumed. The agent keeps its own local audit trail on the endpoint.

Every answer ships a Merkle certificate over the chain that produced it: the question, the model, each cited claim, and the content hash of the exact evidence version behind it, folded into one answer hash. It is recomputable offline, so your audit team can check it without asking us for anything.

What it attests is the chain from claim to evidence. It does not attest the permission decision: the ACL is enforced before retrieval (section 03) and recorded in the audit trail, but it is not hashed into the certificate. If your control requires cryptographic proof that a specific principal was entitled to a specific answer, the certificate is not that artefact today, and we would rather say so than have it fail an audit on your side.

Model output never becomes authoritative knowledge without passing the verification queue, where a human reviewer approves it under your installation’s rules. Approving makes a claim answerable; publishing certifies it. Neither happens automatically. There is no path in the product that publishes model output without a reviewer. Where a deployment profile permits automatic actions on the device, the profile names them and the desktop app shows the posture on screen.

What was captured, structured, approved, retrieved, and acted upon is recorded and reviewable. Source history is preserved when evidence is updated or contradicted, so a reviewer can reconstruct how a piece of knowledge reached its current state. Published versions are hashed into a provenance ledger, which is the chain a reviewer can re-derive independently.

Evodira ships as containers, and the profile decides where the data plane sits: managed, where we operate both planes; hybrid, where evidence, indexes, retrieval, and the local agent run on infrastructure you own under a managed control plane; or on-premises, where the whole stack runs inside your boundary with model routing to private or open-weight models.

The qualification a security reviewer should have up front: hybrid and on-premises are installed with our engineers, not self-served. There is no published Terraform module or Helm chart today, and multi-region residency is in build. Scope a pilot on that basis.

Claims and redacted quotes have to be embedded and synthesised somewhere. In the default managed configuration that is a hosted model provider, today Google’s, so the claim text and redacted quotes in an answer reach that provider. Raw files do not.

This is configuration rather than architecture: Evodira can be pinned to a region-resident endpoint or pointed at a self-hosted open-weight model. On the device, the deployment profile names which providers the agent may use and whether cloud fallback is allowed at all; fallback is off by default, and a policy change that disallows a running provider stops it rather than leaving it running. Ask which configuration your installation will run on. It is a question with a written answer.

Evodira is built for SOC 2 and GDPR from the architecture up, with data residency, redaction, audit trails, and human approval gates as first-class controls. The EU AI Act’s transparency and general-purpose obligations have applied since 2 August 2026, and we work to them as current law rather than as a date ahead of us. These statements describe our posture and design. They are not certifications we have completed. We will share the current state of our documentation, controls, and any attestations directly with you during a security review or pilot.

If you believe you have found a security issue, please contact us at security@evodira.com. We take reports seriously and will work with you on responsible disclosure.