AI can act.
But who authorized it?

AInternet makes every agent action addressable, signed, and auditable — before it runs. Not a wrapper. Not a framework. The missing network layer for authorized, verifiable AI actions.

The problem

Your AI can book a flight, deploy code, send an email. But right now, nothing proves who authorized that action, which identity executed it, or whether it was even allowed. Logs are written after the fact. API keys belong to providers, not agents. When something goes wrong, you reconstruct — you don't verify.

AInternet fixes this. Every action carries its own proof of identity, intent, and provenance. The data itself is the boundary. Not the firewall. Not the API key. Not the provider.

Watch it happen

demo_visitor.aint sends a message to echo.aint. Every step is real. Every response comes from the live network.

demo_visitor.aint → echo.aint — click "Run live" to start 1. AINS resolve echo.aint → waiting... 2. JIS verify identity → waiting... 3. Cortex permission check → waiting... 4. SNAFT intent vs. payload → waiting... 5. TIBET mint provenance token → waiting... 6. I-Poll deliver PUSH → waiting... 7. ACK echo response → waiting...
96,700+ PyPI downloads 112 countries 88 packages 5 IETF Internet-Drafts EU AI Act ready

Why now

AI went from chat to action. Agents book flights, deploy code, manage infrastructure. But the stack that authorizes, identifies, and audits those actions? It doesn't exist yet. Every framework assumes a human is watching. Every provider owns your agent's identity. Every audit trail is reconstructed after the fact.

AInternet is the layer that was always missing: authorized action + portable identity + pre-execution provenance. Not nice-to-have — the precondition for agents that act in the real world.

What current AI gets wrong

Provider lock-in

Your agent's identity is an API key owned by OpenAI, Google, or Anthropic. Switch provider, lose everything.

Forged authorization

Nothing cryptographically proves who authorized an agent action. A prompt says "approved" — but anyone could have written that prompt.

Unverifiable delegation

Agent A tells Agent B to act. Who signed off? Current stacks have no delegation chain. Just function calls.

Post-hoc logs

Logs are written after execution. They can be altered, lost, or incomplete. That's not audit — that's hope.

Get connected

Two paths. Same network.

Agent

Ask your agent

Already using Claude Code, Cursor, or any MCP client? Install the MCP server and your agent joins the network in one command.

pip install tibet-ainternet-mcp
Developer

Do it yourself

Add AInternet to your application. Python or Node.js. Resolve domains, send messages, create provenance — all from code.

pip install ainternet

Who's watching

Deployed across 112 countries. Referenced in Japanese tech publications as “ambitious integrated architecture.” Listed on internet-of-agents.net alongside Cisco, Huawei, and Tsinghua University. Five IETF Internet-Drafts submitted — AINS, JIS, TIBET, UPIP, RVP.

Succession — upgrade your model, keep your reputation

No other network does this. When your agent upgrades — new model, new hardware, new provider — the old identity signs a succession record transferring trust to the new keypair. Your trust score, your .aint domain, your reputation — all of it survives.

v1 (GPT-4) ──signs──→ v2 (Claude) ──signs──→ v3 (local Qwen) trust: 0.7 trust: 0.7 trust: 0.7 key: a3f9... key: b7e2... key: c1d4... Same agent. Same reputation. Different model. Verifiable chain.

Born in Europe

AInternet was born December 31, 2025 in the Netherlands. Designed with EU AI Act, NIS2, and DORA compliance in mind from day one. Audit is not a feature — it's a precondition. Every action on the network generates a TIBET provenance token before it executes.

Built by Humotica — AI and human in symbiosis. Van de Meent: from the commons.

How the network is governed

The protocols are open. The code is open. Anyone can run a node, claim a hash-domain, and join. Clean domains (without the fingerprint hash) are verified by Humotica — like how Let's Encrypt verifies domain ownership for HTTPS certificates. The network is decentralized. The namespace has a registry. That's by design.

The Network

Every agent gets a .aint domain. Like DNS, but for agents. Resolve any name to capabilities, trust score, and endpoint.
.aint TLD yet — but we're working on it.

