Overview#
A partner is building an intelligence-sharing integration and needs to test their code against live Argus endpoints without touching production data or burning partner provider quota. Developer Sandbox Access Tokens provide short-lived, scoped, short-lived JWTs that route requests to deterministic mock connectors instead of real OSINT and finance providers. A platform admin mints a token for an application in seconds, the developer swaps their production bearer token for the sandbox token and points at the sandbox base URL, and the same integration code works against synthetic, repeatable data without any API changes.
Sandbox tokens carry the issuing administrator's tenant and organisation context, so Rule 14 tenant isolation enforces the same data boundaries in test as in production. Sandbox tokens cannot mint further sandbox tokens, preventing privilege escalation. Audit trails tag all sandbox traffic with secrecy_level=sandbox so compliance reporting excludes test calls from production metrics.
Key Features#
- Short-Lived Token Issuance: Mint short-lived JWTs with a configurable lifetime (1 minute to 24 hours, default 1 hour) through a platform admin endpoint, with automatic lifetime clamping
- Scenario Pinning: Pin one or more scenario IDs (e.g.
wallet.high-risk,entity.sanctioned) to receive deterministic mock data on every request for reproducible integration testing - Tenant Isolation: Sandbox tokens carry the issuer's organisation ID and tenant ID in the JWT, enforcing the same tenant scoping rules as live tokens
- Scope-Limited Bearer: Embedded scope set (
argus:profiles:read,argus:profiles:write,argus:jobs:read,argus:jobs:write) withsandbox: trueclaim so mock connectors and routing middleware can enforce dual-gate rules - Privilege Escalation Prevention: Sandbox tokens cannot mint further sandbox tokens; only live tokens with platform admin authority can request new sandbox tokens
- Audit Logging: Every
sandbox.token.issueevent records the actor ID, application ID, tenant, scenario selection, and TTL in the audit trail withsecrecy_level=sandboxtagging - JWT Validation Reuse: Sandbox tokens are signed with the same key set and published through the same JWKS endpoint as live tokens, so existing SDK integrations validate sandbox tokens without any code changes
- No Production Impact: Sandbox calls never touch real OSINT providers, never hit partner rate-limit budgets, and never increment live connector quota usage
Use Cases#
Partner Integration Testing#
Build and validate REST API integrations using deterministic mock responses that replay identically on every request. Developers run CI pipelines that snapshot sandbox responses and assert against them without retry flakiness.
Sandbox Scenario Rehearsal#
Prepare for high-risk scenarios (e.g. entity.sanctioned) before moving to production by pinning a specific scenario to a token and testing your handling of those canned responses in isolation.
Demo and Proof-of-Concept Rehearsal#
Record live demos and onboarding videos using sandbox data without exposing actual investigation data or consuming partner quota, then replay the same scenarios for every take.
Integration Validation Before Production Release#
Validate end-to-end integration against the full v2026.4 API surface using mock data before deploying production tokens, ensuring wire format, headers, and trace propagation are correct.
Integration#
A developer with platform admin authority calls the sandbox-token issuance endpoint with an optional request body specifying scenarios and a token lifetime (clamped between 1 minute and 24 hours). The response includes the signed sandbox JWT, its expiry timestamp, the embedded scope set, the sandbox base URL, and the pinned scenarios.
The partner integration swaps the production bearer token for this sandbox token and points the API client base URL at the sandbox base URL instead of the live endpoint. All wire formats, status codes, headers, and trace IDs remain identical between sandbox and live, so no behavioural integration code changes are required. When ready for production, the admin re-mints a live token through the standard OAuth2 flow, swaps back the base URL, and deploys without touching integration code.
Sandbox tokens are validated like any other JWT: the routing middleware checks the aud claim and rejects requests with aud != "sandbox" on the sandbox host with 403 Forbidden. Live connectors check request.state.sandbox and refuse requests tagged as sandbox-scoped, ensuring a sandbox token cannot accidentally reach a live provider.
Open Standards#
- OAuth 2.0 (RFC 6749): The authorisation framework governing how platform administrators authenticate and obtain the authority required to mint sandbox tokens through the token-issuance endpoint.
- JSON Web Token (JWT, RFC 7519): The on-wire format for sandbox access tokens, carrying all claims, tenant, organisation, scope set, sandbox flag, and expiry, in a signed, self-describing compact serialisation.
- JSON Web Signature (JWS, RFC 7515): The signing layer applied to every sandbox token, guaranteeing that claims cannot be altered after issuance and that the routing middleware can verify integrity without a round-trip to the auth service.
- JSON Web Key Set (JWKS, RFC 7517): The public key publication mechanism through which partner SDKs and routing middleware discover the verification keys; sandbox tokens are signed with the same key set as live tokens and discoverable at the same JWKS endpoint.
- RS256, RSASSA-PKCS1-v1_5 with SHA-256 (RFC 7518): The asymmetric signing algorithm applied to all issued tokens, enabling any standards-compliant JWT library to validate sandbox credentials without configuration changes.
- OAuth 2.0 Bearer Token Usage (RFC 6750): The HTTP transport convention under which sandbox tokens are presented as
Authorization: Bearerheaders, keeping the wire format identical to live tokens so integration code requires no branching. - GraphQL (June 2018 specification): The typed API surface through which platform administrators invoke sandbox-token issuance and through which integration tests drive queries against mock connectors, providing precise field selection and composable operations.
Security and Compliance#
- Tenant Scoping: Sandbox tokens inherit the issuer's organisation and tenant IDs, enforcing the same data isolation rules as live credentials
- Short Lifetime: Default 1-hour TTL with manual upper limit of 24 hours prevents indefinite use of test credentials
- Privilege Separation: Only platform admins can request sandbox tokens; sandbox tokens cannot themselves request further tokens
- Audit Trail: All issuance events are logged with actor identity, application ID, and scenario selection for compliance review
- Dual-Gate Enforcement: Routing middleware and provider clients enforce no-leak in both directions: sandbox tokens cannot read live data, and live tokens cannot access mock data
- JWT Signing: RS256 public-key signing using the platform's standard key set (mirrored to the OAuth2 JWKS endpoint) enables any SDK that validates JWTs to accept sandbox tokens without configuration changes
Availability#
- Enterprise Plan: Included
- Professional Plan: Available as add-on
Last Reviewed: 2026-05-08 Last Updated: 2026-05-08