Trust & security
Trust and security.
What Inktomi does to protect your operations, where its limits are, and how to report a vulnerability.
Where it runs
Inktomi runs on your hosts: the decision service, the MCP proxy, the journal, the permit verifier and your own console. Decisions, approvals, the journal and signing keys stay on your infrastructure, and nothing is sent to Kihan. Data leaves only to destinations you configure, such as your SIEM or an approval webhook.
Identity and approval
Every agent that calls Inktomi must present a credential; the identity an agent claims in its own request is ignored. Approvers sign in through your identity provider over OIDC, and only people on a named approver list can approve. If the provider cannot be reached, approvals are refused, not waved through.
Enforcement
A tool behind the Inktomi proxy, or one that checks permits itself, refuses any call without a valid permit. A permit is signed, lasts 60 seconds, can be used once, and is bound to the exact action, the tool and the tenant. The service will not start unless its policy has been signed offline through your change control.
Evidence
Every decision is written to the journal before the agent gets an answer. Records are encrypted and chained, and the chain is anchored to the policy in force, so an altered or missing record is detected when the journal is opened. Replay re-derives every decision from the recorded input and must reach the same result. Reconciliation compares tools’ own logs with the journal and names the caller behind any effect no permit accounts for. Decisions export to your SIEM as OCSF 1.9.0 events.
Coverage
Inktomi governs the tools routed through it. Paths outside a deployment need their own controls, and a coverage report shows which paths a deployment governs, saying “unknown” where it cannot tell. Inktomi governs actions, not model output.
Cryptography
Records are encrypted with AES-256-GCM and chained with HMAC-SHA384. Permits, decisions and policy are signed with ECDSA P-256. Migration to NIST post-quantum algorithms (ML-DSA, ML-KEM) is under way. Approver sign-in relies on your identity provider’s ID-token signature (RS256 or ES256), which is not quantum-resistant today; that algorithm is the provider’s choice, and Inktomi will accept post-quantum ID tokens as providers adopt them.
Release integrity
Release bundles ship with SHA-256 checksums, and the trusted binaries are pinned by hash inside the product. The container image has no shell, runs as a non-root user with all privileges dropped, and is scanned for known vulnerabilities before release.
Certifications
Kihan is preparing for ISO/IEC 27001 certification and a SOC 2 examination.
For evaluators
On request: architecture and deployment documentation, release checksums for the evaluated version, penetration test findings and our response, and written answers on cryptography, supply chain and data handling.
This website
The website uses no advertising trackers: no tag manager, no advertising or product-analytics SDK, no cookie-consent vendor and no visitor-identification service. Visits are measured with Cloudflare Web Analytics, which sets no cookies; where the Cloudflare zone injects that measurement script automatically, it is the only third-party code the site loads.
Report a vulnerability
Email our security team with a description and the steps to reproduce it. We reply to every report and ask for reasonable time to fix an issue before it is disclosed publicly. Contact details are also published in /.well-known/security.txt.
Request a demo.
Request a 30-minute live demonstration with Kihan, with time for your questions.