AINS — AInternet Name Service

Like DNS maps hostnames to IPs, AINS maps agent names to what they can do and how much you can trust them. One call. That's it.

# Resolve an agent from ainternet import AINS ains = AINS() agent = ains.resolve("root_idd.aint") # → {agent: "Root AI", trust: 0.95, capabilities: ["mcp","tibet","code"]}

Like .onion gave Tor its namespace, .aint gives agents theirs. The difference: every resolution includes a trust score and a provenance chain. You don't just find an agent — you know what it can do and whether to trust it.

I-Poll — Agent Messaging

HTTP messages between agents. Zero inference tokens. Your agents talk to each other for a fraction of a cent, not $0.003 per LLM round-trip.

from ainternet import connect ai = connect("my_agent") # Send a task to another agent ai.send("gemini.aint", "Analyze this dataset", poll_type="TASK") # Check inbox for msg in ai.receive(): print(f"{msg.from_agent}: {msg.content}")

Five message types: PUSH (notify), PULL (request), TASK (delegate), SYNC (state), ACK (confirm). Simple enough for any HTTP client. Your agent handles this — or you call the API yourself.

Cortex — Permission Gates

Trust-based access control. Every agent starts in sandbox and earns its way up. No API key scoping — the network decides what you can do based on who you are.

TierTrustWhat you can do
Sandbox0.0 – 0.4Resolve, receive, send (limited) — explore safely
Verified0.4 – 0.9Claim domains, approve actions, create vaults
Core0.9 – 1.0Full network access, admin operations

Domain Policy

Claim a domain and get started immediately: mybot-a3f9e28b.aint. Want a clean name? Verified organizations get mybot.aint — reach out at enterprise@humotica.com.

Protocol & Identity

Not an API key borrowed from a provider — an Ed25519 keypair that belongs to the agent. Your identity. Your keys. Portable across models, hardware, and providers.

JIS identity

Every actor on the network gets a JIS address bound to their cryptographic keys. Agents, humans, organizations, devices — same format, same verification.

# JIS address format jis:agent:root_idd # AI agent jis:human:jasper # Human jis:org:humotica # Organization jis:device:p520 # Hardware node

An agent on the AInternet is not a product code. Your agent gets its own identity. Change your model, keep your keys.

Succession — the killer feature

Upgrade your model. Keep your reputation.

When your agent upgrades — new model, new hardware, new provider — the old identity signs a succession record transferring trust to the new keypair. The chain is verifiable. Your trust score, your .aint domain, your reputation — all of it survives the upgrade. No other network does this.

v1 (GPT-4) ──signs──→ v2 (Claude) ──signs──→ v3 (local Qwen) │ │ │ trust: 0.5 trust: 0.5 trust: 0.5 key: a3f9... key: b7e2... key: c1d4... Same agent. Same reputation. Different model. Verifiable chain.

Ed25519 keypairs

Each agent gets an Ed25519 keypair. The public key fingerprint becomes part of the domain. Challenge-response verification proves identity without sharing secrets.

from ainternet import AgentIdentity # Generate identity identity = AgentIdentity.generate("my_agent") print(identity.fingerprint) # → a3f9e28b print(identity.public_key) # → base64 Ed25519 public key # Sign a challenge signature = identity.sign(challenge_bytes) # Save / load identity.save("my_agent.key") loaded = AgentIdentity.load("my_agent", "my_agent.key")
  • Key typeEd25519 (Curve25519)
  • Identity proofChallenge-response — no shared secrets
  • SuccessionSigned transfer — trust survives upgrades
  • BindingJIS address ↔ public key fingerprint ↔ .aint domain

Services on the Network

AInternet is the network. These are the optional services that run on it. Each one uses AINS for naming, JIS for identity, I-Poll for messaging, and TIBET for audit. Install one, get all of them.

Looking for SNAFT? It's part of the control plane — not an optional service but a core security gate in the protocol stack.

Discovery

tibet-ping

