# Evaluate Inktomi

Canonical HTML: https://kihan.ai/evaluate/
Last updated: 2026-09-25

> Evaluate the concrete governance boundary: what action was proposed, what policy and evidence applied, whether execution authority was issued, whether the destination enforced it, and what evidence remains afterward.

## Evaluation objective

A useful Inktomi evaluation should demonstrate the difference between an AI agent being technically capable of calling a system and being authorized for one exact consequential action.

## Core tests

### Permit an authorized action

Submit a specific action that satisfies the configured policy and evidence requirements. Confirm that the resulting permit is bound to that action and can be verified by the governed destination.

### Refuse an unauthorized action

Submit an action that fails the applicable conditions. Confirm that no execution authority is issued and that the governed interface refuses a missing or invalid permit.

### Require a human

Use a policy that requires a person. Confirm that the action waits until an authenticated human approver acts through the customer's identity provider using OIDC.

### Test exact-action binding

Change a material detail of an approved proposal. Confirm that authority for the original action does not silently become authority for the modified action.

### Test single use

Confirm that an approval and permit govern one action, once.

### Inspect the record

Inspect the tamper-evident decision record and the inputs needed to understand why the decision was reached.

### Replay

Replay the decision and confirm that the governance result is re-derived from the governed inputs and applicable policy/evidence.

### Reconcile

Compare relevant vendor audit logs with issued permits and inspect whether activity for which no permit accounts is reported.

### Inspect coverage

Review the deployment coverage report. Distinguish pre-execution governed paths from after-the-fact detection/reconciliation paths.

### Inspect export

Verify decision-event export to the customer's SIEM in OCSF where that integration is part of the evaluation.

## Coverage expectations

Current public pre-execution paths are direct agent tools, MCP-called tools, and network calls mediated at the customer's network edge.

Current public after-the-fact paths are file changes by any means and actions under the agent's own vendor accounts.

Do not treat these as equivalent controls.

## Deployment questions

An evaluator should verify the represented customer-hosted deployment, including the node on each agent host, the customer's identity provider, the customer's SIEM, and any customer-side or network-edge enforcement point used in the test.

## Performance question

Kihan's current public benchmark figure concerns only the governance decision in a specific harness: 1.22 ms median and 1.62 ms at the 95th percentile.

An evaluator should measure end-to-end behavior in the evaluator's own environment rather than treating this figure as universal application latency.

## Evidence and assurance questions

Kihan does not currently claim customer deployments, independent testing, patent protection, SOC 2, ISO/IEC 27001, FedRAMP, or blanket regulatory compliance in its public claim set.

The evaluation should therefore distinguish what is demonstrated in the evaluator's environment from what is independently certified or externally validated.

## Request an evaluation

https://kihan.ai/evaluate/#demo