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.
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.
Do not put sensitive content inside gate reason strings in custom gates. Reason strings are stored as-is in the Pecta cloud and appear in dashboard event feeds.
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. |
If a sk_live_ key is exposed, revoke it immediately from Settings → API keys in the dashboard. Revocation takes effect within seconds.
HMAC signing for telemetry
When you initialise PectaTelemetry with hmac: true, every batch POST to /v1/ingest includes an X-Pecta-Signature header:
X-Pecta-Signature: sha256=<hex digest>
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.
const telemetry = new PectaTelemetry({
publishableKey: process.env.PECTA_PUBLISHABLE_KEY!,
secretKey: process.env.PECTA_SECRET_KEY!,
hmac: true,
});
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
EvaluationResult is 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/ingest in the background.
Steps 1–3 complete before any network activity begins. If the flush fails, Pecta retries once after 1 second and then drops the batch silently. Gate decisions are never delayed by network conditions.
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.
