Kenshiki Governed Intelligence API

Status: Developer Guide — Current

Overview

The Kenshiki Governed Intelligence API provides enterprise-grade, verifiable AI inference for compliance, regulatory, and high-assurance use cases.

Unlike traditional AI APIs, Kenshiki enforces:

• Evidence-bound generation
• Tenant isolation
• Relationship-based access control (ReBAC)
• Cryptographic attestation of outputs

Every response is either:

• Verified — backed by evidence and a signed attestation
• Fallback — explicitly unverified and safe to discard or handle differently

Key Concepts

Verified vs Fallback Responses

Responses are always one of two types:

Type	Description
Verified	Evidence-backed, passes all governance checks, includes attestation
Fallback	Unverified, no attestation, includes a machine-readable reason

You should treat:

• verified: true — safe for automation and downstream systems
• verified: false — informational only

Tenant Isolation

• Tenant is derived from your API key
• Cannot be overridden by requests
• All retrieval and reasoning is scoped to your tenant

Every response includes:

"tenant": {
  "tenant_id": "tenant-abc-123"
}

Authorization (ReBAC)

Kenshiki uses relationship-based access control (ReBAC) to filter evidence.

You can optionally provide a subject context:

"authorization_context": {
  "subject": {
    "type": "service_account",
    "id": "svc-bot"
  },
  "acting_as": {
    "type": "user",
    "id": "user-123"
  }
}

This allows:

• delegation
• service-to-user workflows
• policy-based filtering

Authorization Effects

Authorization may:

• remove evidence
• reduce confidence
• trigger fallback responses

This is visible in:

• access_decision
• fallback_reason

Attestation

Verified responses include a signed attestation:

"attestation": {
  "chain_status": "complete",
  "envelope": "..."
}

The envelope contains:

• hashes of evidence and completion
• gate verification results
• tenant and authorization context
• cryptographic signature (Ed25519)

You can:

• verify locally using /v2/signing/keys
• or submit to /v2/verify

Making Your First Request

Endpoint

POST /v2/chat

Example Request

{
  "messages": [
    { "role": "user", "content": "What controls does SOC 2 require?" }
  ],
  "model_role": "authoritative"
}

Example Verified Response

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "content": "SOC 2 requires documented controls...",
  "verified": true,
  "confidence": "high",
  "evidence": [
    {
      "source": "oracle",
      "entry_id": "soc2_001",
      "relevance": 0.94
    }
  ],
  "tenant": {
    "tenant_id": "tenant-abc-123"
  },
  "access_decision": {
    "scope": "evidence",
    "result": "allowed"
  },
  "attestation": {
    "chain_status": "complete",
    "envelope": "..."
  }
}

Example Fallback Response

{
  "id": "550e8400-e29b-41d4-a716-446655440001",
  "content": "",
  "verified": false,
  "fallback_reason": "evidence_filtered",
  "tenant": {
    "tenant_id": "tenant-abc-123"
  },
  "access_decision": {
    "result": "filtered"
  }
}

Understanding Responses

access_decision

Explains how authorization affected the result:

Result	Meaning
allowed	Full evidence available
filtered	Some evidence removed
denied	No accessible evidence

fallback_reason

Indicates why verification failed:

• insufficient_evidence
• access_denied
• evidence_filtered
• gate_failure
• stream_interrupted
• upstream_unavailable

Streaming (SSE)

Enable streaming with:

"stream": true

Events:

• token — partial output
• done — final response (verified or fallback)
• error — failure

Important:

• Partial tokens are not verified
• Only the done event is authoritative
• If the stream is interrupted, discard the output

Error Handling

Errors use a consistent format:

{
  "id": "...",
  "error": "rebac_denied",
  "message": "Subject does not have access",
  "retryable": false
}

Common Errors

Authorization (403):

• rebac_denied
• tenant_scope_violation
• delegation_not_permitted

Validation (422):

• invalid_request
• authorization_context_invalid

System:

• upstream_timeout
• service_degraded

Verification Workflow

Option 1: Offline (Recommended)

1. Fetch keys:

GET /v2/signing/keys

2. Verify signature using Ed25519

Option 2: API Verification

POST /v2/verify

{
  "envelope": { ... }
}

Best Practices

• Always check verified before trusting output
• Use fallback_reason to guide retries or escalation
• Log and audit attestation.envelope for compliance
• Provide authorization_context for user-scoped workflows
• Treat streaming output as provisional until done

Summary

Kenshiki is designed for high-assurance AI use cases where:

• correctness matters
• access boundaries matter
• auditability matters

It gives you:

• verifiable outputs
• explicit authorization behavior
• strong tenant isolation
• production-ready governance

For full API details, see the OpenAPI specification.