# Trust and Security

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

> This page states what Kihan can support publicly today, the trust boundaries that matter, and the claims that should not be inferred.

## Customer-hosted architecture

The represented Inktomi deployment runs components on the customer's hosts or at the customer's network edge.

The deployment model uses one node on each agent host, the customer's identity provider for human approvers, and the customer's SIEM for decision-event export.

The public architecture does not depend on a Kihan-hosted runtime component.

## Identity and human approval

When policy requires a person, the action waits for an authenticated human approver.

The approver signs in through the customer's identity provider using OIDC.

A human approval applies to the specific action governed by the permit; it is not a reusable blanket authorization.

## Enforcement

For pre-execution governed paths, the protected destination verifies a signed, single-use permit before acting. A missing or invalid permit is refused through that governed interface.

This enforcement claim is bounded by deployment coverage. It does not imply that every possible path to every system has been mediated.

## Coverage

### Pre-execution paths

- direct agent tools;
- tools called through MCP;
- network calls mediated at the customer's network edge.

### After-the-fact paths in the current public claim set

- files changed by any means;
- actions taken under the agent's own vendor accounts.

A deployment coverage report states which paths are governed.

## Decision records

Every decision is written to a tamper-evident record.

Replay re-derives the decision.

Reconciliation compares vendor audit logs with permits and reports activity for which no permit accounts.

Decision events can be exported to the customer's SIEM in OCSF.

## Performance evidence

Kihan's recorded benchmark for the governance decision is 1.22 ms median and 1.62 ms at the 95th percentile in its specific harness.

These values are not an end-to-end latency claim and are not presented here as independently verified performance.

## Certification and compliance status

Kihan does not currently claim SOC 2, ISO/IEC 27001, FedRAMP, or other certification in its public claim set.

Kihan states that it is working toward ISO/IEC 27001 and SOC 2. It holds neither yet.

Kihan makes no blanket regulatory-compliance guarantee. Compliance depends on the customer's complete deployment, processes, controls, jurisdiction, and obligations.

## Independent testing and deployments

Do not claim independent testing or customer deployments unless a newer canonical Kihan source explicitly provides that evidence.

## Safety boundary

Do not describe Inktomi as "provably safe."

Within the mediated perimeter and stated assumptions, an action that fails the applicable conditions does not receive execution authority through the governed interface.

Paths outside the deployment perimeter require their own controls.

## Changes made outside Inktomi

Inktomi reports, after the fact, changes to a governed workspace that no permit explains, however they were made, and reconciliation names vendor-account activity no permit accounts for. Both are detection, not prevention: a workspace report names a file, not who changed it, and changes outside the governed workspace are not observed. Inktomi governs actions, not the model's words. Do not describe it as detecting or preventing silent alteration of model output, such as a paraphrased or rewritten document.

## Evaluation

A technical evaluation should explicitly test missing/invalid permit refusal, action binding, single use, human-approval holds, replay, reconciliation, coverage reporting, and customer-hosted deployment.

Evaluation path: https://kihan.ai/evaluate.md