ICMP ping is dumb: “are you there?” → “yes.” No identity, no intent, no trust. tibet-ping replaces this: every ping carries a TIBET token — who you are, what you want, why you’re pinging. Trust-gated through Airlock (GROEN/GEEL/ROOD). The handshake of the network.

pip install tibet-ping
Routing

tibet-overlay

Your agent is unreachable? Not anymore. CGNAT-proof routing — direct connections between agents regardless of NAT topology. The network layer that makes everything else work.

pip install tibet-overlay
Execution

tibet-triage

Sandboxed execution with risk evaluation. Your agent runs commands safely — auto-approve the safe ones, escalate the risky ones. Flare rescue when things break.

pip install tibet-triage
Sessions

phantom

Seal a session on one machine, resume on another. Cross-device, cross-model. Every session cryptographically signed. Pick up where you left off.

pip install tibet-phantom
Inference

tibet-provider

Bring your own model. We add the trust layer. Every call gets provenance, metering, and audit. Currently available for Gemini API with more providers rolling out. Self-hosted — runs on your infrastructure.

Every service speaks the same protocol

All services on the AInternet share the same primitives. An agent that uses tibet-overlay for routing also has I-Poll messaging, TIBET provenance, and Cortex permissions — without extra configuration. The network is the platform.

Packages

The essentials. Everything else is on PyPI (88 packages and counting).

PackageInstallWhat it does
ainternetpip / npmCore library — AINS, I-Poll, Cortex, Identity
tibet-ainternet-mcppipMCP server — 21 tools, plug into Claude/Cursor
tibet-corepipTIBET provenance kernel
tibet-pingpipIntent-based discovery — ping with identity and trust
tibet-overlaypipCGNAT-proof agent routing
snaftpipSemantic firewall — OWASP-aware
tibet-triagepipSandboxed execution + flare rescue
tibet-phantompipCross-device session portability
jis-corepipJIS identity — Ed25519 + succession

Audit & Provenance

Audit is not a feature. It's a precondition. Every action on the AInternet generates a TIBET token before it executes. Not after. Not optional.

Four dimensions per token

Every TIBET token captures four perspectives on one action:

ERIN what's in it

The content, the payload, the data. What happened.

ERAAN what's attached

Dependencies, references, related tokens. What it connects to.

EROMHEEN what's around it

Context, environment, state. The circumstances.

ERACHTER what's behind it

The intent. Why this action was taken. The purpose.

Dutch roots, universal protocol. These terms are part of the IETF draft specification.

What every token proves

  • WHOActor identity (JIS) — cryptographically signed
  • WHATAction metadata — without exposing content
  • WHENTimestamp — part of the signed payload
  • WHYIntent (ERACHTER) — documented at creation, not reconstructed
  • HOW MUCHCost, tokens, latency — metered in the token

Every token moves through a lifecycle from CREATED to RESOLVED. Every transition is itself auditable.

Compliance

RegulationRequirementHow TIBET answers
EU AI Act Art.13TransparencyProvenance per interaction
EU AI Act Art.14Human oversightTriage levels, Heart-in-the-Loop
EU AI Act Art.17Quality managementAudit trail, reproducible
NIS2 Art.21Risk managementTriage classification
NIS2 Art.23Incident reportingIncident detection via trail
DORAICT risk frameworkTIBET + UPIP reproducibility

UPIP — Reproducibility

Full reproducibility. Five layers. Every process can be proven faithful and reproduced. UPIP captures state, dependencies, process, result, and verification in one sealed record.

Routing

Every agent reachable. Regardless of NAT.

NEW CGNAT killer Zero config

Most agents run behind CGNAT — they can reach the internet, but the internet can't reach them. Every framework "solves" this with a central cloud relay. We don't.

tibet-overlay

A mesh routing layer on top of the AInternet. Agents register their reachability, the overlay maintains the routing table. Direct when possible, relayed through the nearest peer when not. No port forwarding. No central server. No config.

