Technical

If your system can call tools, it can use Keon.

Keon exposes a standard MCP tool surface. Your existing client connects directly. Keon handles policy evaluation, identity binding, and receipt issuance on every call.

Schedule Executive BriefingAll Planes
Tool Call→Decision→Execution→Receipt
{
  "method": "tools/call",
  "params": {
    "name": "keon.governed.execute.v1",
    "arguments": {
      "purpose": "Summarize recent emails",
      "mode": "decide_then_execute"
    }
  }
}

From your agent's perspective, that's the entire integration surface.

How It Works

Decide before execute. Receipt every outcome.

Call a tool→Policy + identity→Execute + receipt
01
Your agent calls a tool

Any MCP-compatible client issues a standard tools/call request. No Keon-specific SDK, no custom protocol. If your system can call tools, it can call Keon.

02
Keon evaluates policy and identity

The request enters the governance boundary. Keon resolves the actor, evaluates active policy, and issues a signed Decision — PERMITTED, DENIED, or DEFERRED. No action occurs before this step completes.

03
If approved, Keon executes and returns receipts

Authorized actions execute within the governed boundary. A cryptographic DecisionReceipt is returned alongside the result — proof of what was decided, under which policy, by which authority.

Why Builders Care

The integration stays small because the boundary is doing the work.

Keep your existing framework

Keon does not require you to abandon your orchestration layer. If it speaks MCP, it already speaks Keon.

No custom governance plumbing

You do not build policy evaluation, receipt issuance, or audit trails. Keon handles all of it behind the tool boundary. Your integration code stays small.

Standard MCP compatibility

Keon exposes a standard MCP tool surface. No proprietary protocol, no special transport. Connect the way you connect to any MCP server.

Structured receipts for everything downstream

Every governed execution produces a signed DecisionReceipt. Use them for agent memory, audit logs, compliance reporting, or downstream system coordination.

Fail-closed by design

Tenant binding, actor identity, and policy enforcement are handled by Keon. If policy cannot be evaluated, execution does not proceed.

Works With Your Stack

Keon speaks MCP. Your stack probably already fits.

OpenAI-compatible tool workflows
Function calling → MCP bridge
LangChain / LangGraph
Tool nodes with MCP transport
Local or remote MCP clients
stdio, SSE, or HTTP transport
C#
.NET MCP integration
Python
Native MCP client libraries
TypeScript
First-class MCP support
Go
Server-side MCP integration
Proof, Not Promises

Traditional systems execute first. Keon decides first.

Traditional systems
→ Execute first→ Log later→ Hope it was allowed
Keon
→ Decide first→ Prove authorization→ Then execute
Decision receipts at authorization time

Receipts are issued before execution, not reconstructed after the fact.

Policy-bound execution

Every receipt carries the PolicyHash of the version active at evaluation time.

CAES-style structural accountability

Authorization is not assumed. It is declared, evaluated, and proven at every execution boundary.

Evidence packs verifiable without Keon

A third party can verify them without access to Keon infrastructure.

Legacy HTTP Compatibility

MCP is primary. HTTP exists for compatibility.

Governance evaluation (HTTP)
POST /api/govern/evaluate
{ "intent": "...", "agentId": "...", "policyRef": "..." }
Receipt retrieval
GET /api/receipts/{receipt_id}
Returns: DecisionReceipt (signed, ledger-anchored)
Evidence pack export
POST /api/evidence-packs/export
{ "receiptIds": [...], "format": "pack_v2" }