Does a Fireworks API key identify the employee behind a request?

A Fireworks key identifies the user or service account that owns it. A backend service using one credential for many employees appears to Fireworks as that service account, rather than as each employee. Preserve the employee or agent identity at the application boundary. Protect it against caller modification, then bind it to the outbound request record. Fireworks audit logs and request-layer evidence can then be correlated without treating a workload credential as a human identity.

What changes when inference moves to a dedicated deployment?

Dedicated inference reserves GPU capacity for the account and uses a deployment resource as the model target. Placement and replicas become explicit operating decisions. So do scaling and deployment metrics. Per-user authorization also requires the upstream principal to reach the policy point. Recreating a deployment in another region creates a new route acceptance event.

Does zero data retention settle the security review?

Fireworks states that it avoids logging or storing prompt and generation data for open models without explicit opt-in. That provider retention control answers one part of the review. The enterprise still decides which authenticated principal may send a given data class. It separately approves the model and region. It also decides where application traces persist and how direct-call bypass is blocked. Training workflows can persist datasets, checkpoints, traces, and model artifacts, so they require their own review.

Does DeepInspect cover Fireworks training or model hosting?

Training and dataset storage remain with Fireworks and the customer platform team. Checkpoints, model artifacts, GPU configuration, and deployment lifecycle remain with those teams and the relevant storage owners. DeepInspect applies to a separate event: an authenticated HTTP model request that the application deliberately sends through the proxy. A training API call or model upload requires controls designed for that resource lifecycle.

Fireworks AI Security Needs a Route Acceptance Matrix

Fireworks exposes two production inference paths. Serverless sends authenticated requests to shared Fireworks-managed capacity and bills per token. On-demand deployments run a model on GPUs reserved for the account and bill by GPU time. Both paths accept HTTP model requests, but their model and placement decisions differ, as do scaling and evidence. Approve the complete route. The vendor name is too broad.

TL;DR

Approve each Fireworks route as a tuple: principal, API endpoint, model resource, region, data class, and evidence destination.
Separate global serverless from US-only serverless. Review dedicated deployments independently because their placement and operational evidence differ.
Use service-account credentials and Fireworks account controls as the provider baseline. Preserve the initiating user or agent separately.
DeepInspect covers authenticated HTTP model requests deliberately routed through its proxy. Training and model hosting keep separate owners.

Fireworks inference has three acceptance paths

The Fireworks serverless overview describes multi-tenant inference at api.fireworks.ai, with bearer authentication required on every request. Standard, Priority, Fast, and Ultra-fast modes can change the serving route or model identifier, while prompt caching is enabled by default and the response exposes token usage plus rate-limit details.

US-only serverless has a separate endpoint and model set. Fireworks instructs clients to call us.api.fireworks.ai with a US-scoped model resource. Dedicated deployments use account-owned deployment identifiers such as accounts/<account>/deployments/<deployment-id> and reserve GPUs for the account.

Both forms of serverless need separate route records. Dedicated inference needs its own. Each path needs a named owner. I would reject a production review that says only "Fireworks approved." That phrase hides the endpoint and model resource. It also hides the placement decision inside one green cell.

The route acceptance matrix

Build one matrix entry for every application and environment. The row needs these fields:

Caller: Record the workload service account and Fireworks credential identifier. Also preserve the initiating principal reference plus the application route. A shared credential without an upstream principal leaves the request attributable only to the workload.
Destination: Preserve the approved hostname. The provider endpoint may be api.fireworks.ai or us.api.fireworks.ai; the other approved destination is the proxy hostname. Record the exact inference path and expected TLS name.
Model target: Store the complete serverless router or model. For dedicated inference, store the deployment resource. Include the service tier when it changes routing behavior.
Placement: Name unrestricted, US-only, a multi-region such as US, or an approved single region. Attach the Fireworks policy state that enforces the choice.
Data class: List the prompt classes permitted on this route and the response handling rule. Tie the decision to a policy version.
Evidence: Keep the provider request result and application correlation ID. Add the policy decision. Preserve Fireworks usage fields and the deployment metrics reference where applicable.
Bypass result: Attempt the public Fireworks endpoint and an unapproved model resource. Also test a wrong regional endpoint and a request with missing identity context. Record the denied path beside the accepted one.

The most useful acceptance artifact is often one terminal screen showing the approved hostname and model resource beside a blocked direct call. An architecture diagram records design intent. The captured request establishes the deployed path.

