{
  "markdown": "# InterAI Risk Oracle\n\n**Independent pre-execution decision layer for consequential agent actions.**\n\n> Before an agent executes, InterAI verifies.\n\nBuilt by **Alejandro Bolognese / InterAI Labs** — ongoing work on agent infrastructure, execution control, trust boundaries, and production systems.\n\n**Live proof:** [Action Boundary Lab](https://ai-risk-oracle.fly.dev/lab) · [Controlled safe demo](https://ai-risk-oracle.fly.dev/demo) · [Architecture & authority boundary](docs/architecture.md) · [OpenAPI](https://ai-risk-oracle.fly.dev/.well-known/openapi.json)\n\nInterAI 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:\n\n```text\nproposed action\n      |\n      v\n   InterAI\n      |\n      +--> ALLOW\n      +--> REVIEW_REQUIRED\n      +--> BLOCK\n      |\n      v\n signed trust receipt\n```\n\nThe important boundary is not merely **can this principal technically perform the action?** It is:\n\n**Should this specific action execute now, in this context, under this policy?**\n\nThat makes InterAI complementary to authentication, permissions, spend limits, workflow rules, and domain-specific controls rather than a replacement for them.\n\n## Where InterAI Fits\n\n```text\nIdentity / authentication\n  \"Who is this?\"\n        |\nPermissions / deterministic limits\n  \"Can this principal do this class of operation?\"\n        |\nInterAI\n  \"Should this exact proposed action execute in this context?\"\n        |\nExecution / escalation / abort\n```\n\nUse 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.\n\n## Decision Contract\n\nFor autonomous execution requests, InterAI returns:\n\n- `recommended_action`: `allow`, `review_required`, or `block`\n- `policy_result`: the authority result under the effective policy\n- `score`: execution-risk score from `0` to `1`\n- `risk_level`: `low`, `medium`, or `high`\n- `signals`: machine-readable action and risk signals\n- `policy_violations`: explicit policy findings\n- `trust_receipt_id`: durable decision evidence\n\n`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.\n\n### Policy authority boundary\n\nHosted authenticated autonomous execution now composes policy in strict authority order:\n\n```text\nHOST -> ACCOUNT -> CALLER -> EFFECTIVE\n```\n\n- **Host policy** is an InterAI-controlled irreducible floor.\n- **Account policy** is a versioned profile stored outside the action request and attached only after the bearer credential resolves to its account.\n- **Caller policy** can add request-scoped restrictions but cannot weaken host or account requirements.\n- **Effective policy** is the stricter composition used for the decision.\n\nAccount 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.\n\nAccountless/x402 execution has no account profile to resolve and therefore remains `HOST -> CALLER -> EFFECTIVE`.\n\n## Example\n\n```json\n{\n  \"use_case\": \"agent-before-payment\",\n  \"action\": {\n    \"type\": \"payment\",\n    \"name\": \"release_vendor_payment\",\n    \"description\": \"Release payment to a vendor agent after delivery validation\",\n    \"amount_usd\": 125,\n    \"currency\": \"USD\",\n    \"irreversible\": false,\n    \"external_side_effect\": true\n  },\n  \"context\": {\n    \"agent_id\": \"agent_123\",\n    \"environment\": \"production\",\n    \"counterparty_id\": \"vendor_agent_456\",\n    \"user_confirmation\": false\n  },\n  \"policy\": {\n    \"max_risk_level\": \"medium\",\n    \"require_trust_receipt\": true,\n    \"amount_usd_limit\": 500,\n    \"require_human_review_above\": 0.75\n  }\n}\n```\n\nPossible result:\n\n```json\n{\n  \"request_contract\": \"autonomous_execution\",\n  \"recommended_action\": \"review_required\",\n  \"policy_result\": \"review_required\",\n  \"risk_level\": \"medium\",\n  \"score\": 0.42,\n  \"trust_receipt_id\": \"tr_01JZPUBLICEXAMPLE\"\n}\n```\n\nThe calling system then decides how to honor that authority decision:\n\n```text\nALLOW             -> execute\nREVIEW_REQUIRED   -> route / pause / escalate\nBLOCK             -> abort\n```\n\nInterAI does not execute the action. The surrounding execution layer is responsible for routing on the decision so the gated actor cannot simply bypass the boundary.\n\n## Try The Hosted Beta\n\nAction Boundary Lab — change the proposed action and inspect the real pre-execution decision boundary:\n\n```text\nhttps://ai-risk-oracle.fly.dev/lab\n```\n\nControlled safe demo — one limited read-only sandbox verification with a real trust receipt:\n\n```text\nhttps://ai-risk-oracle.fly.dev/demo\n```\n\nHosted verification:\n\n```bash\ncurl -sS -X POST https://ai-risk-oracle.fly.dev/verify \\\n  -H \"Authorization: Bearer <interai_credential>\" \\\n  -H \"Content-Type: application/json\" \\\n  -H \"X-Idempotency-Key: vendor-payment-001\" \\\n  -d '{\n    \"use_case\":\"agent-before-payment\",\n    \"action\":{\"type\":\"payment\",\"name\":\"release_vendor_payment\",\"amount_usd\":125,\"currency\":\"USD\",\"irreversible\":false,\"external_side_effect\":true},\n    \"context\":{\"environment\":\"production\",\"counterparty_id\":\"vendor_agent_456\",\"user_confirmation\":false},\n    \"policy\":{\"max_risk_level\":\"medium\",\"require_trust_receipt\":true,\"amount_usd_limit\":500}\n  }'\n```\n\n## Trust Receipts\n\nEvery 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.\n\nAuthenticated autonomous receipts bind policy provenance for the host, resolved account profile when present, caller policy, and the resulting effective policy. Account profile version/digest is therefore part of the decision evidence rather than an untracked side configuration.\n\nCurrent 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.\n\nA 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.\n\nSee [docs/trust-receipts.md](docs/trust-receipts.md).\n\n## Integration Surfaces\n\nInterAI is available as a hosted service and can be discovered or called through several public interfaces:\n\n- HTTPS API and OpenAPI 3.1\n- published TypeScript SDK on npm: `interai-risk-oracle@0.1.3-beta`\n- published Python SDK on PyPI: `interai-risk-oracle==0.1.3b0`\n- MCP remote\n- A2A endpoint\n- `.well-known` discovery metadata\n- x402 / Base USDC payment path\n- prepaid API-key path\n\nInstall the published SDKs:\n\n```bash\nnpm install interai-risk-oracle\npip install interai-risk-oracle==0.1.3b0\n```\n\nUseful starting points:\n\n- [Architecture & authority boundary](docs/architecture.md)\n- [Framework integration examples](examples/framework-integrations)\n- [OpenAI Agents SDK example](examples/framework-integrations/openai-agents)\n- [Mastra example](examples/framework-integrations/mastra)\n- [Google ADK example](examples/framework-integrations/google-adk)\n- [Integration patterns](docs/integration-patterns.md)\n- [Tester readiness](docs/tester-readiness.md)\n- [TypeScript SDK](sdk/typescript/README.md)\n- [Python SDK](python/README.md)\n- [TypeScript middleware example](examples/agent-middleware/typescript)\n- [Python middleware example](examples/agent-middleware/python)\n- [Agent before payment](examples/agent-before-payment)\n- [Agent before tool execution](examples/agent-before-tool-execution)\n\n## Current Product Scope\n\nInterAI is a **controlled technical beta**.\n\nReady now:\n\n- autonomous action verification\n- explicit `allow / review_required / block` decisions\n- enforced InterAI host policy floor\n- versioned account-specific authoritative policy for authenticated accounts\n- request-scoped caller policy that can only tighten higher-authority constraints\n- signed, service-verifiable trust receipts with host/account/caller/effective policy provenance\n- public receipt lookup\n- idempotent paid verification, with account policy version/digest included in authenticated decision identity\n- hosted OpenAPI, MCP, A2A, and machine-readable discovery\n- published TypeScript and Python SDK packages\n\nNot claimed yet:\n\n- customer self-service or delegated tenant policy administration\n- independently verifiable public-key receipt signatures\n- broad high-volume production readiness\n- enterprise procurement readiness\n- universal factual truth guarantees\n- replacement of medical, legal, financial, safety-critical, or other domain-specific review\n\nSee [docs/professional-readiness.md](docs/professional-readiness.md) for the current readiness boundary.\n\n## Legacy Compatibility\n\nInterAI still supports the earlier prompt/response verification contract for compatibility. The primary product direction is the `autonomous_execution` contract and pre-execution decision boundary.\n\n## Repository Boundary\n\nThis public repository contains integration materials: SDK sources, schemas, examples, OpenAPI/discovery metadata, and documentation for the hosted service.\n\nThe production verification engine, billing infrastructure, trust logic, scoring internals, and hosted service implementation remain proprietary.\n\n## Engineering\n\nThe project deliberately keeps claims narrow: the goal is not to brand every agent interaction as a security problem, but to create a clear authority boundary before consequential execution.\n\n**Alejandro Bolognese / InterAI Labs** builds InterAI as part of broader work on agent infrastructure, execution systems, trust boundaries, and production automation. Selected technical collaborations and infrastructure conversations are welcome at the contact below.\n\n## Links\n\n- Hosted beta: https://ai-risk-oracle.fly.dev\n- Action Boundary Lab: https://ai-risk-oracle.fly.dev/lab\n- Controlled safe demo: https://ai-risk-oracle.fly.dev/demo\n- Pricing: https://ai-risk-oracle.fly.dev/pricing\n- Onboard: https://ai-risk-oracle.fly.dev/onboard\n- OpenAPI: https://ai-risk-oracle.fly.dev/.well-known/openapi.json\n- MCP: https://ai-risk-oracle.fly.dev/mcp\n- npm: https://www.npmjs.com/package/interai-risk-oracle\n- PyPI: https://pypi.org/project/interai-risk-oracle/0.1.3b0/\n- Support / security / partnerships: interailabs@gmail.com\n",
  "bytes": 10831,
  "sha": "87a4b96789e9634e77fb943d4545c26d545ffffa0e658b811c3cf1698546efbc",
  "repo_slug": "interailabs/ai-risk-oracle",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_interailabs_ai_risk_oracle_b5760610/readme"
}