Security Architecture

LetsPing is a trust anchor for agent-to-agent and agent-to-SaaS transactions. It provides three primitives: identity verification (who signed this request?), behavioral enforcement (does this sequence of calls look normal?), and settlement (did value actually move?).

We operate in the HTTP layer — the same layer where your agent calls Stripe, your storefront, or another team's service. This is not a blockchain, a decentralized identity system, or a credential ecosystem. If you later plug in on-chain identity, the attestations we produce can feed into it. Our value is the operational trust layer that works with the stack you already have.

This page documents the implementation details behind each primitive. The SDKs (Python, TypeScript) are open source. The core monorepo is proprietary, but we describe the internals here so that you can evaluate the architecture.

I. Agent identity and constant-time verification

Every agent gets a credential pair: an agent_id and a secret. Each ingest call is signed with HMAC-SHA256 over the canonical JSON payload. Downstream services can verify the signature and the chain of handoffs without trusting the caller's self-reported identity.

Signature comparison uses crypto.timingSafeEqual with equal-length buffers. This prevents timing side-channel attacks where an adversary probes the server with guessed signatures and infers correctness from response latency. The same pattern is applied to Slack webhook verification.

Agents can register without a human account via a one-time signup token that provisions an organization, a project, and an API key in a single atomic operation. This is the entry point for fully autonomous agent onboarding.

II. Behavioral enforcement: Markov-chain profiling

The behavioral engine learns what "normal" looks like for each agent by building a first-order Markov chain over payload structure. Each ingest call is reduced to a skeleton hash — a fingerprint of the JSON key structure, stripped of values. The skeleton hash becomes a node in a per-agent, per-service transition matrix stored in Redis.

Transition counts are updated atomically via a Lua script that applies a dynamic decay every 10 runs: no decay for counts ≤1, very light decay for low-support edges (≤5, ≤20), and 1% for high-volume edges. This keeps rare-but-legitimate paths from vanishing too quickly and makes it harder for an attacker to "normalize" malicious behavior via a slow drip of variations. The engine computes an edge anomaly score as −log₂(p + ε), where p is the transition probability. Higher scores mean the transition was more surprising relative to the learned baseline.

Only high- or critical-priority baselines, or those with rich Markov enabled, are eligible to progress to locked; others remain in shadow or soft-lock and contribute metrics only. High-volume agents (≥500 runs) switch to a wider window of 15 and a stricter stability threshold of 0.015 to reduce false positives. Critical-priority requests get their own chain so that rare-but-legitimate critical paths don't pollute the primary baseline.

The engine also supports a rich Markov mode where node identity is hash(service, coarseAction, skeletonHash), giving finer-grained baselines for agents that use a single service endpoint for multiple action types.

This runs alongside the rule-based guardrails (velocity limits, loop breakers, pattern matching, PII scanning, cost guards, sequence entropy, media guards) documented in Settings → Guardrails. The Markov chain provides zero-config anomaly detection; the guardrails provide explicit policy enforcement. Both can flag, pause, or reject a request independently.

III. Trust scores with Sybil resistance

The trust score API returns a 0–999 score for an agent so that downstream services (storefronts, carrier APIs, other agents) can decide how much to trust a specific request. This is operational trust for the API call at hand — not a global credit score or on-chain reputation.

The score is composed of two weighted components:

An attacker who runs two agents that hand off to each other in a loop would max out the volume component but produce zero third-party outcome data. We handle this by discounting the volume score by min(1, totalOutcomeEvents / 20). Self-handoff loops with fewer than 20 real outcome events from other organizations are penalized proportionally.

Every trust score response is HMAC-signed so the receiving party can verify it was issued by LetsPing and not forged. The response also includes a caveat field:

"Volume is more reliable when it includes many handoff_outcome events (third-party verification). Cross-organization handoffs will be weighted when data exists. Fake volume (e.g. self-handoff loops) is a known spoof vector and is mitigated by caps and outcome weighting."

We include this caveat in the API response because we believe transparent scoring builds more trust than opaque scoring.

IV. Settlement: charge before grant

The pre-fund endpoint for agent credits does not increment a counter because an agent asked for more units. It charges the organization's Stripe payment method for the requested amount first, then credits. The Stripe PaymentIntent uses the customer's saved default payment method and settles synchronously before the balance is updated.

This matters because a grant-first model means any holder of a project API key can drain unlimited value. We prevent that by making settlement real: no charge, no credit.

Pro-tier organizations use metered billing and never encounter the pre-fund flow. They are billed for actual usage at month-end via Stripe metered subscriptions. The Hobby tier uses pre-fund because there is no recurring subscription to meter against.

V. Circuit breakers, idempotency, and audit

Outbound calls to Stripe, QStash, and webhook endpoints are guarded by in-memory circuit breakers. After 5 failures in 60 seconds (10 for webhooks), the circuit opens for 30 seconds and returns a clear error rather than piling load on a failing dependency. The circuit then enters a half-open state, allowing one trial request through before fully closing.

Ingest and handoff-outcome endpoints accept optional idempotency keys. The mapping is stored in Redis with a 24-hour TTL so that agent retries do not create duplicate requests or duplicate outcome records.

State-changing agent actions (fund, rotate, register, approve, reject) are written to a structured audit log. Every API response can carry a trace ID so that debugging can follow a request across services.

VI. Threat model summary

VII. What this is not

LetsPing does not issue on-chain credentials, replace decentralized identity, or provide a global reputation layer. We answer a narrower question: in this HTTP request, who is the agent, did they sign it, is this sequence of calls normal, and did settlement happen? That question is orthogonal to how you do long-term identity or settlement on a chain — and it needs to be answered regardless.