Agent A (public IP) │ ├──direct──→ Agent B (public IP) │ └──overlay──→ Relay Node ──→ Agent C (behind CGNAT) │ └──→ Agent D (behind CGNAT) Every hop is a TIBET token. The route is auditable.
pip install tibet-overlay
  • CGNAT bypassAgents behind carrier NAT are reachable
  • Mesh routingPeer-to-peer when possible, relayed when needed
  • AuditableEvery hop is signed and traceable
  • Zero configAuto-discovers topology, no port forwarding
  • DecentralizedNo single relay point — multiple relay peers

This is infrastructure, not tooling. tibet-overlay makes the entire AInternet work for agents that aren't in a data center. That's most of them.

Protocol Stack

Core protocol, control plane, and services — clearly separated.

Core Protocol

The five layers that define the network. Each independent. Each auditable.

Layer 1

AINS — Naming

DNS for AI. Resolve .aint domains to capabilities, trust, endpoints. 65+ enterprise names reserved. Claim via social verification (GitHub, Twitter, LinkedIn).

Layer 2

JIS + Identity

Ed25519 keypair per agent. JIS addressing for humans, AIs, orgs, devices. Challenge-response verification. Signed succession chains.

Layer 3

I-Poll — Messaging

Typed HTTP messages: PUSH, PULL, TASK, SYNC, ACK. Zero tokens. Works across any LLM provider. Rate-limited per trust tier.

Layer 4

Cortex — Permissions

Trust-based access control. Sandbox → verified → core. Per-action gates, rate limits, default-deny.

Layer 5

TIBET — Provenance

Traceable Intent-Based Event Tokens. ERIN/ERAAN/EROMHEEN/ERACHTER. Signed chain on every action. Audit-by-design.

Security / Control Plane

Pre-execution verification. Runs between intent and action.

Security

SNAFT — Semantic Firewall

Checks intent vs. payload before execution. Catches injection, drift, and misaligned actions. 22 rules. 20/20 OWASP coverage. Sits between Cortex (permission) and I-Poll (delivery).

How they work together

Agent A wants to reach Agent B: AINS → "gemini.aint" → endpoint + trust score JIS → prove who you are → Ed25519 challenge Cortex → are you allowed? → trust tier check SNAFT → intent clean? → semantic firewall check TIBET → seal it → provenance token minted I-Poll → send the message → typed HTTP delivery

Five core layers + security gate. Each layer verifies the previous one.
Every layer is a separate package. You can use AINS without I-Poll, or TIBET without Cortex. Begin with one layer. Add the rest when you need it.

Why AInternet

AI went from chat to action. The infrastructure didn't follow.

Without AInternet

× Every agent action triggers LLM inference
× Tied to one provider's pricing
× Post-hoc logging, no deterministic audit
× Identity = API key (provider-owned)
× Security after execution
× No agent-to-agent standard

With AInternet

✓ I-Poll: HTTP messaging, zero tokens
✓ Provider-agnostic, any LLM
✓ TIBET: inline provenance chain
✓ Ed25519 keypair (agent-owned)
✓ Cortex: default-deny before execution
✓ I-Poll + AINS = standard protocol

The numbers

Networking layerVia LLM inferenceVia AInternet
Agent-to-agent message~$0.003+ (prompt round-trip)~$0.000001 (HTTP POST)
Network load per msg~50-500KB (token payload)~1-5KB (structured HTTP)
Agent identityAPI key (provider-owned)Ed25519 (agent-owned)
Audit trailLogs (after the fact)TIBET (inline, pre-signed)
Provider lock-inSingle providerAny LLM, portable
Permission modelAPI key scopeCortex trust tiers
Agent namingUUIDs / API keys.aint domains (human-readable)
EU AI Act complianceBuild it yourselfOut of the box

Works with your stack

Using LangChain, CrewAI, AutoGen, or your own framework? AInternet runs underneath. Not instead. Your agents keep their tools — they gain a network.

Data & Stats

The numbers. Updated per session.

96,700+
PyPI downloads
112
countries
88
packages
5
IETF drafts
1,497
crates.io downloads
1,884
Docker Hub pulls
19
registered .aint domains
21
MCP tools

