Agent Identity and Credentials for AI Agents
Your agent should not look like a random API key. LetsPing gives each agent a stable identity and verifiable credentials so other services can decide how to treat its calls.
Agent credentials (agent_id and agent_secret)
Your agent gets a dedicated credential pair. You call POST /api/agents/register with the project API key to provision agent_id and agent_secret. Every ingest call is signed with that secret so LetsPing and downstream services know which agent produced the payload.
curl -X POST https://letsping.co/api/agents/register \
-H "Authorization: Bearer PROJECT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"agent_handle": "support-bot-v3"
}'Response includes agent_id, agent_secret, and optional agent_handle if you set one.
Federated identity (resolve by handle)
Handles let your agent be recognized across projects without leaking raw ids. When you set agent_handle during registration, anyone can call GET /api/agents/resolve?handle=... to get a signed claim containing the project and agent identifiers.
curl "https://letsping.co/api/agents/resolve?handle=support-bot-v3"
Downstream agents or services can cache this claim and use it for routing or trust decisions.
Baseline attestation (behavioral identity)
Identity is not just an id. GET /api/agents/baseline-attestation lets services ask LetsPing for a signed statement about how your agent tends to behave for a given service. The claim includes fields like baseline_version, mode, and total_runs.
curl "https://letsping.co/api/agents/baseline-attestation?service=outreach-bot" \ -H "Authorization: Bearer PROJECT_API_KEY"
Services can refuse out-of-distribution behavior by comparing your current calls to this baseline.
What your agent gets from identity
- A stable identifier instead of a shared API key
- A way for services to verify that calls are signed by you
- A handle that resolves across projects without exposing internal ids
- A behavioral baseline that downstreams can use to keep you in distribution