Token Audit · SaaS live

Token Audit

Keep records of enterprise AI calls and trace risk signals. Token Audit mirrors prompts, model responses, reasoning traces, and tool calls from the enterprise gateway to an independent service, encrypts them per tenant, and runs basic rule checks. Enterprises can access only their own data after signing in; every content view is logged.

Explore the Audit demo Dashboard demo (Chinese) How to enable it

The online demo shows actual audit records from synthetic Router calls. Shared records are visible to other visitors; do not enter real keys or customer information. Production enterprise service is provisioned separately.

INTERACTIVE SCHEMATICInteractive illustration · Not live data

Authorized collection

Encrypted storage

Access log

01Authorized calls enter side-channel collection

02Encrypted per tenant; basic rule checks run

03Waiting for authorized content access

Demonstrates only the sequence “write the access log, then return the content.” No real content is read.

Domainaudit.24test.com (synthetic-data demo)

StatusSaaS live Local edition undergoing prototype validation

ForEnterprise security leads · IT administrators · Authorized auditors

Collection source/v1 and /v1beta routes on the TBuy gateway (modelsok)

How collection works

Side-channel mirroring. Forwarding stays independent.

The gateway fetches a collection-policy snapshot every 60 seconds, determining collection by master account, workspace, or token. Policies can capture call metadata only or include content. Collection failures never affect forwarding or billing; if the audit service is unreachable, the gateway records a collection gap.

Four protocols, normalized

OpenAI Chat, OpenAI Responses, Claude Messages, and Gemini: streaming and non-streaming calls are normalized into one content structure, including four reasoning-trace formats and tool calls.

Encryption per tenant

Each tenant has a data key (AES-256-GCM), with authenticated additional data binding the tenant and record. The master key stays outside the database and backups. Content is stored in a local directory or S3-compatible object storage.

Visible collection gaps

Uncollected, dropped, and truncated items are counted by reason and visible in both the site-owner console and the enterprise “Collection status” page. Enterprises can see whether collection is active, the capture level, and when it began.

How review works

Clear ownership for risk signals. Authorized, logged access to content.

Basic rule checks

Keys and tokens: identified by value patterns
Personal data: IDs and numbers with check digits
Tenant-defined keywords
Upstream refusal signals

Alerts only; no interception. Findings for the same member and matched value are grouped, counted together, and updated as a group.

Enterprise console

Overview, call list, and call details (prompts, responses, reasoning traces, and tool calls)
Risk-finding management, collection status, and access logs
Settings: keywords, accounts, alert webhooks, password changes, and TOTP

Available in Chinese and English.

Roles and access records

Four roles: site owner, tenant administrator, auditor, and read-only
Database row-level security; cross-tenant access always returns 404
Access logs are written before content is returned; if logging fails, content is withheld

Enterprise access logs also show content views performed by the platform operator.

Alerts

Feishu alerts for the site owner and tenant webhooks with HMAC signatures. Messages contain no call content. Every collection-policy change is logged and triggers a notification.

Retention and archiving

Default retention is 180 days, adjustable per tenant; raw items are retained for 7 days. After configuring the site owner’s archive public key (with the private key kept offline), content older than 14 days (default, adjustable) is packaged daily for cold archiving and encrypted with that public key.

Sign-in

Password sign-in. Site-owner accounts must enable TOTP; tenant users can enable it in settings. Passkey sign-in (WebAuthn) has been merged into the main branch, bound to the site domain and enabled only on HTTPS domain deployments. It will become available in the online console after release (planned).

How to enable it

Currently for TBuy enterprise accounts with collection enabled

1. Submit a request: Contact us with the master accounts, workspaces, or tokens to capture and the desired level (call metadata only or including content). Once the “Enable call auditing” entry on the TBuy enterprise account page is live, requests can also be submitted there.
2. Site-owner confirmation: The site owner must individually approve enterprises outside the allowlist before collection starts; this is a hard product requirement. Approval is followed by tenant creation, bindings, collection rules, and enterprise account issuance.
3. Start collection: The gateway fetches the new snapshot and starts collection within 60 seconds. Enterprises can open the Audit demo and verify the scope and start time on the “Collection status” page.
4. Day-to-day use: Review calls and risk findings according to role, and configure keywords and alert webhooks. Every content view creates an access record.

The “Enable call auditing” entry on the TBuy enterprise account page, self-service request form, and approval queue are all planned. Until then, provisioning is handled manually.

Scope and editions

What is covered, and what is not yet covered

Collection covers only the gateway’s /v1 and /v1beta routesContent from playground, separate routes such as MJ/Suno, Realtime, and asynchronous tasks is outside the collection scope and marked as not covered in the console.

Known limitation

Side-channel auditing does not block requests before they are sentRisk findings support internal review and investigation; they do not intercept requests before dispatch.

By design

Collected reasoning traces are the reasoning content returned to the client by the upstream serviceSome providers return only summaries or encrypted signatures. These are labeled accurately, without injecting parameters that force summaries.

By design

The master key is held in server configurationAnyone with audit-server login access can technically decrypt content. Access is currently restricted to the site owner; a hardware-key solution is planned.

Known limitation

Local deployment (Enterprise edition)Code for manual unlocking, offline-signed releases, and controlled backup restoration has been merged into the main branch and validated on a synthetic prototype. Formal release and physical-device acceptance are in progress.

Prototype validation

One instance serves one gateway deploymentAuditing a mainland-China gateway requires a separate instance and domain.

Planned

How the products connect

Before and after auditing

From access to auditing

SaaS path: the enterprise uses the TBuy gateway directly, with collection middleware providing side-channel mirroring. Local path: Token Router Enterprise installs the gateway and local auditing on the same machine.

Return to checking

If risk findings or call details reveal unusual model responses, you can run another check of that model with 24Test Model Check. The return link carries only the protocol type, model name, and the enterprise’s own gateway endpoint—not Keys, channel identities, or content. (Planned.)

What we exclude

The audit console contains no procurement or top-up entry points. Upstream channel identities do not appear in any enterprise-visible API.