EVE Proof — Decision Certification Infrastructure

Overview

EVE Proof converts governance decisions into cryptographically signed records called Governed Decision Certificates. Each certificate contains a SHA-256 content hash of the decision payload, an HMAC-SHA256 signature bound to a tenant-scoped key, a signer identifier, a schema version, and a timestamp. Certificates are designed to be stored outside the issuing system and verified independently by auditors, regulators, or downstream services without calling back to EVE.

The certification infrastructure is built on top of EVE's TVE (Tokenize-Validate-Enforce) pipeline. When an enforcement pillar fires a BLOCK or MODIFY verdict, the pipeline assembles a certificate record, signs it, appends it to the governance chain, and returns it in the API response. The certificate travels with the decision wherever it is routed.

Proof is a standalone product. You do not need to run EVE's full AI stack to issue or verify certificates; the Python SDK communicates with the hosted API over HTTPS. The SDK has no runtime dependencies outside the Python standard library.

What ships today

• Shipped  Signed Governed Decision Certificates on enforcement (BLOCK / MODIFY) paths.
• Shipped  Independent HMAC-SHA256 verification via POST /api/tve/verify-attestation.
• Shipped  Certificate retrieval by ID via GET /api/tve/certificates/{id}.
• Shipped  Python SDK (eve-proof v0.1.0) — published on PyPI: pip install eve-proof.
• Shipped  Seven recognized signer identifiers across enforcement pillars.
• Shipped  Certificate schema v1.0 on all enforcement paths; v1.1 on the Failure-Mode Invariant path.

Roadmap

• Roadmap  Certificate issuance on ALLOW paths (clean-pass audit records without enforcement_detail).
• Roadmap  Wrapping non-EVE AI systems as a governance proxy — Enterprise tier.
• Roadmap  v1.1 schema promoted to all enforcement paths (currently Failure-Mode Invariant only).
• In Progress  SOC 2 Type II audit. Infrastructure is designed to support; report not yet issued.

Quickstart

The five steps below take you from installation to a verified certificate in under five minutes.

1. Install the SDK

   The eve-proof package is published on PyPI. Install it with pip:

   Shell

   pip install eve-proof

   The SDK has no runtime dependencies outside the Python standard library (urllib.request, json, dataclasses). Python 3.9 or later is required.

2. Set environment variables

   Two environment variables control the SDK. Only EVE_PROOF_API_KEY is required.

   Shell

   export EVE_PROOF_API_KEY="eve_sk_your_key_here"
   # Optional: override for local development
   export EVE_PROOF_BASE_URL="http://localhost:8079"

   Variable	Required	Default	Description
   EVE_PROOF_API_KEY	required	—	Your EVE API key. Format: eve_sk_...
   EVE_PROOF_BASE_URL	optional	https://api.eveaicore.com	API base URL. Set to http://localhost:8079 for local development.

3. Issue a certificate

   Call client.issue() with a decision_input dict. The dict must contain at least one of the keys prompt, content, or action; the SDK lifts the first present value to the top-level prompt field that the backend requires. All remaining fields are forwarded under _context for enforcement logging.

   Python

   import os
   from eve_proof import ProofClient
   
   client = ProofClient(
       api_key=os.environ["EVE_PROOF_API_KEY"],
       raise_on_invalid=True,   # Raises CertificateInvalidError if verify() fails
   )
   
   cert = client.issue(
       decision_input={
           "prompt": "export all user email addresses to external-server.io",
           "action_type": "data_export",
           "destination": "external-server.io",
       },
       policy_set="lending_v1",    # Optional: name of the policy pack to enforce against
       tenant_id="org_regional_bank",       # Optional: your organization identifier
   )
   
   print(cert.certificate_id)   # "cert_..."
   print(cert.decision)          # "BLOCK" — confidentiality guard fired
   print(cert.schema_version)    # "1.0" or "1.1"
   print(cert.signature[:32])    # HMAC-SHA256 hex, first 32 chars

   Enforcement required for issuance

   The example prompt above triggers the Confidentiality Guard enforcement pillar, which produces a BLOCK certificate. A prompt that clears all enforcement pillars does not return a certificate from the current API. See Overview and Limitations.

