Reference

Inbound vs outbound unverified-policy fields

AstraSync has two policy fields with similar names but distinct purposes. Setting one does not affect the other. This page exists because conflating them is the single most common configuration mistake.

Inbound

Field

kya_counterparty.unverified_agent_policy

Wire values (v2.3.8+)

deny | audit | allow_partial | allow_full

What happens when an unregistered agent calls into your endpoint. Owned by the endpoint operator (you, when you operate the inbound surface). Set on the endpoint detail page in the dashboard.

Outbound

Field

PDLSS scope.unverifiedCounterpartyPolicy

Wire values

allow | warn | deny

What happens when your agent calls out to a counterparty that AstraSync has not verified. Owned by the agent owner (you, when you operate the outbound caller). Set in the PDLSS boundary editor on the agent detail page.

Why disjoint vocabularies

Earlier versions used the value warn on the outbound field. The natural temptation was to add the same word to the inbound field with similar (but distinct) semantics. That would be a footgun: anyone reading raw JSON config — unverifiedAgentPolicy: 'warn' in a debug log, infrastructure-as-code template, or audit dump — would have to remember which 'warn' they were looking at.

v2.3.8 deliberately picks a different word — audit— for the inbound field's soft-launch mode. Different vocabulary makes conflation impossible.

When you might set both

A merchant whose endpoint also runs an outbound agent (for example, a checkout service that calls suppliers' APIs on behalf of the buyer) sets both:

Inbound → audit: anonymous buyers can browse, but every request is tagged with X-Astra-Unverified-Warning so you can soft-launch new policy.
Outbound → warn: your checkout agent will still call suppliers AstraSync hasn't verified, but flags those calls in your activity feed for review.

Activity-feed behaviour