How to let AI agents access your API safely
If you run an API, an MCP server, or a website, AI agents are already in your traffic. Some are crawlers you can ignore. A growing share are task agents acting for real customers: comparing your catalog, calling your endpoints, trying to buy. How you respond is now a product decision, not just a security one.
The three default postures, and why they fail
Block all agents. Robots rules and bot detection will filter most of them out, along with the revenue they carried. An agent turned away at your door completes the task with a competitor that let it in.
Allow everything. Treating agent traffic like human traffic means unattributed load, scraping, card testing, and no answer when something goes wrong. "A bot did it" is not an audit trail.
Per-agent API keys. Issuing keys to every agent developer who asks does not scale, and a key names an account rather than an agent: no model, no operator, no current standing, no permissions. See AI agent identity vs API keys.
The workable posture is the middle path: verify, then serve. Let any agent in that can prove who it is and what it is allowed to do; hold or refuse the rest.
Verify, then serve: the integration
AstraSync gives you that check as a single endpoint. When an agent arrives carrying its ASTRA-ID (its registered identity, see What is Know Your Agent):
- Your service calls
POST https://astrasync.ai/api/agents/verify-accesswith the presented identity and the requested action. - AstraSync returns the agent's live status: registered or not, standing, trust signals, and whether the action fits its declared permission boundary.
- You serve, throttle, sandbox, or refuse based on a real answer instead of a user agent string.
- For sensitive operations you can require a runtime challenge, a live nonce exchange that defeats replayed or stolen identities.
Unregistered agents are not a dead end. Point them at your policy: AstraSync publishes a machine-readable path (/docs/agent-access, plus llms.txt conventions) that tells an arriving agent exactly how to register and return verified, often within the same session.
Tiering instead of a binary gate
Most operators do not want one yes/no door. A practical policy:
- Verified agents: full access within their permission boundary.
- Identified but unregistered agents: read-only or rate-limited access, with a machine-readable pointer to registration.
- Anonymous automation: existing bot handling applies.
This converts agent traffic into registered, attributable demand over time instead of driving it away. Network-wide, identified-but-unregistered visits outnumber verified ones by hundreds to one today: that is not a threat statistic, it is a conversion queue.
Get started
The merchant guide walks through gating an API, MCP server, or storefront with verify-access, including reference middleware you can clone and configure. Most integrations are serving verified agent traffic the same day.