# Farka security

Farka fails closed around data, spend, and delivery. These are controls enforced
in the product lifecycle, not a logo wall.

## Tenant isolation

Jobs, datasets, quotes, provider runs, artifacts, billing records, and audit
events all carry explicit workspace and account ownership.

## Credential hygiene

Session and access tokens are stored as hashes. Secrets remain in the deployment
secret manager and are not persisted in provider configuration rows. Workspace
access tokens are shown once, prefixed `farka_`, stored as a SHA-256 hash, bound
to one workspace, scoped, and expire after 90 days by default.

## Delivery locks

Artifacts stay unavailable until quality, settlement, provider usage, and
target-specific delivery checks pass.

## Safe retries

Mutation replay is workspace-scoped and body-bound. Duplicate provider
submissions and duplicate customer charges fail closed. Every mutating API call
takes an `Idempotency-Key`; a conflicting reuse returns `409`.

## Compute teardown

A provider accepting a shutdown request is not treated as proof. Farka checks
the underlying capacity until it is no longer billable or reports a terminal
teardown failure.

## Bounded inputs

Strict JSON shapes, upload limits, public-URL controls, content checks, and
unsupported-field rejection run before any sensitive work.

## Data residency

A run can be pinned to the European Union or the United States. Pinning is
enforced rather than advisory: a run that cannot be placed in region fails
instead of relocating.

## Responsible disclosure

Email edi.hasaj@farka.ai with the affected surface, reproduction steps, and
impact. Please avoid accessing customer data or spending compute credits while
testing.