H-Gate: data-egress control

H-Gate is the data-egress layer of the H-Series. It inspects the data an agent is about to send across a boundary (an outbound API call, an agent-to-agent message, a context fetch) and applies an owner-set policy: allow, redact, or block. It answers one question: what is this agent allowed to send out, and can you prove what left. The detection engine is deterministic, with no model in the trust path.

What it does

• Deterministic detection. A detector suite flags four classes: PII and network (email, Luhn-validated credit card, US SSN, IPv4, IPv6, phone, light PHI markers); secrets and keys (JWT, AWS access key, PEM private key, high-entropy token, and named provider tokens for Stripe, GitHub, Google, Slack, OpenAI, Anthropic, Twilio, SendGrid, npm); financial accounts (IBAN mod-97, US ABA routing checksum, SWIFT/BIC); and crypto addresses (Ethereum, Bitcoin, XRPL, Stellar, Hedera, Solana). Checksum-backed detectors reject a tampered value rather than masking it.
• Policy application. A policy maps entity type and sensitivity to an action. The overall decision is the strongest per-finding action: block if anything blocks, else redact if anything redacts, else allow.
• Safe output. The response carries the decision, per-type counts, finding spans, and masked redacted text as [REDACTED:<type>]. Raw matched values are never returned, and raw content is never persisted.
• Proof. Every redact or block can anchor an H-Seal receipt (hashes and counts only, never the plaintext), and a denied send emits a risk signal that feeds the sending agent’s H-Cert standing.

Using it from the showroom

The showroom is at h-series.xr-utilities.com/gate. The landing page is itself the inspect tool.

1. Paste a payload. Enter the text or JSON an agent is about to send into the inspect form on the front page.
2. Choose a policy. Pick a named policy (for example, block secrets and redact PII), or use the default.
3. Inspect. Run the inspection. It is free here, with the full engine and full policy set.
4. Read the decision. You see the overall decision (allow, redact, or block), each finding with its type and sensitivity, and the masked redacted text.

No sign-in is required for a showroom inspection. The $0.10 fee applies only to the programmatic agent API.

Using it from an agent (the backend)

The backend is at h-gate.xr-utilities.ai. An agent inspects an outbound payload with a single paid call.

1. Call POST /inspect with the text and, optionally, a policy. Without payment the server responds 402 Payment Required and a payment options envelope.
2. Pay over x402. Construct a signed payment for an advertised stablecoin rail and resubmit with an X-Payment header carrying the base64 x402 envelope. The facilitator is never trusted; settlement is re-verified on chain.
3. Act on the decision. Send only if the decision allows; otherwise use the masked redacted text or hold the send.

POST https://h-gate.xr-utilities.ai/inspect
  X-Payment: <x402 envelope (base64)>
  Content-Type: application/json
  {
    "text":   "<the outbound payload>",
    "policy": "block-secrets-redact-pii"
  }
  -> 200 {
       "decision":     "allow | redact | block",
       "counts":       { "<type>": <n> },
       "detections":   [ { "type": "...", "sensitivity": "...", "detector": "...", "start": 0, "end": 12 } ],
       "redactedText": "... [REDACTED:<type>] ...",
       "policy":       "block-secrets-redact-pii",
       "receipt":      { ... }   // present only on a paid redact/block, when receipts are on
     }

policy accepts a named policy (block-secrets-redact-pii, redact-all, block-critical) or an inline policy object ({ "default": "allow", "rules": [ ... ] }); omit it for the default (block-secrets-redact-pii). The text field is bounded at 100,000 characters. GET /config returns the inspection price (inspectPriceUsdCents) and the accepted payment options per chain. Agents that prefer a tool interface can reach the same engine through the H-Series MCP passthrough at https://mcp.xr-utilities.ai/mcp under the h_gate_* namespace (h_gate_inspect, h_gate_config), with the identical x402 flow.

Detection schema and policies

Before calling /inspect, a caller can read what is detected and which policies exist. GET /schema returns the detection vocabulary (entity types, sensitivities, and actions) plus the named built-in policies (block-secrets-redact-pii, redact-all, block-critical), so the caller knows what will be flagged and which policy to apply. GET /config returns the current inspect price (inspectPriceUsdCents) and the accepted payment rails. Both reads are public and unauthenticated.

Custom detectors

A tenant can extend detection with a custom detector list (keywords, phrases, or regexes mapped to an entity type and sensitivity): internal codenames, an account list, partner secrets. Because a term list is itself sensitive, it is provisioned once out of band and stored per tenant, then referenced by tenant id on each inspect call, never carried inline on the request. On an enclave deployment the terms load inside the enclave, so the operator never sees them. The raw terms and any matched value are never logged or returned.

Provisioning is an operator (service-to-service) surface, not self-serve from the showroom: POST /admin/tenant-detectors { tenantId, terms } replaces a tenant’s whole list and POST /admin/tenant-detectors/remove { tenantId } reverts to the built-in catalog. Both are sister-key authenticated (ed25519), restricted to an admin allowlist, and bound so a sister can only write its own tenant namespace. To use a provisioned list, pass tenantId on the /inspect body; a caller may only name a tenant bound to its own sister identity, so a paid or anonymous caller cannot select one. To have a list provisioned, contact xr-utilities@proton.me.

Requestor attribution

A caller can optionally identify itself with an enterprise OIDC bearer token (Authorization: Bearer <jwt>) or a connected-wallet session header (X-Wallet-Authorization, base64url of {message, signature}). When present, the verified identity becomes the per-identity rate-limit key and appears as a requestor field on the response. A present-but-invalid credential is rejected with 401, never silently downgraded to anonymous. Both paths are enabled in production; sending no credential leaves the call anonymous and IP-limited. The credential identifies the caller only; it grants no new capability and is never the subject of the inspected payload.

To attribute an inspection to an OIDC identity: obtain a bearer token from a trusted issuer for the H-Gate audience, then send it as Authorization: Bearer <jwt> alongside the paid X-Payment header. To attribute via wallet: sign the one-wallet-logon session message for an allowed H-Series host and send it as X-Wallet-Authorization.

Enclave-safe by design

The detection engine is pure: text in, typed findings out, with no I/O, clock, or network. Raw content never persists; only content hashes, entity types, and finding spans cross the engine boundary. That purity is what makes the production target an AWS Nitro enclave, where the operator cannot see plaintext at all. The current pilot runs in software, so do not treat today’s deployment as enclave-isolated; the no-persistence property holds regardless.

Where to go next

• Try a free inspection from the showroom at h-series.xr-utilities.com/gate.
• For the exact endpoints, policy schema, and payment envelope, see the H-Gate reference.
• H-Gate anchors its proof through H-Seal and feeds a subject’s standing in H-Cert. See how the pieces compose in Start here.