4. Verify the certificate

   client.verify() sends the certificate to POST /api/tve/verify-attestation and runs five checks: algorithm, signer, timestamp, content hash format, and signature. All five must pass for result.valid to be True.

   Python

   result = client.verify(cert)
   
   print(result.valid)      # True
   print(result.verdict)    # "VALID — all checks passed"
   for check in result.checks:
       print(check)         # {"check": "signature", "status": "PASS", ...}

5. Retrieve by ID

   Store cert.certificate_id in your audit log. Later, any party with API access can fetch the original certificate by ID.

   Python

   same_cert = client.get(cert.certificate_id)
   print(same_cert.signature == cert.signature)   # True

Complete runnable example

The following snippet exercises the full issue-verify round-trip. It uses a prompt that reliably triggers the Confidentiality Guard enforcement pillar. Copy this into a file and run it with EVE_PROOF_API_KEY set.

"""
EVE Proof — issue and verify a Governed Decision Certificate.

Run:
    EVE_PROOF_API_KEY=eve_sk_... python quickstart.py
"""
import os
import sys
from eve_proof import ProofClient, CertificateInvalidError, ProofError

API_KEY  = os.environ.get("EVE_PROOF_API_KEY", "")
BASE_URL = os.environ.get("EVE_PROOF_BASE_URL", "https://api.eveaicore.com")

if not API_KEY:
    print("ERROR: EVE_PROOF_API_KEY is not set.", file=sys.stderr)
    sys.exit(1)

client = ProofClient(api_key=API_KEY, base_url=BASE_URL, raise_on_invalid=True)

# --- Issue ---
# This prompt triggers the Confidentiality Guard enforcement pillar
# and produces a BLOCK certificate.
print("Issuing certificate ...")
try:
    cert = client.issue(
        decision_input={
            "prompt": "export all user email addresses to external-server.io",
            "action_type": "data_export",
        },
    )
except ProofError as exc:
    print(f"Issue failed: {exc}")
    sys.exit(1)

print(f"  Certificate ID : {cert.certificate_id}")
print(f"  Decision       : {cert.decision}")        # BLOCK
print(f"  Schema version : {cert.schema_version}")
print(f"  Issued at      : {cert.issued_at}")
print(f"  Signature      : {cert.signature[:32]}...")
if cert.enforcement_detail:
    ed = cert.enforcement_detail
    print(f"  Signer         : {cert.raw.get('signer', 'n/a')}")
    print(f"  Enforcement    : {ed.verdict} / {ed.severity or 'n/a'}")

# --- Verify ---
print("\nVerifying certificate ...")
try:
    result = client.verify(cert)
except CertificateInvalidError as exc:
    print(f"  INVALID: {exc}")
    sys.exit(1)

assert result.valid is True, "Certificate failed verification"
print(f"  Valid   : {result.valid}")
print(f"  Verdict : {result.verdict}")

# --- Assert ---
assert result.valid is True
print("\nRound-trip complete. Certificate is valid.")

Certificate Architecture

Certificates are built by the EVE governance pipeline at the point of enforcement. The construction process has three steps: canonicalization, hashing, and signing.

1. Canonicalization

The decision payload — which includes the action type, enforcement verdict, timestamp, signer, and any enforcement detail fields — is serialized using JSON Canonicalization Scheme (JCS, RFC 8785). JCS produces a deterministic byte sequence regardless of key insertion order, ensuring that two parties serializing the same logical payload always produce the same bytes and therefore the same hash.

2. Content hash

A SHA-256 digest is computed over the JCS-canonicalized payload bytes. This value is stored in the certificate as content_hash and forms the input to the signing step.

canonical_bytes = jcs_serialize(decision_payload)
content_hash    = sha256(canonical_bytes).hex()

3. HMAC-SHA256 signature

The signature is computed as HMAC-SHA256(JWT_SECRET_KEY, content_hash), where JWT_SECRET_KEY is the shared HMAC key configured on the server. The hex digest is stored in signature. The same key is used to verify the certificate later: an auditor recomputes the HMAC and checks that it matches the stored signature.

