> For the complete documentation index, see [llms.txt](https://docs.mediafier.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediafier.ai/trust/enterprise-readiness.md).

# Enterprise Readiness

The five questions enterprise reviews focus on — identity, tenancy, authorization, audit, governance — and what is in place for each.

> **Identity. Tenancy. Audit. Governance. Trace correlation.** This page consolidates what an enterprise security or procurement reviewer needs in one place, in the language those reviews are conducted in.

***

## The five questions enterprise reviews focus on

Enterprise security and procurement reviews typically focus on the same five questions. Each answer below is enforced consistently across every surface — agent-first (CLI + MCP), Slack & Teams, and Pippa chat — by the same gateway chain.

| Pillar                     | What to verify                                          | What's in place                                                                                                                                                                                                                                                               |
| -------------------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Identity**               | Who issues identity, and how is it verified at runtime? | Auth0 is the sole identity provider. Bearer access tokens are verified server-side at the gateway entry, before any tool call runs. No service-account fast-path; no internal client mode.                                                                                    |
| **Tenancy**                | How is one customer's data isolated from another's?     | Organization context is server-derived from the authenticated principal. Row-level isolation enforced at the platform's data layer blocks cross-org reads. The boundary is enforced from below, not by application convention.                                                |
| **Authorization**          | Who decides what each caller can do?                    | Per-tool, per-org permission checks against the organization's authorization model. Enforced before rate limiting, before billing, before dispatch. Allowed and refused decisions both produce an audit row; a refusal returns a structured error carrying the same trace ID. |
| **Audit & evidence**       | Can the customer reconstruct what happened?             | Every governed call carries an `X-Trace-Id` that joins audit, billing ledger, and runtime logs. Audit rows are append-only by data-layer enforcement. Evidence Cards from MediaClaw runs are immutable. Provenance Passports on media assets are append-only.                 |
| **Operational governance** | Can the customer control spend, throttling, and access? | Per-org wallets and credit ledger; per-org rate limits; org-admin notifications; per-tool spend visibility. The gateway enforces the controls; org admins configure how aggressive the controls are.                                                                          |

Each answer is covered in depth in its dedicated page — [The Gateway](/platform/gateway.md), [Identity & Authentication](/trust/identity-and-authentication.md), [Multi-Tenant Organization Model](/trust/multi-tenant-organization-model.md), [Audit, Observability & Compliance](/trust/audit-observability-and-compliance.md), and [Credits & Billing](/overview/credits-and-billing.md). This page collects the answers in one place because enterprise reviews tend to evaluate them as a single block.

***

## What the gateway enforces on every call

```
Request enters gateway
  │
  ▼  Identity (Auth0 token verified)
  ▼  Organization (server-derived from principal)
  ▼  Authorization (per-tool, per-org policy)
  ▼  Rate limit (per-org throttling)
  ▼  Billing (credit reservation against the org's wallet)
  ▼  Audit (append-only record, trace-correlated)
  ▼  Dispatch (adapter-owned transport)
  │
Response with X-Trace-Id
```

Every surface walks the same chain. The control plane is one chain; there is no second one.

***

## What this posture supports in procurement reviews

The chain above produces three properties procurement teams typically need to confirm:

* **Single enforcement chain.** A security team auditing the platform sees one ingress and one chain, not forty per-tool integrations. That alone short-cuts a lot of procurement review.
* **Reconstructable evidence.** Any incident, dispute, or audit request resolves against trace IDs. The customer-support correlation walk-through in [Audit, Observability & Compliance](/trust/audit-observability-and-compliance.md) holds at procurement scale.
* **Tenant isolation at the data layer.** The boundary is enforced where the data lives, so a handler bug does not by itself widen what a caller can read; cross-organization access is tested in CI.

### What you'll only see under NDA or in the customer agreement

The following are deliberately not published; they are shared during procurement under NDA or negotiated into the customer agreement:

* Specific compliance certification badges and audit reports — shared under NDA during procurement.
* Hard SLA, latency, or uptime numbers — procurement-binding performance terms live in the customer agreement.
* A specific retention term in years — retention is supported per organization configuration and enterprise policy; the binding term lives in the customer agreement.
* Named third-party tooling for observability or data export — integration patterns are configurable customer-side; specific vendor relationships are not declared publicly.

***

## What customers and partners get from this posture

For an organization adopting Mediafier:

* One identity provider for every surface. SSO federates into Auth0; every agent, operator, and partner ends up on the same chain.
* One audit trail. The chain that records every call also records every authorization decision, every billing movement, every runtime outcome — joined by one trace ID.
* One governance contract. Marketplace resources, partner-published tools, and first-party capabilities all live under the same enforcement chain, so there is no second class of resources to evaluate separately.

For a partner reselling the platform:

* The customer's security team reviews one enforcement chain, not forty per-tool integrations.
* The compliance investment is centralized — partners don't have to re-implement audit, identity, or tenant isolation per engagement.
* The control plane scales as the customer's adoption broadens.

***

## What this page is not

* It is not a SOC report. Specific certifications and audit reports are shared under NDA during procurement.
* It is not a contract. Hard commercial commitments — SLA terms, retention numbers, refund language — live in the customer agreement.
* It is not a substitute for the per-pillar pages. This page is the single-block summary; The Gateway, Identity & Authentication, Multi-Tenant Organization Model, Audit, Observability & Compliance, and Credits & Billing are the detail.

***

## Where to go next

| If you're…                                            | Read next                                                                         |
| ----------------------------------------------------- | --------------------------------------------------------------------------------- |
| Looking at the gateway in detail                      | [The Gateway](/platform/gateway.md)                                               |
| Looking at identity                                   | [Identity & Authentication](/trust/identity-and-authentication.md)                |
| Looking at tenancy                                    | [Multi-Tenant Organization Model](/trust/multi-tenant-organization-model.md)      |
| Looking at audit and observability                    | [Audit, Observability & Compliance](/trust/audit-observability-and-compliance.md) |
| Looking at credits, billing, and operational controls | [Credits & Billing](/overview/credits-and-billing.md)                             |
| Looking at how the platform sits in a larger stack    | [Where Mediafier Fits](/overview/where-mediafier-fits.md)                         |