PDLSS on Endpoints

Endpoint policies mirror agent PDLSS — the enforcement engine evaluates both boundaries and the intersection wins.

Endpoint policies mirror agent PDLSS. When an agent calls an endpoint, the enforcement engine evaluates both boundaries — the agent's own and the endpoint's — and the intersection wins. The endpoint detail page at /endpoints/[id] exposes all five PDLSS dimensions:

How the endpoint boundary is enforced

Every axis reads "what this endpoint allows a calling agent to request" — axes the endpoint doesn't declare simply don't deny. Denials from the endpoint's boundary are namespaced endpoint.pdlss.* in the failures array so you can tell them apart from the agent's own pdlss.* failures.

Jurisdictions gate on the agent owner's country, not a header. The scope axis evaluates where the calling agent's owner is located — identity-verified country first, self-registered location as fallback — never the caller-declared jurisdiction field, which is not a compliance control. A block-list entry denies even when no allow-list is set; if the owner's country can't be resolved yet, the jurisdiction check is skipped and enforcement tightens as identity verification completes.

Anonymous-agent policy (unverifiedAgentPolicy, v2.3.0+)

Endpoint owners pick how the canonical verify-access flow handles callers who arrive without an ASTRA-id (no X-Astra-Id header, no agentId in the request body). One of four values, set at registration or via PUT /api/endpoints/:id:

• deny (default) — the caller is rejected. Response carries an advisory block pointing at the registration URL + docs. Strictest setting — recommended for endpoints handling sensitive operations.
• audit (v2.3.8+) — the caller is allowed through but AstraSync sets X-Astra-Unverified-Warning on the response. Activity feed records as "granted (audit)". Soft-launch mode for endpoints transitioning to registration enforcement. Disjoint vocabulary from the PDLSS-scope outbound warn value (see Inbound vs outbound).
• allow_partial — the caller is granted accessLevel="restricted" (browse-only, read-only) plus an advisory explaining what they can't do and how to upgrade. Recommended for content endpoints (catalog, public reads). v2.3.9: was guidance; renamed to remove the value-name collision with the guidance: {} help-payload object.
• allow_full — the caller is granted accessLevel="standard" with no PDLSS-scoped token but is advised to register for next time. Recommended for fully public endpoints where you still want activity attribution.

All three branches always emit a verification.unverified_* event and queue a blockchain audit record. Recognised platform agents (Claude / ChatGPT / Gemini / Cursor / Goose) get an auto-provisioned provisional ASTRA-id under the AstraSync admin org regardless of which branch fires.

Webhook signature verification (v2.3.0+)

Endpoint registration returns a webhookSecret ONCE in the response body (subsequent GET calls mask it). Save it — when AstraSync delivers a webhook, the request carries an X-AstraSync-Signature header with HMAC-SHA256 over {timestamp}.{rawBody}. Use the SDK helper to verify:

import express from 'express';
import { verifyAstraSyncWebhook } from '@astrasyncai/verification-gateway/webhooks';

app.post(
  '/webhooks/astrasync',
  express.raw({ type: 'application/json' }), // IMPORTANT: raw body
  (req, res) => {
    const result = verifyAstraSyncWebhook(
      req.body.toString('utf8'),
      req.headers,
      process.env.ASTRASYNC_WEBHOOK_SECRET!
    );
    if (!result.ok) return res.status(401).json({ error: result.reason });
    // ... handle event
    res.status(204).end();
  }
);

5-minute replay tolerance (configurable). Outbound delivery from AstraSync is a separate engineering track — the contract + SDK verifier ship now so partners can implement verification today against test signatures.