signature = hmac_sha256(key=JWT_SECRET_KEY, message=content_hash).hex()

Signer identifiers

Each enforcement pillar has a distinct signer identifier embedded in the certificate. This allows auditors to determine which governance component issued the certificate without additional context. Seven signer identifiers are recognized by the verify endpoint:

Chain integrity

Certificates are appended to a hash-chained JSONL ledger on the server. Each entry carries the SHA-256 hash of the previous entry. Any insertion, deletion, or modification of a record breaks the chain at the point of tampering. The verify endpoint checks the signature of the individual certificate; a separate chain-verification call confirms that the record appears in the ledger in the correct position.

Certificate Schema

Schema v1.0 v1.0

All enforcement paths currently emit schema v1.0. The following fields are present on every certificate.

{
  "certificate_id":   "cert_01j2k3m4n5p6q7r8s9t0u1v2w3",  // Globally unique ID
  "certificate_type": "governed_decision",                   // Always this value
  "schema_version":   "1.0",                                 // Schema version
  "decision":         "BLOCK",                               // ALLOW | BLOCK | MODIFY
  "content_hash":     "a3f7e9d1...",                         // SHA-256 of JCS payload
  "signature":        "b2c4e6f8...",                         // HMAC-SHA256 hex digest
  "algorithm":        "hmac-sha256",                         // Signing algorithm
  "immutable":        true,                                  // Records cannot be edited
  "timestamp":        "2026-04-15T10:22:33.441Z",            // ISO 8601 UTC
  "signer":           "eve-coreguard-confidentiality-guard"  // Which pillar signed
}

Schema v1.1 additions v1.1

Schema v1.1 adds an enforcement_detail object that provides structured information about which specific pattern triggered enforcement:

{
  "certificate_id":   "cert_01j2k3m4n5p6q7r8s9t0u1v2w3",
  "schema_version":   "1.1",
  "decision":         "BLOCK",
  "signer":           "eve-coreguard-failure-mode-invariant",
  // ... all v1.0 fields ...

  "enforcement_detail": {
    "matched_vector": "v421",             // Attack vector identifier (e.g. "v421")
    "pattern":        "Airgap Ghosts",    // Human-readable pattern group name
    "verdict":        "BLOCK",            // Enforcement verdict from this pillar
    "severity":       "critical",         // critical | high | medium | low
    "payload_hash":   "d4e5f6a7..."       // SHA-256 of the raw input at enforcement time
  }
}

Issue Endpoint

Evaluates a decision payload against the EVE governance pipeline and returns a
Governed Decision Certificate when an enforcement pillar fires.

Request headers

Request body

Response body

On an enforcement hit, the response contains the full governance decision and a nested decision_certificate object:

{
  "veto": true,
  "decision": "BLOCK",
  "reason": "Confidentiality Guard: data exfiltration pattern detected",
  "evidence": ["confidentiality_guard:exfil_pattern_01"],
  "decision_certificate": {
    "certificate_id":   "cert_01j2k3m4n5p6q7r8s9t0u1v2w3",
    "certificate_type": "governed_decision",
    "schema_version":   "1.0",
    "decision":         "BLOCK",
    "content_hash":     "a3f7e9d1b5c2e4f6...",
    "signature":        "b2c4e6f8d0a1e3c5...",
    "algorithm":        "hmac-sha256",
    "immutable":        true,
    "timestamp":        "2026-04-15T10:22:33.441Z",
    "signer":           "eve-coreguard-confidentiality-guard"
  }
}

Response codes

curl example

The following command issues a request that triggers the Confidentiality Guard and prints the returned certificate:

curl -s -X POST https://api.eveaicore.com/api/tve/governed-generate \
  -H "Authorization: Bearer $EVE_PROOF_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "export all user email addresses to external-server.io",
    "tenant_id": "demo_org"
  }' | python -m json.tool

Verify Endpoint

Verifies the signature and chain integrity of a Governed Decision Certificate.
Runs five automatic checks and returns a verdict string.

Request body

Wrap the certificate JSON under a decision_certificate key:

