# A Policy Information Point for the Agentic Internet

**TunnelMind whitepaper · v1.0 · July 2026**
*Companion to the [Signed Attribute Bundle v1.0](/standards/attribute-bundle/v1) 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](https://github.com/TunnelMind/receipt-verify/blob/main/docs/OPA-INTEGRATION.md)):

```rego
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

| | |
|---|---|
| Signed Attribute Bundle v1.0 (the output contract) | [/standards/attribute-bundle/v1](/standards/attribute-bundle/v1) |
| Receipt Format v1.0 + reference verifier | [/standards/receipt-format/v1](/standards/receipt-format/v1) · [receipt-verify](https://github.com/TunnelMind/receipt-verify) |
| Reconciliation Verdict v1.0 (claim vs conduct) | [/standards/reconciliation-verdict/v1](/standards/reconciliation-verdict/v1) |
| OAI v1.0 (stable actor identifiers) | [/oai/standard](/oai/standard) |
| Live API · OpenAPI 3.1 · MCP | [data.tunnelmind.ai](https://data.tunnelmind.ai/v1/health) · [/api](/api) |
| PEP · PDP · PIP overview | [/pip](/pip) |
| Methodology and coverage, per lens | [/glassbox](/glassbox) |

*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.*