Provider identity and model policy establish the baseline

Fireworks service accounts let applications use their own API credentials instead of a human credential. The account can assign a role such as inference-user, and Fireworks identifies the service account in its audit logs. Use one service account per workload boundary where operations and rotation ownership differ. Preserve the credential identifier in evidence while keeping the secret out of logs.

Enterprise model access policy adds an account-wide model allowlist or blocklist. Fireworks documents four separate capabilities: standard serverless inference, Fast serving, dedicated deployments, and training. The current policy applies to every user on the account and lacks per-user or per-group rules. That makes it a useful catalog boundary, while the application still owns finer authorization decisions for a specific employee, agent, route, and data class.

The per-role AI policy guide covers that second decision. A Fireworks service account authenticates the workload to the provider. The upstream application has to carry the initiating principal if the acceptance record must answer who caused one model request.

Residency is part of the approved route

Fireworks offers account-level data residency for Enterprise accounts. With US residency selected, every credential on the account is restricted to the regional endpoint and supported US model resources. Requests outside the configured region are rejected. Clients keep their existing route after the setting changes. They must be reconfigured for the regional endpoint and model set.

Dedicated placement has another lifecycle rule. Fireworks documents GLOBAL, US, CANADA, EUROPE, and APAC multi-regions, along with named single regions. Placement is chosen when a deployment is created. Moving a deployment requires a replacement in the target region and validation of that replacement. The old deployment must then be deleted.

Include the endpoint, model resource, deployment placement, and active residency setting in the acceptance row. A US endpoint paired with a global model identifier should fail. A dedicated deployment recreated in another region should re-enter review because its resource identifier and observed route changed. The AI egress control implementation guide explains how network policy can block a direct provider path after the approved route is captured.

Evidence has provider and request layers

Fireworks Enterprise audit logs cover account activity and data-access operations. Entries can be filtered by email, API key ID, event type, target API key ID, message, and resource. A reviewer can use those fields to identify who rotated a credential. The same fields show who changed a deployment or accessed a resource. Service accounts appear under a distinct Fireworks identity.

Dedicated deployments also expose a Prometheus-format metrics endpoint. Each series carries the base model and full deployment path. Separate labels identify the account and deployment ID. Available measurements cover request and error rates, prompt tokens, generated tokens, latency, concurrency, and cache utilization. They omit the authenticated enterprise user and application route. Prompt classification and the policy decision are also absent unless another request-layer system records those fields.

Correlate both layers because provider evidence covers activity inside the Fireworks account or deployment, while the request record explains why this principal was allowed to send this data class to this model at that moment. AI gateway architecture places that record at the routed HTTP boundary instead of asking the application to reconstruct it later.

Acceptance tests for serverless and dedicated inference

Run the matrix as a release gate and repeat it after route changes. For serverless, send an approved request through the configured hostname, then change the model resource to one outside policy. Repeat against the direct public endpoint. For US-only use, test a global endpoint and a non-US model identifier. Capture Fireworks response codes and the local policy result.

For a dedicated deployment, record its deployment resource and placement, then verify the observed destination. Attempt another deployment ID and a direct route that bypasses the approved policy point. Confirm that deployment metrics identify the expected account and deployment. Test missing and expired upstream identity separately. Then test an invalid Fireworks credential. Those failures belong to different owners.

The release record should name who can rotate the provider credential and who can update Fireworks account policy, while also identifying the owner of egress controls and the reviewer of request decisions. Rerun the tests after a base URL edit, model change, residency change, deployment recreation, service-account rotation, or policy update. Prompt-level DLP provides the classification method for content entering the accepted route.

DeepInspect

DeepInspect can sit on an approved Fireworks inference route when the application deliberately sends the authenticated HTTP model request through its proxy. It evaluates the supplied principal and role, plus the application route and data classification. The model destination and active policy are checked before forwarding. Each decision produces an independent request record that can be correlated with Fireworks audit logs and dedicated deployment metrics.

Fireworks keeps ownership of its serverless platform and account controls. It also owns the dedicated GPU service and provider evidence. Customer teams retain credential rotation, deployment placement, training data, model artifacts, and network egress. Direct calls that bypass the proxy remain outside DeepInspect, so the acceptance test must prove those paths are blocked. Book a technical deep dive at deepinspect.ai.