Never submit
- prompts or transcripts;
- credentials, tokens, cookies, or authentication payloads;
- names, email addresses, or free-form personal data outside the request-observation allowlist;
- raw customer content;
- raw tool inputs or outputs;
- full product responses;
- unknown report fields.
agent_reports_user_statement, agent_reports_current_task, and agent_inference as equivalent evidence.
Automatic request observations
The official Express and Fastify adapters record a bounded allowlist of facts the company server already sees: framework-resolved client IP, HTTP method, user agent, accepted language, referrer origin, and User-Agent Client Hints. These observations are audit facts, not proof of identity, and Epode never merges customers or constructs sessions from them. Cookies, authorization, request bodies, full referrer URLs, query strings, forwarding-header chains, and arbitrary headers are excluded. MAC addresses cannot cross a routed HTTP connection and are not available to collect. Request observations are linked to the exact interaction and are physically deleted when that interaction is purged under the product’s 1–365 day retention policy. Configure Expresstrust proxy or Fastify trustProxy
only for proxies you control; otherwise the framework’s direct peer address is retained.
Purpose separation
product_personalization and targeted_advertising are separate permission scopes. Approval, retrieval, and
decision evidence for one cannot be reused for the other. A company must request advertising permission
explicitly; generic personalization consent is insufficient.
The company may request durable memory, but the customer can approve sharing without approving memory. Revoked,
declined, expired, and wrong-purpose items are omitted from customer-context retrieval immediately.
Epode rejects unknown fields and common sensitive patterns recursively. Your product and the submitting runtime are
still responsible for keeping sensitive material out of summaries and finding details.
Product key
Theaf_live_... key is configured as EPODE_API_KEY and belongs only in trusted server configuration. SDKs derive a signing key with SHA-256 and use
it to create a scoped afr2_... capability locally. A capability never contains the raw customer reference,
product response, prompt, or personal identity. Ask-once capabilities do contain a public key ID, a
pseudonymous HMAC-derived consent subject, and a non-negative consent revision so Epode can remember
the choice for that product scope without accepting stale updates.
Setup shows a newly created or rotated key only for the current page load and does not persist the full secret in
browser storage. Move it directly into a deployment secret manager. Never paste it into shell history, CI output,
a committed .env file, browser or mobile code, an MCP client, a product-auth header, or a support message. If the
value is lost, rotate it; Epode cannot reveal it again.
The company-owned enrichment relay never forwards this key. It accepts only an aqr1_ request handle and the
allowlisted consent or answer body, then forwards them to fixed Epode endpoints without redirects.
Data retention
Team owners and admins can set each product’s retention period to any whole number from 1 to 365 days in Collection policy. A shorter period changes dashboard filtering immediately, so feedback reports, interactions, request observations, and sessions outside the retained window stop appearing right away. Physical deletion runs on a schedule and can take up to the scheduled purge interval. The purge permanently removes expired feedback, interactions, request observations, and sessions. Durable Ask-once permission is a separate data control. It survives the telemetry retention window so a customer is not asked again merely because older product data expired. That permission remains until it is explicitly changed or the product is deleted; changing retention alone does not reset it.Capability
- scoped to one interaction;
- expires within two hours;
- write-only;
- accepts one idempotent report;
- rejected when forged, expired, or used for a different interaction.
Agent and customer identity
Epode does not identify an agent or invent customer identity. HTTP runtime headers and MCP client information are unverified hints.accountRef and userRef are opaque values supplied by verified product authentication;
anonymousRef is a stable product-owned first-party pre-login ID. customerRef exists only for durable Ask once
compatibility and, when richer identity is present, must exactly equal accountRef rather than identifying only a
user. Session references come only from server/product state that already proves a journey and are hashed before
storage. Ask-once consent uses an HMAC-derived subject, so neither the raw customerRef nor stored telemetry
references are exposed to the customer’s agent in the feedback envelope. Use non-personal internal identifiers
only; never names, emails, prompts, caller values, agent arguments, or unverified token claims.
Origin safety
Agent-side HTTP helpers require an explicit allowlist of HTTPS submit origins. MCP servers validate every present browserOrigin against an explicit allowlist. Empty MCP origin allowlists reject browser-originated requests.