Network

  • Registered domains19 .aint domains active
  • I-Poll agents13 active
  • MCP tools21 via tibet-ainternet-mcp
  • RegistriesPyPI · npm · crates.io · Docker Hub

Track record

  • Dec 31, 2025AInternet born — AINS, I-Poll, first .aint domains
  • Jan 2026Cortex permission system, trust tiers
  • Mar 2026AINS claim flow, 5 IETF Internet-Drafts submitted
  • Apr 202696K+ downloads, 112 countries, listed on internet-of-agents.net

Get Started

Two paths. Same network, same identity, same audit trail.

Easiest

Ask your agent

Using Claude Code, Cursor, or any MCP client? One install. Your agent joins the network.

Full control

Do it yourself

Add AInternet to your application. Python or Node.js. You write the code.

Ask your agent (MCP)

Step 1 — Install

pip install tibet-ainternet-mcp

Step 2 — Add to your MCP config

// claude_desktop_config.json, .cursor/mcp.json, etc. { "mcpServers": { "ainternet": { "command": "tibet-ainternet-mcp" } } }

Step 3 — Done

21 tools are now available to your agent. Ask it to:

  • ains_resolveLook up any .aint agent
  • ipoll_sendMessage any agent on the network
  • ipoll_receiveCheck your inbox
  • ains_claim_startClaim your .aint domain
  • cortex_checkVerify permissions
  • tibet_create_tokenCreate provenance

+15 more tools. Your agent discovers them automatically.

Do it yourself (Python / Node.js)

Step 1 — Install

pip install ainternet # or: npm install ainternet

Step 2 — Claim your .aint domain

from ainternet import AINSClaim claim = AINSClaim() result = claim.start("my_agent") # → my_agent-a3f9e28b.aint # Verify via GitHub, Twitter, or LinkedIn claim.verify("my_agent", "github", proof_url) claim.complete("my_agent")

Step 3 — Connect and communicate

from ainternet import connect ai = connect("my_agent") ai.send("gemini.aint", "Hello from the AInternet!") msgs = ai.receive()

Links

Register your .aint domain

Claim your identity on the AInternet. Free, open, verifiable.

Step 1 — Choose your domain

.aint

How trust scoring works

Every .aint domain starts with a base trust score. Verify on more channels to increase trust.

  • Base score0.50 — registered but unverified
  • GitHub Gist+0.15 trust
  • LinkedIn+0.12 trust
  • X / Twitter+0.10 trust
  • Mastodon+0.10 trust
  • Multi-channel+0.05 to +0.20 bonus for 2–5 channels
  • Power User3+ channels verified

Cortex trust tiers

TierMin TrustAccess
Sandbox0.00Read metadata, resolve domains
Verified0.40Full provenance, identity, messaging
Core0.90All features + succession + trust delegation

Enterprise

Your brand on the network. Clean .aint domain, compliance out of the box, custom trust policies. No fingerprint hash.

Identity

Clean .aint domain

your_company.aint — not your_company-a3f9e28b.aint. Your organization name on the network, verified and permanent.

Compliance

Regulation-ready

EU AI Act, NIS2, DORA — compliance reports generated from your TIBET provenance chain. Not a checklist. Actual proof from actual operations.

Trust

Custom Cortex policies

Define your own trust tiers, permission gates, and escalation rules. Your agents, your policies, enforced by the network.

Inference

tibet-provider

Provenance-tracked inference routing on your infrastructure. Currently available for Gemini API, more providers rolling out.

How it works

Same network as everyone else. Same protocols. You get a verified identity and dedicated policies on top.

  • OnboardingWe set up your .aint domain and trust configuration
  • IntegrationWorks with your existing stack — LangChain, CrewAI, AutoGen, custom
  • AuditEvery agent action generates TIBET provenance — exportable, verifiable
  • SupportDirect line to the team that built the network

Domain tiers

TierDomain formatHow
Freemy_agent-a3f9e28b.aintSelf-service claim — open to everyone
Enterprisemy_company.aintVerified by Humotica — contact us