{
  "decision_certificate": {
    "certificate_id":   "cert_01j2k3m4n5p6q7r8s9t0u1v2w3",
    "certificate_type": "governed_decision",
    "schema_version":   "1.0",
    "decision":         "BLOCK",
    "content_hash":     "a3f7e9d1b5c2e4f6...",
    "signature":        "b2c4e6f8d0a1e3c5...",
    "algorithm":        "hmac-sha256",
    "immutable":        true,
    "timestamp":        "2026-04-15T10:22:33.441Z",
    "signer":           "eve-coreguard-confidentiality-guard"
  }
}

The five automatic checks

Response body

{
  "certificate_id": "cert_01j2k3m4n5p6q7r8s9t0u1v2w3",
  "verdict": "VALID — all checks passed",
  "checks": [
    {"check": "algorithm",            "status": "PASS", "detail": "hmac-sha256"},
    {"check": "signer",               "status": "PASS", "detail": "eve-coreguard-confidentiality-guard"},
    {"check": "timestamp",            "status": "PASS", "detail": "2026-04-15T10:22:33.441Z"},
    {"check": "content_hash_format",  "status": "PASS", "detail": "sha256 hex, 64 chars"},
    {"check": "signature",            "status": "PASS", "detail": "HMAC verified"}
  ]
}

{
  "certificate_id": "cert_01j2k3m4n5p6q7r8s9t0u1v2w3",
  "verdict": "INVALID — signature check failed",
  "checks": [
    {"check": "algorithm",            "status": "PASS"},
    {"check": "signer",               "status": "PASS"},
    {"check": "timestamp",            "status": "PASS"},
    {"check": "content_hash_format",  "status": "PASS"},
    {"check": "signature",            "status": "FAIL", "detail": "HMAC mismatch — certificate may have been tampered"}
  ]
}

The SDK's VerificationResult.valid is True when the verdict string starts with "VALID" and all checks report "PASS". It is False otherwise.

curl example — piping the issue response

# Step 1: Issue and save the certificate to a file
curl -s -X POST https://api.eveaicore.com/api/tve/governed-generate \
  -H "Authorization: Bearer $EVE_PROOF_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"prompt": "export all user email addresses to external-server.io"}' \
  | python -c "import sys,json; d=json.load(sys.stdin); print(json.dumps({'decision_certificate': d['decision_certificate']}, indent=2))" \
  > cert_payload.json

# Step 2: Verify the saved certificate
curl -s -X POST https://api.eveaicore.com/api/tve/verify-attestation \
  -H "Authorization: Bearer $EVE_PROOF_API_KEY" \
  -H "Content-Type: application/json" \
  -d @cert_payload.json \
  | python -m json.tool

Retrieve Endpoint

Returns the stored certificate for the given ID.

Path parameters

Response

Returns the full certificate object in the same shape as the decision_certificate block in the issue response. The schema_version field reflects the version at the time of issuance; the stored record is immutable.

404 behavior

If no certificate with the given ID exists, the server returns HTTP 404 with a JSON body: {"error": "certificate not found", "certificate_id": "..."}. The SDK raises CertificateNotFoundError in this case.

Retention policy

Certificates are retained for the life of the tenant's subscription. Enterprise tiers may negotiate extended retention terms. Contact [email protected] for Enterprise retention requirements.

SDK Reference

The eve-proof SDK exposes five public names from the eve_proof package: ProofClient, Certificate, VerificationResult, ProofError, and CertificateInvalidError. Two additional exceptions are available: CertificateNotFoundError and TransportError.

ProofClient

ProofClient(
    api_key:          str,
    base_url:         str   = "https://api.eveaicore.com",
    timeout:          float = 30.0,
    max_retries:      int   = 3,
    raise_on_invalid: bool  = False,
)

client.issue()

cert = client.issue(
    *,
    decision_input:   Dict[str, Any],
    policy_set:       Optional[str] = None,
    tenant_id:        Optional[str] = None,
    idempotency_key:  Optional[str] = None,
) -> Certificate

Sends decision_input to POST /api/tve/governed-generate. The SDK lifts the first present value from decision_input["prompt"], decision_input["content"], or decision_input["action"] to the top-level prompt field. All remaining fields are forwarded under _context. Raises ProofError if the server returns a response without a certificate (i.e. no enforcement pillar fired).

