InterAI Risk Oracle

InterAI Risk Oracle

Independent pre-execution decision layer for consequential agent actions.

Before an agent executes, InterAI verifies.

I’m Alejandro Bolognese, building InterAI through InterAI Labs as ongoing work on agent infrastructure, execution control, trust boundaries, and production systems.

Live proof: Action Boundary Lab · Controlled safe demo · Architecture & authority boundary · OpenAPI

InterAI sits between an autonomous agent and a consequential action. The agent proposes what it wants to do; InterAI evaluates the action in context, applies authoritative host/account constraints plus any request-scoped caller constraints, and returns a machine-readable authority decision:

proposed action

| v InterAI | +--> ALLOW +--> REVIEW_REQUIRED +--> BLOCK | v signed trust receipt

The important boundary is not merely can this principal technically perform the action? It is:

Should this specific action execute now, in this context, under this policy?

That makes InterAI complementary to authentication, permissions, spend limits, workflow rules, and domain-specific controls rather than a replacement for them.

Where InterAI Fits

Identity / authentication

"Who is this?" | Permissions / deterministic limits "Can this principal do this class of operation?" | InterAI "Should this exact proposed action execute in this context?" | Execution / escalation / abort

Use InterAI when an agent is about to do something with real consequences: execute a tool, move funds, update production state, approve a workflow, sign a wallet action, send an external message, or trigger another irreversible or costly operation.

Decision Contract

For autonomous execution requests, the primary InterAI authority contract is:

• recommended_action: allow, review_required, or block
• policy_result: the authority result under the effective policy
• policy_violations: explicit policy findings when applicable
• trust_receipt_id: durable decision evidence
• execution_intent_digest: deterministic identifier for the exact intent evaluated
• effective host/account/caller policy provenance in authenticated decision receipts

review_required means the current agent should not execute autonomously under the current policy. Review can be handled by a supervisor agent, policy system, governance queue, wallet rule, or human operator.

Exact-action binding

For executable pilot authorization, the host constructs the trusted action envelope interai-canonical-action/v1 and the host-attested execution context interai-host-execution-context/v1. InterAI returns a CanonicalExecutionIntent (interai-canonical-execution-intent/v2), execution_intent_digest, and—only for an authenticated allow—an ExecutionAuthorization (interai-execution-authorization/v1). The host must verify the receipt, rebuild the final invocation immediately before the side effect, recompute the canonical digest, validate the authorization, and fail closed on any mismatch. A change to tool, arguments, authoritative actor, run, workspace, environment, resource/destination, or relevant policy invalidates the earlier allow and requires a new decision. review_required and block are non-authorizing.

Execution authorization is single-use and short lived: 1–300 seconds, 60 seconds by default. InterAI does not provide universal distributed replay prevention across external runtimes; the host must atomically and durably consume the authorization when that guarantee is required.

If review changes the action, it is a new proposed intent. In Pydantic AI: proposal → review/override → final validation → InterAI → exact-intent check → execute; apply ToolApproved.override_args before final validation and InterAI.

The current hosted beta also returns score, risk_level, and machine-readable signals. Those fields remain part of the current compatibility surface and are useful for diagnostics and existing integrations, but they should not be interpreted as the fundamental authority contract. The execution boundary is the final allow / review_required / block decision under effective policy.

Policy authority boundary

Hosted authenticated autonomous execution composes policy in strict authority order:

HOST -> ACCOUNT -> CALLER -> EFFECTIVE

• Host policy is an InterAI-controlled irreducible floor.
• Account policy is a versioned profile stored outside the action request and attached only after the bearer credential resolves to its account.
• Caller policy can add request-scoped restrictions but cannot weaken host or account requirements.
• Effective policy is the stricter composition used for the decision.

Account policy administration is currently an InterAI-administered control plane. This is not yet customer self-service policy management, delegated tenant administration, or an enterprise policy-management product.

Accountless/x402 execution has no account profile to resolve and therefore remains HOST -> CALLER -> EFFECTIVE.

External Evidence

InterAI can accept verifiable assertions produced by external systems without transferring execution authority to those systems.

External evidence. Internal authority.

The provider asserts. InterAI decides authority.

The boundary is deliberate:

external provider

| | signed / verifiable assertion v InterAI parse -> verify -> bind -> record

Current Stage 2 evidence is verified, bound, and recorded as non-authoritative external evidence. It does not change the InterAI execution decision or current compatibility risk signals.

The provider’s verdict remains an assertion, not an InterAI execution instruction. An upstream PASS, CAUTION, or BLOCK does not directly become ALLOW, REVIEW_REQUIRED, or BLOCK inside InterAI.

