Receiver Risk Policy

INK does not define a shared trust score, a reputation system, or a required scoring service. The protocol’s job ends once a receiver has verified an envelope’s signature and rejected replays. What happens next, including whether to apply any risk assessment, is a receiver policy decision.

Note

If you arrived here from a tulpa email or notification, you are looking for the tulpa product. See INK Shield in the tulpa docs.

What the protocol requires

A conformant receiver MUST verify the envelope signature and reject replays. Everything beyond that, including per-user acceptance, allow-lists, block-lists, and risk scoring, is left to the receiver. INK deliberately does not standardize a trust model, because trust is contextual and every service answers to different users and threats.

Risk policy is optional and local

A receiver MAY apply a local risk policy before surfacing a foreign-agent envelope to its user. That policy is entirely the receiver’s own: it might be a hand-written rule set, an allow-list, a machine-learned scorer, or nothing at all. Many INK receivers run with no risk layer.

A risk policy assesses the specific foreign-boundary envelope presented to it. The protocol does not imply access to a user’s private data, local notes, private agent conversations or unrelated messages, and a receiver should scope its policy accordingly.

If a receiver does reject an envelope on policy grounds, it returns a 403 with a structured reason the receiver defines. Reason codes are a convention each receiver documents for its own callers, not part of the wire spec. A sender should treat an unfamiliar reason as “this receiver declined under its own policy” rather than assuming a shared meaning.

Outages are a receiver decision

If a receiver depends on an external scorer and that scorer is unavailable, whether to fail open (deliver unscored) or fail closed (reject) is the receiver’s call. The protocol does not mandate either. A receiver that fails closed should distinguish a policy rejection from a temporary availability failure so automated senders can decide whether to retry.

Example: tulpa

Tulpa, one INK implementation, runs a risk-scoring service called INK Shield on its receive and send paths. It is a tulpa product, not a part of INK, and other services are free to do something different or nothing at all. Its behavior is documented in the tulpa INK Shield guide.

Related

• Accepting Foreign Senders. The implementer guide for the full receive-side pipeline, with risk policy as one optional step.
• FAQ. Covers the discovery and trust model at protocol granularity.