Pecta’s security model is designed around one principle: the data that matters most to you — bid payloads, MCP tool inputs and outputs, user content — never leaves your infrastructure. Gates evaluate locally inside your process, and only the result metadata is batched and shipped to the cloud asynchronously. This section explains what Pecta stores, how API keys work, and how telemetry is authenticated.Documentation Index
Fetch the complete documentation index at: https://docs.pecta.ai/llms.txt
Use this file to discover all available pages before exploring further.
What Pecta stores
Pecta persists only evaluation metadata. User payloads are never transmitted, queued, or written to disk.| Stored | Not stored |
|---|---|
agent_id | Bid request / response payloads |
| Gate name | MCP tool inputs and outputs |
| Pass / fail boolean | User message content |
| Reason string (gate-generated, not from payload) | Any field from ctx.input or ctx.output |
latency_ms | |
timestamp (ISO 8601 UTC) |
@pecta/core SDK enforces this boundary before any network call is made: it strips the EvaluationResult down to the metadata fields above and discards everything else, including any details objects that might reference user data.
API key types
Pecta issues two key types with different trust levels:| Prefix | Type | Use |
|---|---|---|
pk_live_ | Publishable | Safe for config files, CLI arguments, and client-side code. Use for telemetry ingest and evaluation requests. |
sk_live_ | Secret | Server-only. Required for admin operations and HMAC signing. Never commit to source control or include in config files visible to end users. |
HMAC signing for telemetry
When you initialisePectaTelemetry with hmac: true, every batch POST to /v1/ingest includes an X-Pecta-Signature header:
HMAC-SHA256(secretKey, requestBody). The Pecta API verifies the signature before accepting the batch, ensuring that telemetry cannot be spoofed or replayed by a third party who only has your publishable key.
sk_live_ secret key. Keep it in an environment variable or a secrets manager — never hardcode it.
Gates run locally; only results reach the cloud
In SDK and proxy mode, gate evaluation is entirely local:- Your agent produces output.
engine.evaluate()runs gates inside your process (< 15 ms for RTB, < 50 ms for MCP).- The
EvaluationResultis returned to your code. telemetry.track(result)strips the result to metadata and adds it to an in-memory buffer.- The buffer is flushed asynchronously to
POST /v1/ingestin the background.
In REST API mode (Mode 3), gate evaluation runs server-side on Pecta infrastructure. This is the only mode in which agent output travels over the network. If this is a concern, use the SDK or proxy mode instead.
Per-mode key requirements
| Mode | Required key | HMAC |
|---|---|---|
| MCP proxy, local-only | None | — |
| MCP proxy, cloud telemetry | pk_live_ | Optional |
| In-process SDK, telemetry | pk_live_ | Optional with sk_live_ |
| In-process SDK, HMAC signing | pk_live_ + sk_live_ | Required |
| REST API, evaluation | pk_live_ | — |
| REST API, admin operations | sk_live_ | — |
Additional hardening
- Every
/v1/*endpoint is scoped to the authenticated organization — you can never read another organization’s data even with a valid key. - All endpoints are rate-limited. Exceeding the limit returns
429 RATE_LIMITED. - JSON-RPC messages larger than 1 MB are dropped by the proxy before gate evaluation (
--max-message-size). - No secrets appear in proxy or SDK logs. The publishable key prefix (
pk_live_) is safe to log; full key values are not.