A Policy Information Point for the Agentic Internet

TunnelMind whitepaper · v1.0 · July 2026 Companion to the Signed Attribute Bundle v1.0 specification and the live API at data.tunnelmind.ai.

Abstract

Autonomous agents now transact with counterparties no human ever inspects. The access-control architecture the industry is converging on — enforcement point, decision point, information point (PEP / PDP / PIP) — has mature enforcement (gateways, proxies, agent runtimes) and mature decision engines (OPA, Cedar, Cerbos), but no neutral source of the facts those decisions need. OPA's own documentation states it plainly: "OPA is not designed to be a source of truth." This paper describes what a Policy Information Point owes a Policy Decision Point on the open internet, and how TunnelMind implements that contract: multi-lens observation, coverage honesty, a freshness contract, offline-verifiable signatures with a public transparency log, and a sub-100 ms consumption path. Facts, not verdicts — the trust decision stays in your policy engine.

1. The empty seat

Every serious authorization architecture separates three roles:

• PEP — Policy Enforcement Point (your gateway, proxy, or agent runtime): intercepts the request or action and enforces the decision — allow, deny, step-up. It asks the PDP; it does not reason.
• PDP — Policy Decision Point (your policy engine — OPA, Cedar, Cerbos, your own code): evaluates your policy against the facts. The only place a trust decision is made, with your rules and your risk tolerance.
• PIP — Policy Information Point: supplies the attributes the PDP needs about a counterparty.

For agentic traffic, the first two seats are crowded and the third is effectively empty. Edge providers verify agents for their own customers, inside their own products — the facts are not portable, signed, or consumable by a third-party engine. Bot-management vendors sell decisions, not facts, from closed scoring no policy can inspect. The network-intelligence providers practitioners actually wire into PDPs today are single-lens, unsigned, and carry no statement of their own blind spots. The forming IETF drafts describe the PEP/PDP flow in detail and leave the PIP as an exercise for the reader.

A PDP consuming any of these inherits their gaps silently. That is the problem a real PIP has to solve — not "more data," but accountable data.

2. What a PIP owes a PDP

Four obligations, each missing from the status quo:

Facts with provenance, not verdicts. A verdict is a decision made with someone else's risk tolerance. A PIP supplies per-source facts, each labeled with where it came from and how it was derived, so the policy engine can weigh them under its rules. TunnelMind's bundle tags every field {value, tier, source} — verified, derived, or trusted — and keeps the fused cross_lens score advisory beside them.

Coverage honesty. The most dangerous answer a PIP can give is a silent gap: "no threat data" meaning either observed and clean or never looked. Every lens in a TunnelMind bundle reports a tri-state: observed_clean (we looked, it was clean), never_observed (an honest blind spot), or degraded (we tried and failed). A PDP can — and should — gate on the difference. No other provider states its blind spots in-band.

A freshness contract. Facts age. Each bundle carries valid_until (when to refresh) and stale_if_error (how long a stale answer is still better than failing closed), so cache behavior is defined by the producer of the facts, not guessed at by every consumer.

Verification that does not require trusting the PIP. Every bundle ships inside an Ed25519-signed receipt over RFC 8785 canonical JSON, resolvable against a published key bundle with attestation-strength ceilings and a revocation feed. Since July 2026 every receipt is also committed to an append-only RFC 6962 transparency log: any consumer can demand an inclusion proof against a published signed tree head. The reference verifier is open source and runs offline. You never have to take TunnelMind's word for TunnelMind.

3. The architecture

Four lenses, one join. TunnelMind observes the internet through four independent lenses — network behavior from a signed sensor fleet (who is on every IP, what it actually does on the wire), supply-chain and publisher integrity, routing integrity (RPKI validity, hijack posture, sanctions exposure), and the tracker/ownership graph. A single call, POST /v1/verify/{node}, fans out across all four and returns the fused bundle: per-lens facts, coverage tri-states, the freshness contract, and the signed receipt. Identity claims meet observed conduct in one answer — a registry entry says what an actor claims; the lenses report what it does.

The hot path. A full resolve takes ~2 s — fine for preflight, fatal for per-request authorization. GET /v1/attributes/{node} serves the last-known signed bundle from edge cache in under 100 ms, with the freshness fields telling the PDP exactly how much to trust its age. A miss is an honest 404 — never a fabricated answer.

Agent-native surfaces. The same facts are consumable as 117 MCP tools across three servers (for Claude-family and other MCP agents), an OpenAPI 3.1 surface (for Gemini/ADK and codegen), and machine-payable x402 endpoints. A preflight call — "should I act?" — returns allow / caution / deny plus a signed consultation receipt an agent can carry as evidence that it checked.

Small and honest beats big and vague. TunnelMind's observation fleet is smaller than the incumbents' — and says so, in-band, on every answer. The coverage tri-state turns limited breadth from a hidden liability into a stated property a PDP can reason about. never_observed is a feature precisely because observed_clean is earned.

4. Consuming it

OPA, on the decision path (the full pattern, including coverage gating, is in the OPA integration guide):

package authz
import rego.v1

default allow := false

tm := http.send({
    "method": "GET",
    "url": sprintf("https://data.tunnelmind.ai/v1/attributes/%s", [input.destination]),
    "headers": {"Authorization": sprintf("Bearer %s", [opa.runtime().env.TUNNELMIND_API_KEY])},
    "cache": true,
    "caching_mode": "deserialized",
}).body

allow if {
    tm.ok
    tm.data.cross_lens.verdict == "pass"
    tm.data.attributes_meta.freshness == "fresh"
    tm.data.coverage.rollup.degraded == 0
}

SDKs that verify the PIP. The TypeScript (@tunnelmindai/sdk) and Python (tunnelmind) clients run offline receipt verification on every response by default and attach the result beside the facts. Cross-language conformance is pinned by a shared signed test vector. The whole pitch in one import: the client checks the server's signature before your policy reads a byte.

Anything else. The bundle is plain JSON over HTTPS with an anonymous free tier — Cerbos's HTTP driver, a Cedar entity-provider shim, or twenty lines of your own code consume it the same way.

5. What TunnelMind deliberately does not do

It does not enforce (no proxy, no gateway — bring your own PEP). It does not decide (the verdict field is advisory; the decision is your policy's). It does not claim global coverage (the tri-state says exactly where the lenses have and haven't looked). And it does not require trust in itself (every answer is offline-verifiable and transparency-logged). A PIP that did any of those would be selling something other than facts.

6. References

Verify this paper's claims yourself: curl -X POST https://data.tunnelmind.ai/v1/verify/example.com returns a signed bundle; the verifier at github.com/TunnelMind/receipt-verify checks it offline.