Power your agent
The publisher's own URL. Not a PlugMCP endpoint.
Host a copy with our keys and logs.
https://api.interailabs.dev/mcpThe Claude button above opens Claude with the name and URL filled in. You still confirm it there.
claude mcp add --transport http io.github.interailabs-ai-risk-oracle https://api.interailabs.dev/mcpRun in a terminal.
{ "mcpServers": { "io.github.interailabs-ai-risk-oracle": { "command": "npx", "args": [ "-y", "mcp-remote", "https://api.interailabs.dev/mcp" ] } }}claude_desktop_config.json
Remote URL or a command on your machine? How the two installs differ
Run on PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
LaunchFrom the publisher
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.
Pre-execution policy gate for consequential agent actions with durable trust receipts.
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.
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.
For autonomous execution requests, the primary InterAI authority contract is:
recommended_action: allow, review_required, or blockpolicy_result: the authority result under the effective policypolicy_violations: explicit policy findings when applicabletrust_receipt_id: durable decision evidenceexecution_intent_digest: deterministic identifier for the exact intent evaluatedreview_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.
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.
Hosted authenticated autonomous execution composes policy in strict authority order:
HOST -> ACCOUNT -> CALLER -> EFFECTIVE
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.
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.
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.
{
"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.
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 <interai_credential>" \
-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}
}'
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.
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 selected stable tools may also receive focused standalone repositories to improve discovery and contribution without copying private-core logic.
InterAI is available as a hosted service and can be discovered or called through several public interfaces:
[email protected] (beta dist-tag)interai-risk-oracle==0.1.7b0.well-known discovery metadataSDK package versioning is independent from the hosted runtime version. The hosted service and its discovery manifests remain on their current runtime release until a separate runtime release is made.
Install the published SDKs:
npm install [email protected]
pip install interai-risk-oracle==0.1.7b0
Useful starting points:
InterAI is a controlled technical beta.
Ready now:
allow / review_required / block decisionsNot claimed yet:
See docs/professional-readiness.md for the current readiness boundary.
InterAI still supports the earlier prompt/response verification contract for compatibility. The primary product direction is the autonomous_execution contract and pre-execution decision boundary.
The hosted beta also retains score/risk compatibility fields used by the current implementation and existing integrations. They are not the long-term conceptual definition of InterAI's authority boundary.
This public repository contains integration materials: SDK sources, schemas, examples, OpenAPI/discovery metadata, Apache-licensed open-source tools, and documentation for the hosted service.
The production verification engine, billing infrastructure, trust logic, scoring internals, native decision implementation, signing internals, and hosted service implementation remain proprietary.
I keep InterAI’s claims deliberately narrow. I’m not trying to brand every agent interaction as a security problem; I’m building a clear authority boundary before consequential execution.
I’m building InterAI as part of broader work on agent infrastructure, execution systems, trust boundaries, and production automation. I’m open to selected technical collaborations and infrastructure conversations where there is a concrete interoperability or execution-control problem to solve.
GET /trust/receipts/{receiptId} without credentials returns only a
public_summary containing receipt ID and issuance time. It is not signed
evidence or an execution authorization. Supply an active Bearer key belonging
to the receipt account for the complete receipt, original opaque
verification.signed_payload, signature and authorization. Invalid keys return
401; another account receives 404. Responses must not be cached.
Accountless x402/payment-reference clients must preserve the complete evidence returned by their original verification; a public lookup cannot recover private contents. Demo links also show only the public reference. Do not put API keys in receipt URLs. Keep the signed payload bytes unchanged when verifying.
© 2026 MCP Directory.
Pre-execution policy gate for consequential agent actions with durable trust receipts.
{ "mcpServers": { "io.github.interailabs-ai-risk-oracle": { "url": "https://api.interailabs.dev/mcp", "headers": {} } }}Tools
No tool list yet. Remote servers get one after the first health check.
FAQ
Copy the http config for Cursor, Claude Desktop, Claude Code, or VS Code on this page. It uses the publisher's install, not a PlugMCP proxy.
No required environment variable is listed on this record.
InterAI Risk Oracle is reached over HTTP.
Last checked 2026-11-09. Pre-execution policy gate for consequential agent actions with durable trust receipts.