Legal
Data governance.
How execution data is actually handled on the platform — the mechanisms, not the marketing. Last updated August 2026.
What we collect.
Execution records and events
When your SDK or REST client submits an execution, we store the execution record — model, provider, status, tokens, latency, cost, trace metadata — and every event submitted for it: tool calls, payloads and context.
Agent profiles
Agent registration captures name, type, description and an optional email. Every agent is scoped to one organization and one project.
Consent policies
For each agent we store a consent policy (consent_policies): whether anonymization is required (requires_anonymization), which use cases are allowed (allowed_use_cases), a privacy scope (default private) and a retention window (retention_days).
How data is protected.
Payload redaction at ingest
Every event payload passes through the redaction library (redactPayload / redactString in apps/api/src/lib/redact.ts). Field-level: keys like password, secret, token, authorization and similar are replaced with [redacted]. Pattern-level: emails, API keys, phone numbers, SSNs, credit cards, IPv4 addresses and private keys are stripped. Nesting beyond 8 levels is truncated, and payload length is capped at ingest (2,000 characters when anonymization is required, 10,000 otherwise).
API keys are hashed, never stored
Only the SHA-256 hash of an API key is stored (api_keys.key_hash), plus a short prefix for identification. The plaintext key exists once — at issuance. The same applies to external access credentials: a mag_ credential is shown once and only its hash is retained.
Organization isolation
Every query is scoped by organization_id. No code path can read another tenant's executions, events, agents, projects or datasets — the scope is part of the SQL, not left to application discipline.
Anonymization policies
Organizations can define anonymization policies (anonymization_policies) listing fields to strip, with optional differential-privacy parameters (epsilon, delta) for release-time guarantees.
Who can access data.
Your organization only
Within the platform, only your organization's keys can read your executions and events — and each key is itself scoped to a project, with its own permissions and optional expiry.
Access grants for data consumers
External data buyers authenticate with access grants (access_grants): read-only credentials bound to one organization and an explicit list of agent IDs. Every read is recorded in the access audit log (access_audit) for invoicing. Grants are revocable at any time.
Consent-aware delivery
The external read API (/v1/access/executions in access-executions.ts) checks each agent's requires_anonymization flag and redacts payloads, error strings, summaries and reasoning before anything leaves your tenant. If no policy exists, anonymization defaults to on.
Public endpoints
The public API (/v1/public/*) exposes only aggregate stats and metadata — never raw payloads.
Retention & immutability.
History is never overwritten
Events are append-only and immutable — there is no update or delete path for event records. Execution records transition through lifecycle status updates (started, completed, failed) but their history is never hard-deleted. A soft-delete flag (deleted_at) exists for dashboard and access filtering only; records are physically retained.
Versioned, immutable datasets
Datasets are released as immutable versions (datasets + dataset_versions): each version records its record count, schema definition, storage path, checksum and a change summary. A released version can be cited, audited and reproduced — it cannot be silently altered.
Retention windows
Consent policies carry a retention_days setting per agent, and policy changes are themselves auditable. Contact requests are retained for 12 months.
Everything can be replayed
Because history is immutable and versioned, any execution, pipeline stage or dataset release can be replayed or reproduced exactly as it happened — a prerequisite for auditability.
Your control.
Per-agent consent, changeable
Consent policies are per agent: toggle requires_anonymization, restrict allowed_use_cases, or withdraw consent entirely. The platform checks consent against the use case at every point of downstream use. Withdrawal stops future use; already-released dataset versions remain immutable by design.
Keys and grants you can revoke
API keys can be deleted (soft-deleted, with expires_at support), and access grants can be revoked instantly — a revoked grant stops working on its next request.
Audit trails
Access reads are logged per grant, per request, with row counts and request metadata — so you can see exactly who read what from your tenant, and when.
Questions and requests
For access, correction or deletion requests about your data, write to khalidkhan46572@gmail.com. We answer.