eavantage
Request a demo

Trust & data handling

Security & data handling

This page is deliberately specific. eavantage is a governance product, and the quickest way to lose a security reviewer’s trust is a claim they can later disprove. So here is what is protected, what is partial, and what is your responsibility.

Your environment, your data

eavantage is licensed, self-hosted software: one deployment per firm, running entirely inside infrastructure you control. There is no vendor-held copy of your engagement data, your model, or your client’s documents. Nothing leaves for us to hold — which also means there is nothing to hand back if you stop using it.

The exception is the evaluation trial. The trial runs on a single shared cloud instance that we host, so the guarantee above does not apply to it. A demo dataset is provided and is enough to evaluate the product; the trial terms cover the rest.

What the AI sends to your language-model provider

This is the part most self-hosted assumptions get wrong, so it is worth stating plainly.

You choose the language-model provider — Anthropic, OpenAI, or Azure OpenAI. Most of eavantage’s AI features send real client business content to that provider, because they have to reason over the actual content to be useful: extraction, diagram ingestion, problem framing, the chat assistant, target-state drafting, and the gap, recommendation, and scoring engines all work this way by design. One feature is different — the discovery interview classifies input locally and discards the raw text before anything reaches the model.

Before content goes to the provider, personal names are pseudonymised where they appear in free-text evidence and in stakeholder records — replaced with stable placeholders and restored in the response. This is best-effort: it uses a pattern heuristic, not a named-entity model, and it is not a guarantee. Business identifiers — for example, up to six high-level capability names on each chat turn — are not pseudonymised.

If your engagement data cannot be shared with a third-party model provider under any circumstances, that is a constraint to talk through before a trial or a licence — raise it in a demo.

Audit & provenance

Every change to the model is written to an audit log that cannot be edited after the fact. AI-chat interactions have their own separate audit log. Standards carry a lineage record. Closing an engagement requires a dual sign-off, and eavantage verifies each signer’s actual role before accepting it. Once an engagement is sealed, its deliverables and templates are locked. Separately, an on-demand graph integrity check can be run at any point to detect orphaned, duplicated, or mis-nested elements.

This is the part of eavantage that answers a client’s “how do we know this is right, and what did the AI touch?” — and it is real today.

What’s in place today

All of the following is implemented and verified in the current build:

  • In the build pipeline — static analysis (Bandit) on every change, dependency scanning with automated security updates (Dependabot alerts and security-update PRs), a CycloneDX software bill of materials generated each build for both stacks, shipped container images built from an explicit file allow-list rather than the whole build tree, and remediation of every known vulnerability that has a fix available.
  • Input handling — field-level length and range limits on request bodies, upload size caps, hardened XML parsing confirmed against a live attack payload, and parameterised queries to the graph and document stores.
  • Transport & headers — an opt-in TLS overlay for every internal hop and the edge; a full set of HTTP security headers with violation reporting; no-store caching on API responses.
  • Rate limiting — three tiers: login attempts, AI-calling endpoints, and everything else.
  • Backups — every database dump is encrypted, and a full restore has been verified end to end.
  • Identity — single sign-on via OIDC (built to the generic spec; no specific identity provider is certified yet) with just-in-time provisioning, plus time-based multi-factor authentication for local accounts. A documented credential-rotation procedure with a staleness check.
  • Operational integrity — cascade deletes report partial results rather than a blind success; closure sign-off checks the caller’s real role, not a claimed one.
  • Custom entity types stay inside the same guarantees. A firm can define its own entity types and relationships through the metamodel editor; a custom type is written by the same single writer, carries the same tenant isolation and audit trail as a shipped type, and its candidates never auto-commit — even a high-confidence extraction floors at batch review, since the AI has no priors for a type it’s never seen. A custom type can only add a label — it can never remove a guarantee the shipped ontology already gives you.

What’s partial, or not there yet

Stated plainly, because a reviewer will find these anyway:

  • Fine-grained permissions — mostly, not fully. Access is role-based, segregation of duties is enforced (the person who drafts a deliverable cannot approve it), and most of the permission model is wired individually: every layer of the architecture model — business, application, data, motivation, implementation, technology, finance — is gated by its own read and write permission on the server, as are deliverable actions, client-portal access, tier-2/3 approvals, and most engagement-management operations. An engagement lead sets each role’s permissions from a “Manage access” screen. A few operations (tier-1 auto-approval, conflict resolution, role creation, phase advance) still fall back to a coarser “is this person on the engagement” check.
  • Encryption at rest. Not a product feature. The databases eavantage runs on do not encrypt at rest natively; you encrypt the host disk or volume when you deploy. See Deployment.
  • Independent security review. Static analysis, dependency scanning, and an internal fix register are in place. A formal third-party penetration test or code review has not been done.
  • Observability. Structured logging is in place; a full monitoring, tracing, and alerting stack has not been selected.
  • Connection pooling. Tuned for the paths that were load-tested; some code paths still open a database connection per call.

A buyer security review, answered

Does client data leave our environment?
No, for a self-hosted deployment — except what your chosen language-model provider sees (real business content; personal names pseudonymised where detected).
Single sign-on?
Yes — generic OIDC, feature-flagged. No named-vendor certification yet.
Multi-factor authentication?
Yes — time-based codes for local accounts; SSO accounts use your identity provider’s MFA.
Encryption in transit?
Yes — an opt-in overlay for all internal and edge hops.
Encryption at rest?
Not in the product — you encrypt the host disk or volume.
Formal penetration test or security review?
Not done. Static analysis, dependency scanning, and an internal fix register only.
Audit trail?
Yes — immutable, and it covers every governance event; AI-chat interactions have their own separate immutable log.
SLA or support commitment?
None formal today — handled personally. See Licensing.

How the databases and infrastructure fit together is on theDeployment page. Support and licensing terms are onLicensing.

Last reviewed 2026-09-04

Have a security question this page doesn’t answer?

Request a demoTalk to us about licensing

Ask it directly — a walkthrough is a real screen-share with someone who can answer, not a sales deck.