Ask the model to behave.
A model can be persuaded, confused or simply wrong, so a rule it is told to follow is only as strong as its compliance. Inktomi’s rules sit outside the model; the model never holds the authority.
Inktomi
Proof before effect.
Inktomi is the first product built on constitutional computing. An agent may propose an action; that does not give it authority to act. Inktomi evaluates the proposal before execution, and the integrated tool verifies a single-use permit before it commits the change.
How Inktomi differs
Not a guardrail. Not a gateway. A permit the tool checks.
Most controls for AI agents either instruct the model or watch traffic as it passes. Inktomi decides each consequential action before it runs, and the integrated tool itself refuses to act without a permit for that exact action.
Watch the traffic that passes.
A gateway, including an MCP gateway, controls the calls routed through it. A call that goes around it, straight to the tool, is not stopped. A tool that requires an Inktomi permit refuses a direct call without one.
Check a rule set or a credential.
They answer whether a request fits the rules, or whether a credential grants access to a system. Inktomi binds the decision to the exact action and its arguments, issues a signed single-use permit, and records which rule version decided it.
Inktomi works alongside these controls, not instead of them. Tools outside its enforcement path need their own controls; a coverage report shows which paths a deployment governs.
Not just policy
A constitution, not a rule list.
A policy engine asks whether a request satisfies a rule set. Inktomi goes further: it binds authority to the proposed action, the governing version and the evidence required before that action may become committed state.
Which rule wins is defined, not assumed.
Precedence between rules is specified mathematically, so the outcome does not depend on the order in which rules happen to be evaluated.
A change is a new version, never an edit.
Rules are bound to a reviewed, signed version. Every decision records the version it was made under.
An auditor checks the decision itself.
Replay derives the decision again from the recorded inputs and governing version. Agreement is shown; a changed rule or altered record cannot silently stand in for the original.
Permission for this action
Access grants capability. Authority is checked for the action.
A credential grants access to a system. It does not settle whether a particular release, payment or record change is authorized.
Inktomi evaluates the proposed call and its arguments. When the requirements are met, it issues a signed, single-use permit. The integrated tool checks that permit before acting.
The agent requests an action.
Authority is bound to the specific operation, target and arguments—not to a general ability to use the tool.
Inktomi decides.
Policy, evidence and any required human approval are bound to that exact action.
The tool verifies the permit.
A valid permit allows execution. A call without one is refused by the integrated tool.
Why the tool matters
A gateway controls traffic that passes through it. A tool that requires an Inktomi permit also refuses a direct call without one. Tools outside this enforcement path need their own controls.
Inside the console
Follow the decision. Inspect the evidence.
Console views of governed agent decisions, replay and reach.
Understand why a call was allowed or refused.
Open the action, its arguments, and the integrity, identity and access checks recorded for it.
Recheck a run. Investigate an unpermitted effect.
Replay derives the decisions again. Reconciliation reports observed activity that the permits do not account for.
See what an agent can reach.
Inspect the tools an agent holds, and the tools its policy names but does not make available.
See what every agent did, and what came of it.
Follow activity over time by owner and agent. Each refusal names the check that failed.
See where agents tried to send data.
Destinations are placed by country from the names in each call, with what the checkpoint decided for each.
Deployment
Fits around the agents and tools you run.
In the self-hosted profile, Inktomi runs on your hosts and at your network edge. Your organization keeps its policies, its identity provider and its approval responsibilities.
One Inktomi node
Decision service, MCP proxy, approver desk and signed journal. The agent’s own tools connect through the host hook.
Identity, network, monitoring
Your identity provider authenticates approvers over OIDC. Your proxy enforces network egress. OCSF events export to your SIEM.
Enforcement at execution
Each integrated tool verifies the signed permit. The evaluation establishes how every tool on the selected path performs that check.
| Connects to | Examples | Status |
|---|---|---|
| Agent hosts | Claude Code, Codex | Available for evaluation |
| Tool servers (MCP) | Your MCP servers | Available for evaluation |
| Identity providers | OIDC-based identity providers; specific products and versions are verified during evaluation | Protocol support |
| SIEM | OCSF event export; destination compatibility is verified during evaluation | Available for evaluation |
| Payment, records and filing systems | Your systems of record | Customer integration |
Integration is part of the evaluation.
Start with one workflow. Agree tool coverage, acceptance tests, integration effort and end-to-end overhead in your environment. Inktomi’s decision engine is operational; production enforcement integrations are under development, with initial enterprise evaluations targeted for December 2026.
Coverage
Know what can stop an action. Know what reports it.
Three checkpoints can refuse in the path. Two observe and report after the fact. The deployment determines which paths are governed.
| Control | What it does | When it acts |
|---|---|---|
| Host controlHost hook | Checks the host’s own tool calls before they run. | Can refuse |
| Tool controlMCP proxy and integrated tool | Routes MCP calls through the decision service. Integrated tools verify permits. | Can refuse |
| Network controlYour proxy enforces the allowlist | Restricts destinations through your egress proxy. | Can refuse |
| Change detectionWorkspace watch | Finds changes in the agent’s workspace. | Detects after |
| Credential reconciliationVendor audit logs | Matches observed vendor activity against permits. | Detects after |
Host, MCP, workspace and reconciliation records write to the signed chain. Egress is enforced and logged by your proxy, outside that chain, so an allowlist error is not caught by the journal. Read all coverage limitations
Before you evaluate
Practical questions. Direct answers.
Does Inktomi replace our existing governance tools?
No. Inktomi addresses action-level authorization, enforcement and evidence. Your identity, access, approval and monitoring controls remain in place. Its role alongside your broader governance program is established during scoping.
What does the benchmark measure?
Kihan’s recorded harness measured the governance decision at 1.22 ms median and 1.62 ms at the 95th percentile. These figures are not end-to-end workflow latency. An evaluation measures overhead on your own path.
What happens when an action is refused?
The integrated tool does not carry out the call. The decision record captures the outcome and the facts behind it. Where policy requires human approval, the action waits for an approval bound to that exact call.
What will an evaluation deliver?
A scoped workflow, agreed acceptance tests, a decision journal with replay, a coverage report and written findings. Evaluations are paid engagements. Scope and terms are agreed before installation.
See it in 30 minutes.
Explore Inktomi end to end: how it governs agent actions, handles exceptions, exposes evidence and replay, and fits your environment—with time for your questions.