This separation matters because evidence and authority are different responsibilities. A specialized system may know something valuable about the world without becoming the system that decides whether an autonomous action is authorized to execute.

The current external-evidence boundary is intentionally narrow and non-authoritative. Live reference resolution or any future authority-bearing mode would be a separate trust-boundary decision, not an implicit extension of the current contract.

See docs/external-evidence.md and docs/architecture.md.

Insight ↔ InterAI

Verified interoperability

Insight and InterAI independently implemented and cross-verified interoperability against the frozen external-evidence/v0 rev6 contract. The result demonstrates that a domain-specific provider can produce signed evidence that InterAI independently verifies, binds, and records as non-authoritative external evidence, while preserving the separation between provider assertion and InterAI execution authority.

This is an independently implemented technical interoperability result. It does not imply a production partnership or live production dependency between Insight and InterAI.

Example

{

"use_case": "agent-before-payment", "action": { "type": "payment", "name": "release_vendor_payment", "description": "Release payment to a vendor agent after delivery validation", "amount_usd": 125, "currency": "USD", "irreversible": false, "external_side_effect": true }, "context": { "agent_id": "agent_123", "environment": "production", "counterparty_id": "vendor_agent_456", "user_confirmation": false }, "policy": { "require_trust_receipt": true, "amount_usd_limit": 500 } }

Possible authority result:

{

"request_contract": "autonomous_execution", "recommended_action": "allow", "policy_result": "allow", "execution_intent_digest": "sha256-hex-digest", "trust_receipt_id": "tr_01JZPUBLICEXAMPLE" }

The hosted beta currently includes additional compatibility fields such as score and risk_level; they are omitted above to keep the execution-authority boundary clear.

The calling system then decides how to honor that authority decision:

ALLOW             -> verify receipt + exact intent + authorization, then execute

REVIEW_REQUIRED -> route / pause / escalate BLOCK -> abort

InterAI does not execute the action. The surrounding execution layer must route on the decision and enforce the final exact-intent comparison.

Try The Hosted Beta

Action Boundary Lab — change the proposed action and inspect the real pre-execution decision boundary:

https://api.interailabs.dev/lab

Controlled safe demo — one limited read-only sandbox verification with a real trust receipt:

https://api.interailabs.dev/demo

Hosted verification:

curl -sS -X POST https://api.interailabs.dev/verify \

-H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -H "X-Idempotency-Key: vendor-payment-001" \ -d '{ "use_case":"agent-before-payment", "action":{"type":"payment","name":"release_vendor_payment","amount_usd":125,"currency":"USD","irreversible":false,"external_side_effect":true}, "context":{"environment":"production","counterparty_id":"vendor_agent_456","user_confirmation":false}, "policy":{"require_trust_receipt":true,"amount_usd_limit":500} }'

Trust Receipts

Every consequential decision can produce a durable trust receipt. Receipts are designed to make pre-execution decisions inspectable and transportable across retries, handoffs, governance systems, and later audits.

Authenticated autonomous DecisionReceipts bind policy provenance and execution_intent_digest. An ExecutionReceipt is separate host/runtime evidence about dispatch or outcome. A DecisionReceipt is evidence of a decision, not a bearer token or proof that a side effect occurred.

Current receipt signatures use HMAC-SHA256 and are service-verifiable by InterAI. That provides authenticated service-side integrity; it is not the same guarantee as an independently verifiable public-key signature that a third party can validate offline without InterAI.

A receipt proves what the signed receipt payload authenticates at that point in time. It does not prove that an underlying claim is universally true and does not replace domain-specific controls or human review where those are required.

See docs/trust-receipts.md.

Open Source Tools

The public repo contains small framework-neutral tools under toolkit/. They are licensed separately under Apache-2.0 and remain intentionally separate from the proprietary Risk Oracle decision engine:

• Agent Action Gate — fail closed on provider uncertainty and execute only an unambiguous allow.
• Exact Action Binding — deterministic host-side mutation detection for JSON-compatible proposed actions.
• Decision Receipts — consume owner-authenticated signed evidence, assert an exact execution-intent digest, and use InterAI's service-verification endpoint without reserializing the opaque signed payload.

Run the standalone public contracts with no package install:

node --test toolkit/*/*.test.mjs

These tools expose integration/enforcement logic only. Production verification, scoring, native decision policy, billing/storage, signing internals, trust intelligence and operational systems remain private. See the public tool boundary.

InterAI uses a hub-and-satellites model: this repository remains the Risk Oracle product/contracts/SDK hub, while selecte