Comparisons

EVE vs Authensor

A factual comparison for teams evaluating agent governance approaches. This page states only claims we can source. EVE rows are sourced from EVE's claims registry; Authensor rows from Authensor's public website and repository (retrieved 2026-07-22).

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

Capability	EVE	Authensor
Deterministic pre-execution decision (ALLOW / BLOCK / MODIFY)	Yes — `core/coreguard/evaluator.py`; PILOT_READY	Yes — declarative policy engine (allow / block), per Authensor's public docs
No LLM in the decision path	Yes — deterministic policy kernel; PILOT_READY	Yes — deterministic policy evaluation (conditions / sessions / budgets)
Signed decision evidence bound to the decision (ECDSA P-384 prod / HMAC fallback)	Yes — SUPPORTED	Partial — SHA-256 hash-chained receipts + optional Sigstore/Rekor; no per-decision asymmetric signature
Offline, independent evidence verification (Python / Node / browser)	Yes — SUPPORTED	Partial — local receipt-chain verification; public transparency via Rekor (opt-in)
MCP approved-vs-executed request binding (at-most-once)	Yes — `core/mcp/execution_binding.py`; PILOT_READY	Yes — SEP authorization protocol + TOCTOU re-evaluation
Server-derived MCP identity (forged headers rejected)	Yes — PILOT_READY	Not documented in public materials
Action-sequence governance (block prohibited combinations)	Yes — `core/agent_monitoring/sequence.py`; PILOT_READY	Yes — session forbidden-sequence rules
Deterministic budget / resource limits	Yes — PILOT_READY	Yes — budget / constraint enforcement
Customer-runnable adversarial red-team suite with signed reports	Yes — PILOT_READY	Yes — Chainbreaker red-team harness (MITRE ATT&CK); signed reports not documented
Open-source distribution	Public clients — `eve-coreguard` (PyPI), `eve-ai-governance` (npm); core service is commercial	Yes — MIT-licensed, self-hostable (18 npm packages)

Authensor rows above are sourced from Authensor's public website and repository (retrieved 2026-07-22); they describe what Authensor documents, not an independent test by EVE. Both products now publicly present deterministic policy enforcement, MCP governance, behavioral monitoring, human approvals, and tamper-evident audit records — so the distinction is no longer "enforcement vs monitoring."

EVE's specific differentiator is narrower and concrete: a per-decision ECDSA P-384 signature bound to the request, response, and policy version that a third party verifies offline without trusting EVE. Authensor's evidence is a SHA-256 hash-chained receipt log (tamper-evident, with optional Sigstore/Rekor publication) rather than an asymmetric signature on each individual decision — a real difference for examiner-grade, non-repudiable proof. Authensor's countervailing strengths are open-source (MIT) availability, one-command onboarding, and a free tier.

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.7) and TypeScript client (eve-ai-governance 0.3.1) are release-candidate core clients. The clients are published on public registries: pip install eve-coreguard (PyPI) and npm install eve-ai-governance (npm).
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

EVE capabilities are sourced from the EVE claims registry; Authensor capabilities from Authensor's public website and repository (retrieved 2026-07-22). Competitor rows describe documented capabilities, not independent EVE testing.
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 ECDSA P-384 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.