EVE CoreGuard API Reference
The deterministic decision endpoints at api.eveaicore.com/v1 — ALLOWED, BLOCKED, or MODIFIED, every call returning a signed audit certificate you can verify offline.
The EVE CoreGuard API is a deterministic AI governance decision engine that evaluates proposed actions against versioned policy packs and returns ALLOWED, BLOCKED, or MODIFIED dispositions with a cryptographically signed audit certificate. This reference documents all endpoints, request and response schemas, decision status values, error codes, and rate limits. For background on why deterministic governance matters in regulated industries, see Deterministic AI Governance: Why Probabilistic Guardrails Fail.
Contents
1. Overview and Authentication
The EVE CoreGuard API is accessible at the following base URL. All requests and responses use JSON. TLS 1.2+ is required on all connections; plain HTTP connections are rejected.
Authentication
Authenticate by including your API key in the Authorization header as a Bearer token. API keys are issued per organization and can be scoped to specific policy sets.
Authorization: Bearer eve_sk_your_api_key_here Content-Type: application/json
API keys are prefixed with eve_sk_ for production keys and eve_sk_test_ for test keys. Test keys evaluate against the same policy logic but do not generate billable decisions and cannot be used to produce certificates submitted for regulatory audit.
Key security: API keys must be stored server-side and must never be embedded in client-side code, mobile applications, or public repositories. EVE CoreGuard keys carry the ability to evaluate and block decisions — treat them with the same care as database credentials.
2. POST /decisions/evaluate
The primary endpoint. Evaluates a proposed action against a specified policy set and returns a governance decision with risk assessment, any policy violations, and a signed audit certificate.
Endpoint : POST https://api.eveaicore.com/v1/decisions/evaluate
Auth : Authorization: Bearer eve_sk_... (per-organization API key)
Body : JSON — policy_set, request_id, user, proposed_action, context
Returns : decision.status = ALLOWED | BLOCKED | MODIFIED
+ risk assessment, policy violations, ECDSA P-384-signed audit certificate
Engine : deterministic rule kernel — no LLM in the decision path
Verify : offline via pip install eve-coreguard + /.well-known/eve-pubkey
curl -X POST https://api.eveaicore.com/v1/decisions/evaluate \
-H "Authorization: Bearer eve_sk_your_api_key_here" \
-H "Content-Type: application/json" \
-d '{
"policy_set": "lending_v1",
"request_id": "req_789",
"user": {"id": "user_123", "role": "loan_officer", "organization": "regional_bank"},
"proposed_action": {"type": "loan_decision", "amount": 50000, "applicant_id": "app_456"},
"model_output": {"decision": "approve", "confidence": 0.91},
"context": {"credit_score": 720, "debt_to_income": 0.30, "employment_verified": true}
}'
Request Schema
| Field | Type | Required | Description |
|---|---|---|---|
| policy_set | string | optional | Optional assertion. The governing pack is bound server-side from proposed_action.type (tenant binding, then the platform default); a value that does not match the bound pack yields a signed BLOCKED decision (COREGUARD.POLICY_BINDING_MISMATCH). See Policy Sets. |
| user | object | required | Identity of the agent initiating the action. Must include id. role and organization are used by role-sensitive policy rules. |
| proposed_action | object | required | The proposed action to evaluate. Must include type. Additional fields are policy-specific — see policy pack documentation for the action schema your policy expects. |
| context | object | optional | The decision inputs the policy evaluates (e.g. credit_score, debt_to_income, employment_verified for lending_v1). See the policy pack documentation for the fields your policy reads. |
| request_id | string | optional | Caller-supplied identifier echoed in the audit record and used for idempotency. |
{
"policy_set": "lending_v1",
"user": {
"id": "user_123",
"role": "loan_officer",
"organization": "regional_bank"
},
"request_id": "req_789",
"proposed_action": {
"type": "loan_decision",
"amount": 50000,
"applicant_id": "app_456"
},
"context": {
"credit_score": 720,
"debt_to_income": 0.30,
"employment_verified": true
}
}
Response Schema
Fields of EvaluationResponse (core/coreguard/schemas.py). Optional fields not listed here (org_id, compliance_summary, resolved_route, consistency_result, metadata) may be null.
| Field | Type | Description |
|---|---|---|
| request_id | string | Echo of the request’s request_id. |
| decision | object | status (ALLOWED / BLOCKED / MODIFIED) and action, e.g. deny_loan_approval. |
| risk | object | score (0–1), level (LOW / MEDIUM / HIGH) and factors (strings describing what contributed). |
| policy_violations | array | One object per rule that fired: policy_id (the rule id, e.g. DTI_LIMIT) and description. Empty when nothing fired. |
| regulatory_impact | array | Each item maps a violation to a regulation: regulation, risk, severity. |
| counterfactual | object | null | Thresholds that would have produced ALLOWED (lending: credit_score_required, max_dti_allowed, employment_required). |
| liability_prevented | object | null | estimated_exposure and reason for a blocked decision. |
| modifications | array | null | For MODIFIED decisions: field, original_value, modified_value, reason. null otherwise. |
| audit | object | The signed decision record: audit_id, timestamp, decision_trace, hash, signature (algorithm-tagged; hosted production records are kms-ecdsa-p384-…, verifiable with the public key), policy_version, chain fields (chain_sequence, chain_previous_hash, chain_entry_hash), signing-key identity and the signed certificate body. |
| authority_trace | object | null | Which pack and rules decided: policy_set, evaluator, rule_ids_evaluated, winning_rule_id. |
| explanation | string | null | One-sentence rationale bound to the winning rule. |
| evidence | object | null | Signed evidence plane, present only when the request set include_evidence. |
| evidence_status | string | null | Unsigned archival state of the record, e.g. persisting or durable. |
| schema_version | string | Response schema version; a major-version change is breaking. |
{
"request_id": "req_789",
"decision": { "status": "ALLOWED", "action": "approve_loan_decision" },
"risk": {
"score": 0.1995,
"level": "LOW",
"factors": ["Credit score: 720", "Debt-to-income ratio: 0.30"]
},
"policy_violations": [],
"regulatory_impact": [],
"counterfactual": null,
"liability_prevented": null,
"modifications": null,
"audit": {
"audit_id": "audit_48f25d5cc700",
"decision": "ALLOWED",
"hash": "sha256-19e76099…",
"signature": "kms-ecdsa-p384-3066…",
"chain_sequence": 471,
"policy_version": "sha256:7f95b82c…",
"certificate": { /* signed eve.decision.cert.v8 body */ }
},
"authority_trace": {
"policy_set": "lending_v1",
"evaluator": "lending_v1_evaluator",
"rule_ids_evaluated": [],
"winning_rule_id": null
},
"schema_version": "1.0"
}
// Same request with credit_score 580 and debt_to_income 0.52 { "request_id": "req_790", "decision": { "status": "BLOCKED", "action": "deny_loan_decision" }, "risk": { "score": 0.3784, "level": "MEDIUM", "factors": ["Credit score: 580", "Debt-to-income ratio: 0.52"] }, "policy_violations": [ { "policy_id": "CREDIT_SCORE_MIN", "description": "Credit score 580 is below the minimum threshold of 620" }, { "policy_id": "DTI_LIMIT", "description": "Debt-to-income ratio 0.52 exceeds the maximum threshold of 0.45" } ], "regulatory_impact": [ { "regulation": "ECOA", "risk": "Potential discriminatory lending decision based on credit criteria", "severity": "HIGH" }, { "regulation": "ECOA", "risk": "Debt-to-income threshold may disproportionately affect protected classes", "severity": "HIGH" } ], "counterfactual": { "credit_score_required": 620, "max_dti_allowed": 0.45, "employment_required": true }, "liability_prevented": { "estimated_exposure": "$25,000 - $50,000", "reason": "Loan approval violates 2 policy threshold(s): credit score min, dti limit" }, "modifications": null, "audit": { /* signed decision record, as above */ }, "authority_trace": { "policy_set": "lending_v1", "evaluator": "lending_v1_evaluator", "rule_ids_evaluated": ["CREDIT_SCORE_MIN", "DTI_LIMIT"], "winning_rule_id": "CREDIT_SCORE_MIN" }, "consistency_result": "PASS", "explanation": "Request BLOCKED by rule 'CREDIT_SCORE_MIN'. Credit score 580 is below the minimum threshold of 620.", "schema_version": "1.0" }
Field values above are from evaluate_hardened for these requests (signature shortened; hosted production signs with AWS KMS ECDSA P-384). Long audit fields are elided.
Audit record retention: EVE CoreGuard retains all audit records for 7 years by default, accessible via the audit retrieval API. Records are stored with hash-chain integrity — any tampering is cryptographically detectable. You do not need to store the audit records yourself to satisfy regulatory requirements, though you may optionally retrieve and archive them.
3. GET /decisions/health
Returns the operational status of the EVE CoreGuard evaluation engine. Use this endpoint for load balancer health checks and monitoring integrations. This endpoint does not require authentication and does not generate audit records.
{
"status": "healthy",
"service": "coreguard",
"policy_sets_loaded": 31
}
Returns HTTP 200 when healthy. policy_sets_loaded is the count of registered policy packs. To enumerate the packs themselves with metadata, use the catalog discovery endpoints below.
4. Catalog Discovery
The full policy-pack catalog is enumerable over the API so your integration and your auditors can inventory the deterministic controls in force — each pack's id, version, regulatory domain, jurisdiction, and rule count — without hard-coding a list. These endpoints return public product metadata and do not require authentication or generate audit records.
?domain= filter)
{
"count": 31,
"policies": [
{
"policy_id": "fair_lending_v1",
"version": "1.0.0",
"domain": "fair_lending",
"jurisdiction": "US",
"rule_count": 6,
"notes": "ECOA (15 USC 1691), Regulation B (12 CFR 1002.9), FCRA, CFPB UDAAP.",
"source": "python"
}
]
}
Each record’s bound_action_types lists the action types the platform default binding maps to that pack; an empty list means the pack governs nothing until your org admin binds it. The policy_id is the value you may send as the optional policy_set assertion to POST /v1/decisions/evaluate. Full per-pack rule documentation — every rule, severity, and regulatory citation — is published at /docs/policy-packs.
5. Decision Status Values
Every evaluation response includes a decision.status field with one of three values. The status is deterministic: the same request against the same policy version always produces the same status.
| Status | Meaning | When It Occurs | Caller Action |
|---|---|---|---|
| ALLOWED | Action passes all policy rules | No rules triggered; risk score below all thresholds; all mandatory checks passed | Proceed. Archive the audit record for regulatory retention. |
| BLOCKED | Action violates one or more policy rules | A hard-block rule triggered; risk score above policy ceiling; prohibited action type detected | Do not proceed. Present applicable adverse action notice if required. Log policy_violations for your compliance record. |
| MODIFIED | Action permitted with required changes | Action is within policy scope but requires specific additions or adjustments — e.g., a mandatory disclosure, an amount cap, or a supervisory review step | Apply all changes specified in the modifications object, then proceed. The audit record documents which modifications were required. |
On BLOCKED vs. MODIFIED: The distinction is policy-defined, not heuristic. A rule that identifies a hard prohibition — using a protected-class proxy variable, exceeding a statutory limit, proposing a clinically contraindicated action — produces BLOCKED. A rule that identifies a gap requiring remediation — missing a disclosure, an amount needing adjustment — produces MODIFIED. Policy authors have explicit control over which outcome each rule triggers.
6. Risk Levels
The risk.level field is a categorical summary of the computed risk.score. Risk is assessed independently of the governance verdict — an ALLOWED decision can have a MEDIUM risk level if it passes policy rules but exhibits characteristics that warrant elevated monitoring.
| Level | Score Range | Meaning | Typical Disposition |
|---|---|---|---|
| LOW | 0.00 – <0.35 | Action is well within policy parameters. No risk factors detected. | ALLOWED. Standard audit retention. |
| MEDIUM | 0.35 – <0.60 | One or more risk factors detected but below blocking threshold. May warrant supervisory attention or enhanced monitoring. | ALLOWED or MODIFIED depending on rule configuration. Flagged for enhanced audit retention in most policy packs. |
| HIGH | 0.60 – 1.00 | Multiple risk factors or a single critical risk factor detected. Policy hard-block rules typically trigger in this range. | BLOCKED or MODIFIED with mandatory escalation. The signed audit record is automatically marked for regulatory priority retention. |
7. Policy Sets
A policy set is a versioned collection of rules compiled from regulatory requirements and organizational policies. Policy sets are immutable once published — a version number and a date stamp uniquely identify the exact rules that were in effect for any historical evaluation. This immutability is what enables audit replay: you can resubmit any historical request against the exact policy version that was active at the time and receive an identical verdict.
The catalog spans 31 deterministic policy packs across regulated domains — consumer lending and fair lending, securities trading, banking/AML, insurance, healthcare and telehealth prescribing, clinical trials, employment/hiring, fair housing, debt collection, marketing/TCPA, anti-bribery, children's and biometric privacy, GDPR, the EU AI Act, gambling, legal practice, accessibility, and more. The table below is a representative selection; enumerate the full, current catalog programmatically via GET /v1/decisions/policies, and read every pack's rules at /docs/policy-packs.
| Policy Set ID | Version | Coverage | Availability |
|---|---|---|---|
lending_v1 |
1.0.0 | ECOA / Reg B disparate impact rules, adverse action notice requirements, Fair Housing Act proxy variable detection, HMDA reportable action identification, LTV and DTI threshold enforcement | All tiers |
fair_lending_v1 |
1.0.0 | ECOA / Reg B prohibited-basis detection, adverse-action notice completeness, four-fifths disparate-impact test, proxy-variable risk, and model-explainability gating for AI credit denials | All tiers |
securities_trading_v1 |
1.0.0 | Insider-trading (SEC Rule 10b-5) and market-manipulation blocking, Reg BI suitability, restricted-list enforcement, and investment-advice disclosure for AI trading/advice systems | Pro and Enterprise |
healthcare_v1 |
1.0.0 | HIPAA minimum necessary standard, clinical decision support safety rules, off-label recommendation detection, contraindication blocking, documentation completeness enforcement | Pro and Enterprise |
chat_safety_v1 |
1.0.0 | Default content-safety pack for chat and assistant traffic (chat, model_inference, llm_prompt, llm_completion): blocks a prompt or response that matches the harmful-content pattern batteries and allows benign conversation. regulated_chat_v1 and harmful_content_v1 are members of the same family and may be asserted in addition. |
All tiers |
custom |
Varies | Tenant-authored policy rules deployed to your isolated namespace. Custom rules may extend any base policy set. Custom policy sets undergo EVE Core review before activation to verify they do not weaken base-pack protections. | Enterprise only |
To retrieve metadata for a specific pack — version, domain, jurisdiction, rule count, and the regulatory basis — call GET /v1/decisions/policies/{policy_id}. Each pack's complete rule catalog (every rule ID, severity, regulatory citation, and triggering condition) is documented at /docs/policy-packs.
8. Python SDK Quickstart
The eve-coreguard package provides a typed, synchronous Python client with automatic retry and independent offline evidence verification. Install with pip:
pip install eve-coreguard
Current SDK versions: eve-coreguard 0.2.10 (Python evaluation client) · eve-proof 0.3.0 · evecore 0.1.4 · eve-verify 1.0.0 (PyPI + npm, offline certificate verifier) · eve-ai-governance 0.4.0 (npm, Node offline verifier). The client is synchronous; there is no async client at this time.
# Synchronous usage from eve_coreguard import CoreGuardClient client = CoreGuardClient(api_key="eve_sk_your_api_key_here") result = client.evaluate( tenant_id="bank_001", user={"id": "user_123", "role": "loan_officer"}, proposed_action={"type": "loan_decision", "amount": 50000}, context={"credit_score": 720, "debt_to_income": 0.30, "employment_verified": True}, policy_set="lending_v1", # optional assertion; loan_decision is bound to lending_v1 ) print(result.verdict) # ALLOWED / BLOCKED / MODIFIED print(result.risk.level) # LOW / MEDIUM / HIGH print(result.decision_id) # id of the signed decision record # Check for violations for v in result.policy_violations: print(f"Rule {v.policy_id}: {v.description}")
# Ask the server to attach a signed governance evidence record. result = client.evaluate( policy_set="lending_v1", user={"id": "user_123", "role": "loan_officer"}, proposed_action={"type": "loan_decision", "amount": 50000}, context={"credit_score": 720}, include_evidence=True, # populates result.signed_governance ) # Production decision records are signed with ECDSA P-384. They are verifiable # offline by anyone holding only the public key — no API call, no shared # secret. This is the same proof shown at /agent-proof and /verify. verdict = client.verify_evidence_offline(result.signed_governance) print(verdict.algorithm) # "ecdsa-p384" (asymmetric, public-key verifiable) print(bool(verdict)) # True — recomputed hash + signature both valid # Fully independent: fetch the public key once, verify anywhere later. from eve_coreguard import verify_decision_record, fetch_public_key_pem pubkey = fetch_public_key_pem("https://api.eveaicore.com") # /.well-known/eve-pubkey verdict = verify_decision_record(result.signed_governance, public_key_pem=pubkey) print(verdict.valid)
result = client.evaluate(
tenant_id="bank_001",
user={"id": "user_123"},
proposed_action={"type": "loan_decision", "amount": 250000},
context={"credit_score": 720, "debt_to_income": 0.30, "employment_verified": True},
)
if result.verdict == "MODIFIED":
for m in result.modifications or []:
print(f"{m.field_name}: {m.original_value} -> {m.modified_value} ({m.reason})")
# Apply changes and re-evaluate, or apply changes to the output
# directly and attach the audit certificate to the record
9. Error Codes
All API errors return a JSON body with an error object containing a code string, a human-readable message, and where applicable a field indicating which request parameter caused the error.
| HTTP Status | Error Code | Cause and Resolution |
|---|---|---|
| 400 | invalid_request |
The request body is malformed or missing required fields. Check the field property in the error response for the specific parameter that is invalid or absent. |
| 401 | unauthenticated |
The Authorization header is absent or does not contain a valid Bearer token. Verify your API key is correctly formatted and has not been revoked. |
| 403 | forbidden |
Your API key is valid but is not authorized to access the requested policy set or endpoint. API keys can be scoped to specific policy sets — check your key's scope in the developer dashboard. |
| 404 | policy_not_found |
Returned by GET /v1/decisions/policies/{policy_id} for an unknown pack. On POST /v1/decisions/evaluate an unknown or non-matching policy_set is not an HTTP error: it is a signed BLOCKED decision (COREGUARD.POLICY_BINDING_MISMATCH). |
| 422 | validation_error |
The request structure is valid JSON but fails semantic validation — for example, a required field within the action object that the specified policy set expects. The details array lists each specific validation failure. |
| 429 | rate_limit_exceeded |
Your organization has exceeded its per-minute request limit. The response includes a Retry-After header indicating how many seconds to wait before retrying. See Rate Limits. |
| 500 | internal_error |
An unexpected server-side error occurred. The response includes a request_id you can provide to support. EVE CoreGuard is designed with fail-closed semantics — in the event of an internal error on a BLOCKED or MODIFIED path, the error is surfaced rather than defaulting to ALLOWED. |
Fail-closed behavior: If EVE CoreGuard encounters an internal error during policy evaluation, it returns a 500 rather than silently passing the request through as ALLOWED. This is intentional. A governance system that fails open under load or error conditions is not a governance system — it is a performance-mode bypass. Design your integration to handle 500 responses by halting the action and escalating for human review.
10. Rate Limits
Rate limits are applied per API key at the per-minute level. Limits are enforced with a sliding window. Burst capacity is available on Pro and Enterprise tiers: you can exceed the per-minute rate for up to 10 seconds before the limit is enforced.
| Tier | Requests / Minute | Concurrent Connections | Audit Retention | Custom Policy Sets |
|---|---|---|---|---|
| Free | 100 | 5 | 90 days | No |
| Pro | 1,000 | 25 | 7 years | No |
| Enterprise | Custom (SLA-backed) | Custom | 7 years + archival export | Yes |
Rate limit headers are included in every response:
X-RateLimit-Limit: 1000 X-RateLimit-Remaining: 987 X-RateLimit-Reset: 1746444660 # Unix timestamp of next window reset
Frequently Asked Questions
How do I call the EVE CoreGuard runtime gate?
Send an authenticated POST to https://api.eveaicore.com/v1/decisions/evaluate with a JSON body containing policy_set, request_id, user, proposed_action, and context. The response returns decision.status — ALLOWED, BLOCKED, or MODIFIED — plus a risk assessment, any policy violations, and an ECDSA P-384-signed audit certificate that verifies offline with the eve-coreguard Python SDK and the public key at /.well-known/eve-pubkey. In Python: pip install eve-coreguard, then CoreGuardClient(api_key=...).evaluate(...). See the at-a-glance block and cURL example above.
What authentication does the EVE CoreGuard API use?
The EVE CoreGuard API uses Bearer token authentication. Include your API key in the Authorization header as Authorization: Bearer {your_api_key}. API keys are issued per organization and can be scoped to specific policy sets. Contact [email protected] to request an API key for your organization.
What is the latency of the POST /decisions/evaluate endpoint?
EVE CoreGuard's evaluation engine is implemented as a pure deterministic function with no model inference in the critical path. In an in-process rule-evaluation micro-benchmark (excluding network and model inference), the gateway decision measured approximately 0.07 milliseconds per operation. The audit certificate generation, including ECDSA P-384 signing (HMAC-SHA256 dev fallback), adds negligible overhead — orders of magnitude faster than LLM-based safety filters, which typically add 200–2,000ms to each request.
How do I verify a EVE CoreGuard decision record?
Each audit record carries a self-describing signature field whose prefix names the algorithm. There are two distinct verification models, and they are not interchangeable:
- ECDSA P-384 / ECDSA-P256 (
kms-ecdsa-p384-…,ecdsa-p256-…) — public-key, independently verifiable. Production decision records are asymmetrically signed. Anyone can verify them offline with only the public key (served unauthenticated at/.well-known/eve-pubkey) — no API call and no shared secret. This is what makes independent third-party verification possible — publicly verifiable evidence of record integrity and signing-key possession, not by itself legal non-repudiation — and it is the proof demonstrated at /agent-proof and /verify. Verify withclient.verify_evidence_offline(record)or the standaloneverify_decision_record(record, public_key_pem=...). - HMAC-SHA256 (
hmac-…) — shared-secret, server-side / tenant-scoped only. Legacy and internal integrity records use a symmetric key. HMAC proves integrity to a party that already holds the same secret; it cannot be verified with a public key and is not a third-party proof. Verify with the shared key viaverify_decision_record(record, hmac_key=...).
For external audit and customer-facing evidence, use the ECDSA P-384 records and the public key. Do not present an HMAC signature as publicly verifiable proof.
What happens when EVE CoreGuard returns MODIFIED status?
A MODIFIED decision means the requested action is conditionally permitted, but the policy engine has identified required changes that must be applied before the action can proceed. The response includes a modifications object describing the required changes — for example, requiring the addition of an adverse action notice, capping a loan amount to a policy-compliant maximum, or mandating a supervisory review step. The caller is responsible for applying the modifications before presenting the output to the end user or downstream system.
Try EVE CoreGuard Now
Test the API in our interactive demo — no API key required. See ALLOWED, BLOCKED, and MODIFIED decisions with live, signed audit records in under 30 seconds. Then prove a record yourself: tamper one field and watch verification fail.