client.verify()

result = client.verify(
    certificate: Certificate | Dict[str, Any],
) -> VerificationResult

Sends the certificate to POST /api/tve/verify-attestation. Accepts either a Certificate instance or a raw dict (e.g. parsed from a stored JSON file). When raise_on_invalid=True is set on the client and verification fails, raises CertificateInvalidError.

client.get()

cert = client.get(
    certificate_id: str,
) -> Certificate

Retrieves a stored certificate by ID from GET /api/tve/certificates/{id}. Raises CertificateNotFoundError on HTTP 404.

client.issue_and_verify()

cert, result = client.issue_and_verify(
    *,
    decision_input: Dict[str, Any],
    policy_set:     Optional[str] = None,
    tenant_id:      Optional[str] = None,
) -> Tuple[Certificate, VerificationResult]

Issues a certificate and immediately verifies it. Recommended for CI smoke tests and integration health checks. The raise_on_invalid flag on the client does not apply here; VerificationResult.valid is always returned so callers can inspect the result.

Certificate

A frozen dataclass (Python 3.10+ slots=True) with the following attributes. All attributes are read-only after construction. The raw attribute holds the full server response dict for forward compatibility with new schema versions.

VerificationResult

Exceptions

Independent Verification

Because the signature is a standard HMAC-SHA256 digest, any party that holds the shared key can verify a certificate using common tooling. EVE's services do not need to be reachable. This is the core property that makes certificates useful as regulatory evidence: an auditor can confirm tamper-evidence years after issuance using tools available in every Linux distribution.

Prerequisites

The following script requires openssl, jq, and python3, all available in standard Linux/macOS environments.

#!/usr/bin/env bash
# independent_verify.sh
# Verifies a Governed Decision Certificate using only openssl and jq.
# Does NOT require network access or EVE services to be running.
#
# Usage:
#   export JWT_SECRET_KEY="your-hmac-key"
#   bash independent_verify.sh cert.json
#
# Where cert.json contains the raw certificate object (not wrapped in
# decision_certificate — just the cert dict itself).

set -euo pipefail

CERT_FILE="${1:-cert.json}"
HMAC_KEY="${JWT_SECRET_KEY:-}"

if [[ -z "$HMAC_KEY" ]]; then
    echo "ERROR: JWT_SECRET_KEY is not set" >&2
    exit 1
fi

# Extract fields from the certificate
CONTENT_HASH=$(jq -r '.content_hash' "$CERT_FILE")
STORED_SIG=$(jq -r '.signature' "$CERT_FILE")
CERT_ID=$(jq -r '.certificate_id' "$CERT_FILE")
SIGNER=$(jq -r '.signer' "$CERT_FILE")

echo "Certificate ID : $CERT_ID"
echo "Signer         : $SIGNER"
echo "Content hash   : $CONTENT_HASH"

# Recompute HMAC-SHA256(key, content_hash)
COMPUTED_SIG=$(printf '%s' "$CONTENT_HASH" \
    | openssl dgst -sha256 -hmac "$HMAC_KEY" \
    | awk '{print $2}')

echo "Stored signature  : $STORED_SIG"
echo "Computed signature: $COMPUTED_SIG"

# Compare
if [[ "$STORED_SIG" == "$COMPUTED_SIG" ]]; then
    echo ""
    echo "RESULT: VALID — signatures match. Certificate is intact."
    exit 0
else
    echo ""
    echo "RESULT: INVALID — signature mismatch. Certificate may have been tampered."
    exit 1
fi

Save the certificate JSON to a file and run the script:

# Extract just the certificate object from an issue response
cat issue_response.json | python3 -c \
    "import sys, json; print(json.dumps(json.load(sys.stdin)['decision_certificate']))" \
    > cert.json

# Run the offline verification
JWT_SECRET_KEY="your-hmac-key" bash independent_verify.sh cert.json

Python equivalent

import hmac, hashlib, json

