Edge verification

Trusted Agent Gateway

The Trusted Agent Gateway (TAG) is AstraSync's verification gateway at the CDN edge: it classifies and (optionally) verifies every inbound agent request in front of your existing site — with zero site changes. Run it in observe mode first (verify, classify, and record everything; block nothing), then flip to enforce from the dashboard when the traffic picture looks right.

Which adapter do I need?

Your setupPackageConnection captureTLS fingerprint (JA3/JA4)
AWS (CloudFront / Lambda@Edge)@astrasyncai/adapter-lambdaFull: IP, ASN, geo, TLS version+cipher, HTTP version, device class, header structureJA3 + JA4 (2.2.0+, all HTTPS viewers)
Cloudflare Workers@astrasyncai/adapter-edge/cloudflareFull: IP, ASN + AS org, geo, TLS version+cipher, PoP, TCP RTTJA3 + JA4 on Bot Management zones only
Vercel Edge Middleware@astrasyncai/adapter-edge/vercelIP + geo (country, region, city, time zone)JA4 with BotID enabled
Fastly Compute (your own service)@astrasyncai/adapter-edge/fastlyIP; geo/ASN via the opt-in geolocation flag

If spoof-resistant client fingerprinting is the deciding factor for a new deployment, CloudFront (via adapter-lambda) is currently the only platform that yields both JA3 and JA4 unconditionally.

Deploy on AWS (CloudFront)

adapter-lambda ships a CloudFormation template, deploy script, and a step-by-step runbook (staging → production → rollback). Your DNS zone stays where it is — the cutover is a single ALIAS/ANAME record.

npm install @astrasyncai/adapter-lambda
# then: configure + run infra/deploy.sh — see the package runbook
# (infra/RUNBOOK.md) for the full rollout procedure

The template's origin request policy whitelists the full CloudFront-Viewer-* signal set including JA3/JA4 fingerprints and header-structure signals. Stacks deployed before 2.2.0 pick these up with a normal stack update — no distribution replacement, no downtime.

Deploy on Vercel / Cloudflare / Fastly

npm install @astrasyncai/adapter-edge

// Vercel: middleware.ts
export { default } from '@astrasyncai/adapter-edge/vercel';

// Cloudflare Workers / Fastly Compute: see the per-platform
// entrypoints in the package README

All platforms consume the same dashboard-managed policy — mode, verification depth, and per-path rules change from the dashboard with no redeploys.

What gets captured — and what your platform determines

IntegrationConnection layerFingerprints
Edge adapter (TAG)Full — native platform signalsPer the adapter table above
Merchant SDK behind a CDN you controlDerived — geo/ASN/TLS promoted from your CDN's injected headersCloudflare: JA3+JA4 (plan-dependent). CloudFront: JA3+JA4 once you add the fingerprint headers to your origin request policy
Merchant SDK behind a platform-managed CDN (Railway, Render, Fly, Heroku…)IP only (x-forwarded-for)None
Merchant SDK, no CDNAbsentNone

"Behind Fastly" is not the same as "receives Fastly's headers": platform-managed CDNs (Railway, Render, Fly, Heroku) do not forward their provider-specific geo/TLS headers to customer origins — only the client IP arrives. If connection-layer signals matter on a managed platform, deploy the TAG in front of it: that is exactly what the edge adapters are for.

Failure posture

Fail posture follows success posture. Paths in observe mode allow by default, so they fail open: if AstraSync is unreachable, traffic passes through untouched — your site never breaks because of the gateway. Paths in enforce mode deny by default, so they fail closed: when verification infrastructure is unavailable, agent traffic on an enforced path receives 503 with error code VERIFICATION_UNAVAILABLE and a Retry-After header.

  • 503 VERIFICATION_UNAVAILABLEmeans retry with backoff — the caller's identity was never evaluated and no denial was recorded.
  • 403 means register first (or fix the mandate) — retrying without changing anything will not help.
  • Human browser traffic and generic bots are never gated in either mode, so an AstraSync outage cannot affect your human visitors.
  • A misconfigured property key (revoked/rotated) fails openin both modes — agents are never blocked by the property's own credential problem; the property owner is alerted instead.

The commerce bridge applies the same principle: catalog browsing degrades to the anonymous tier when verification is unavailable, while checkout and settlement fail closed.

Running the SDK behind the TAG

If your origin also runs the merchant SDK middleware, set trustVerifiedHop: true(SDK 4.3.0+) so the origin honours the gateway's X-Astra-Verified-Hop marker and skips the duplicate verify-access call at authenticate/authorize depth. The gateway strips any inbound copy of the marker, so it can only originate at your edge. At the default classify depth no marker is emitted and the origin verifies as usual.

app.use(createMiddleware({
  // ...your existing config
  trustVerifiedHop: true, // only behind the TAG or a trusted boundary
}));

Learn more