Security and credentials

Blazing Agents exposes a backend-only /v1 trust boundary. Use backend credentials to establish Tenant context, keep third-party credentials in their dedicated stores, and let the tenant's application authenticate and authorize its own end-users.

Backend-only access

A Blazing Agents API key grants Tenant-wide access and must stay in a trusted backend. Provider keys, MCP credentials, and internal service credentials must not enter browser or mobile clients either.

Keep credentials on the backend

Never place a Blazing Agents API key or another service credential in a browser bundle, mobile binary, public-prefixed environment variable, URL, or client-visible error.

An API key identifies a Tenant; it does not identify an end-user. End-user Attribution is an optional data label, not authentication or authorization. The tenant's backend must establish the end-user identity and enforce application access before calling the platform.

Authenticate a backend client

Load the API key from the backend environment and perform a harmless Tenant settings read:

import { BlazingAgents } from "@blazing-agents/sdk";

const apiKey = process.env.BLAZING_AGENTS_API_KEY;
if (!apiKey) {
  throw new Error("BLAZING_AGENTS_API_KEY is required");
}

const client = new BlazingAgents({ apiKey });
const settings = await client.tenant.get();

console.log(settings.name);

A successful call returns the authenticated Tenant's settings. Configure baseUrl as a backend setting when calling a non-default API origin.

API key lifecycle

API keys carry no scopes or per-Agent permissions. Creation returns the full ba_… API key once; later reads return only the API key record and a short display fragment. Authentication hashes the presented API key with SHA-256 and looks up the stored digest, so the full API key is not stored in the API key table.

There is no in-place rotation operation. Create a replacement, deploy it to every backend instance, verify it, and then delete the old API key. Deletion is a hard revocation; expired keys also stop authenticating.

Provider credentials

A Provider create request accepts one API key, stores it in Supabase Vault, and keeps only a Vault pointer and last-four display fragment in the product table. Responses never return the full key. Provider updates can change the name or base URL, not the credential or provider type; replace a credential by creating a new Provider, moving Agents, and deleting the old Provider.

Turn resolution decrypts a referenced Provider key through a Tenant-scoped database operation and uses it in the live dispatcher process. The stored-Provider test operation is the other scoped decrypt path. The key is not written to Session, Task, DBOS checkpoint, or Sandbox state.

MCP credentials and outbound access

MCP Connections support no authentication, bearer credentials, OAuth authorization code, and OAuth client credentials. Credential bundles are versioned in Vault; create, replacement, refresh, and deletion operations keep the product row and Vault state coordinated. Runtime resolution injects the active bearer or OAuth credential into the remote Streamable HTTP transport without exposing it as an Agent tool argument.

MCP setup and Tool failures return sanitized messages. Runtime checks reject discovered definitions or Tool results that contain protected credential values. Outbound MCP requests use a guarded fetch path that validates schemes and resolved addresses, bounds redirects, time, and response size, and removes sensitive headers on allowed cross-origin redirects.

Sandbox and service boundaries

API and task-worker processes authenticate to the private Sandbox service with scoped, short-lived ES256 service JWTs. Every file or exec operation also carries the durable admission grant, whose Tenant, Sandbox, Turn, holder, phase, and deadline are validated before dispatch.

AgentOS exposes writable access only under /workspace, denies guest networking and environment access, and applies supported resource limits. Provider and platform credentials remain in the API or task-worker dispatcher; they never become files or environment variables inside the Sandbox. Tenant Skill and Artifact object-storage buckets are private and are not mounted into its workspace.

Safe logging and operations

Load credentials from a backend credential store or server environment, and rotate them with an overlap period where the resource supports replacement-by-create.
Never log Authorization headers, plaintext Provider keys, MCP credential bundles, OAuth credentials, or full API keys.
Log stable request and resource identifiers only after checking that the corresponding error surface permits them.
Return sanitized application errors to clients. Do not assume arbitrary application logs are automatically redacted; explicitly omit credentials and sensitive request bodies.
Treat credential fragments as display aids, not authentication material.

See Tenancy and end-user attribution, MCP connections, and Sandboxes for the surrounding ownership and runtime model.