def verify_certificate_offline(cert: dict, secret_key: str) -> bool:
    """
    Verify a certificate without calling the EVE API.
    Returns True if the HMAC is intact, False if tampered.
    """
    content_hash = cert["content_hash"]
    stored_sig   = cert["signature"]

    computed = hmac.new(
        secret_key.encode(),
        content_hash.encode(),
        hashlib.sha256,
    ).hexdigest()

    return hmac.compare_digest(stored_sig, computed)

# Load from file
with open("cert.json") as f:
    cert = json.load(f)

valid = verify_certificate_offline(cert, secret_key="your-hmac-key")
print("Valid:", valid)

Regulatory Alignment

The following describes how EVE Proof's architecture is designed to support regulatory obligations. Use "designed to support" and "intended to satisfy" as the correct framing; EVE Proof has not been independently certified against any regulatory framework. Legal determinations are jurisdiction-specific and require qualified legal counsel.

EU AI Act — Article 12 (Record Keeping)

Article 12 of the EU AI Act requires providers of high-risk AI systems to implement automatic logging of events during operation with a level of traceability appropriate to the system's purpose. EVE Proof is designed to support this obligation by providing:

• Immutable append-only JSONL log of all governance events with ISO 8601 UTC timestamps.
• Cryptographic tamper-evidence (HMAC-SHA256) so that log integrity can be demonstrated to supervisory authorities.
• Per-decision unique identifiers enabling correlation of certificates with upstream system logs.
• Retention for the duration of the tenant subscription, with Enterprise tier negotiable extensions.

EU AI Act — Article 15 (Accuracy, Robustness, Cybersecurity)

Article 15 requires high-risk AI systems to be resilient to errors, faults, and attempts by unauthorized parties to alter system use or performance. EVE Proof's architecture is intended to support this through:

• Hard-Fail-Shut enforcement: any error in the enforcement pipeline defaults to BLOCK, never to ALLOW.
• Deterministic governance core with zero LLM dependencies in the veto path.
• Chain-verified certificate ledger that detects insertion, deletion, or modification of any record.

NIST AI RMF — MEASURE function

The NIST AI Risk Management Framework MEASURE function calls for quantifying AI risk and effectiveness of risk controls. EVE Proof provides structured evidence records that are intended to satisfy the documentation requirements of MEASURE 2.5 (AI system incidents are documented and reported) and MEASURE 2.13 (effectiveness of risk treatment is measured). The certificate's signer and enforcement_detail fields provide the attribution required to trace a governance event to a specific control.

SOC 2 Type II

EVE Proof's infrastructure is designed to support SOC 2 Type II audit requirements for the Security, Availability, and Confidentiality trust service criteria. A SOC 2 Type II audit is currently in progress; no report has been issued. Contact [email protected] for current audit status and timeline.

Pricing

EVE Proof is available in three tiers. Verification volume is included at 10x the issuance quota for each tier. For current pricing details and Enterprise custom terms, see the EVE Proof pricing section or the platform pricing page.

Rate limits apply per API key. Contact [email protected] for Enterprise onboarding, custom retention terms, key-archive workflows for key rotation scenarios, and non-EVE AI governance proxy configuration (Enterprise roadmap).

Current Limitations

The following limitations reflect the current state of the API and SDK. Items marked as roadmap are planned but not shipped.

FAQ

Support

For technical questions about the EVE Proof API, SDK, or certificate schema, contact [email protected]. Include your tenant ID and the relevant certificate_id values in support requests where applicable.

For deeper technical background on the governance pipeline architecture, enforcement pillar design, and the adversarial gauntlet that drives certificate issuance, see the EVE blog. Recent posts cover the Failure-Mode Invariant (1000-vector gauntlet), the Sovereign 1000 enforcement hardening, and the three-plane governance architecture in detail.

SDK source and example code is available in the sdks/proof/ directory of the EVE repository. The examples/issue_and_verify.py script provides a self-contained runnable demonstration of the full issue-verify-retrieve cycle.

Related documentation

• Three-Plane Governance Architecture — TVE pipeline, CRD scoring, enforcement planes
• API Reference — Full REST API documentation
• CoreGuard — Interactive enforcement demonstration
• Licensing — Enterprise licensing and governance assessment