Navigation▼
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 setup | Package | Connection capture | TLS fingerprint (JA3/JA4) |
|---|---|---|---|
| AWS (CloudFront / Lambda@Edge) | @astrasyncai/adapter-lambda | Full: IP, ASN, geo, TLS version+cipher, HTTP version, device class, header structure | JA3 + JA4 (2.2.0+, all HTTPS viewers) |
| Cloudflare Workers | @astrasyncai/adapter-edge/cloudflare | Full: IP, ASN + AS org, geo, TLS version+cipher, PoP, TCP RTT | JA3 + JA4 on Bot Management zones only |
| Vercel Edge Middleware | @astrasyncai/adapter-edge/vercel | IP + geo (country, region, city, time zone) | JA4 with BotID enabled |
| Fastly Compute (your own service) | @astrasyncai/adapter-edge/fastly | IP; 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 procedureThe 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 READMEAll 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
| Integration | Connection layer | Fingerprints |
|---|---|---|
| Edge adapter (TAG) | Full — native platform signals | Per the adapter table above |
| Merchant SDK behind a CDN you control | Derived — geo/ASN/TLS promoted from your CDN's injected headers | Cloudflare: 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 CDN | Absent | None |
"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.403means 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 open in 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
- Package guides: adapter-lambda · adapter-edge · verification-gateway
- Merchant onboarding guide and test your integration
- Traffic appears on your endpoint's dashboard the moment observe mode is live — that includes the agent traffic you can't see today.