EVE vs Authensor

A factual comparison for teams evaluating agent governance approaches. This page states only claims we can source. Where a capability cannot be independently sourced, it is marked "not independently verified here" rather than asserted or denied.

Positioning

Authensor focuses on open-source agent security and safety controls. EVE is positioned as a proof-bearing governance and enforcement platform for organizations that require deterministic decisions and independently verifiable evidence.

The two occupy different points on the same problem: keeping AI agents inside intended limits. EVE's distinguishing emphasis is a deterministic policy decision (ALLOW / BLOCK / MODIFY) computed before a governed action executes, with no LLM in the decision path, plus a signed evidence record bound to each decision that a third party can verify offline without trusting the EVE server.

Capability matrix

Rows about Authensor are marked "not independently verified here" because we do not hold sourced evidence for those specific rows. This is not a claim that the capability is absent — only that we do not assert it either way.

For fairness, Authensor's own materials (retrieved 2026-07-20) describe an open-source stack: a policy engine, a receipt chain (hash-chained records), the Aegis prompt-injection scanner, and the Sentinel behavioral-drift monitor. So EVE's differentiator is not "having an audit trail" — Authensor ships a receipt chain. EVE's specific, registry-sourced claims are independently verifiable signed decision certificates (offline Python/Node/browser verification, no server trust) and approved-vs-executed MCP request binding; whether Authensor offers those exact properties is not established in its public docs (Unknown, per the source ledger).

Where EVE fits

Choose EVE when the requirement is a deterministic decision boundary before a tool executes plus independently verifiable proof of what was decided. EVE produces a GovernanceResult with reason codes, a decision id, and a signed evidence envelope; verification checks integrity, signature, and schema without contacting the EVE server.

Readiness

• EVE SDK core is a RELEASE CANDIDATE WITH EXCLUSIONS.
• The Python client (eve-coreguard 0.2.2) and TypeScript client (@eve/coreguard 0.1.0-rc1) are release-candidate core clients. The release-candidate clients are distributed privately for pilots — install the pilot artifact, not a public pip/npm install (see readiness for public-registry status).
• The core governance architecture is pilot-validated. Signed evidence and offline verification (jcs-1 canonicalization) are SUPPORTED.
• Framework adapters other than the generic adapter are experimental.

Limitations

• This comparison sources only EVE's capabilities from the EVE claims registry. Authensor rows are marked "not independently verified here" and are not accusations of missing features.
• The pip client governs via hosted mode (requires a reachable endpoint); embedded in-process evaluation is the EVE service, not the client wheel.
• Independent (asymmetric) verification requires the Ed25519 public key; the HMAC fallback is symmetric and not independently verifiable.
• MCP binding provides at-most-once authorization consumption and approved-equals-executed binding; it does not provide remote exactly-once execution — an unknown remote outcome is recorded as OUTCOME_UNKNOWN, never silently retried.
• jcs-1 is a constrained RFC 8785 profile: it fails closed on non-integer floats / NaN / Infinity and is not full float compliance.
• Framework adapters other than the generic adapter are experimental and untested against pinned live framework versions. Wrapper-enforced adapters can be bypassed by a direct call to the underlying tool; cooperative hooks are not an unbypassable boundary. Hard enforcement requires a gateway or sidecar.