Public API Connect v1
/api/connect/v1 is the documented tenant automation surface. Its resources, scopes, pagination, completeness metadata, and supported actions form the public contract.
API Connect / Release 4.4
Use a tenant-scoped public API for pageable local collection access and supported review-preserving workflow actions—with scopes, completeness, correlation, and action boundaries made explicit.
One public tenant API
Release 4.4 separates customer automation from browser implementation details and service-provider operations.
/api/connect/v1 is the documented tenant automation surface. Its resources, scopes, pagination, completeness metadata, and supported actions form the public contract.
HTML routes, form submissions, and browser-session endpoints support the interactive product. They are not a substitute public API and can evolve with the interface.
Control Center interfaces support authorized service operations. They are private service boundaries and are not exposed by a customer tenant API key.
Threat Foundry Control Center remains the authorized cross-tenant boundary for MSSP and managed-service operations. API Connect v1 stays inside the authenticated customer tenant; it does not provide portfolio-wide access, impersonation, or a path around customer authorization.
Purpose-bound access
Administrators create tenant-scoped API Connect keys using predefined purpose profiles. Every key requires a named owner and fixed expiry. New or blank scope state grants no authority. The raw secret is shown once; the platform retains a non-reversible verifier and bounded metadata.
Every key and every collection request is bound to one active tenant. Tenant context is activated before licensed data is read or changed.
Purpose profiles issue allowlisted exact scopes. An isolated pentest uses a one-day read-only key rather than a broader testing profile.
Named ownership and expiry are mandatory. Administrators can revoke a key, which exposes only a short non-secret prefix for identification.
The capabilities resource reports the authenticated tenant, current key scopes, expiry, available endpoint families, and operating boundaries.
Bounded collection access
Authorized collections are delivered in bounded, signed-cursor pages. Follow next_cursor while continuation remains. Offset-based collection traversal is never snapshot-complete because records can change between pages.
Offset collection traversal never claims snapshot completeness, even when the current pass has no continuation. It does not prove attacker behavior is absent. Absence-sensitive automation repeats the traversal and reconciles stable record identifiers. Responses identify continuation, known omissions, and evaluated scope so incomplete evidence cannot be mistaken for an exhaustive negative conclusion.
Connected local evidence
Scope and license determine which resource families a key can use. Detail and child collections remain separately enumerable so automation can retrieve the stored context it needs.
Saved hunts, run history, result rows, entities, notes, plans, and analytical context. Stored hunt-result JSON above 16 MiB returns 413 before loading or truncation, with guidance to retrieve complete bounded partitions.
Normalized tenant intelligence, provenance, source policy, reviewed context, integrations, and synchronization history.
Triage items and history plus case metadata, evidence, tasks, and timeline events.
Detection Studio, validation, assurance, ATT&CK, and D3FEND evidence. D3FEND scans each selected source record in full for mapped ATT&CK references; source and per-technique presentation caps remain disclosed and force completeness false when reached.
Approved-scope EASM finding lifecycle, ownership, affected assets, service context, and stored evidence.
Governed risk records, ownership, treatment state, evidence health, scoring context, and review dates.
Minimized request status and correlation metadata without returning raw credentials, provider secrets, or hidden cross-tenant context.
Authenticated tenant identity and current API capability boundaries for reliable client initialization.
Review-preserving actions
Where the key scope, tenant license, record state, and workflow policy allow it, API Connect supports bounded local actions such as appending a saved-hunt note, progressing non-terminal triage, opening and maintaining cases and tasks, updating non-terminal exposure ownership and lifecycle metadata, and creating a draft risk.
hunting:write authorizes tenant-local hunt records and notes; it does not contact a modelhunting:generate scope and an eligible tenant-selected routeA scope is necessary but not sufficient. Tenant licensing, feature settings, record ownership, current source policy, and workflow state are rechecked at the action boundary.
Correlation + operational safety
Mutating v1 actions require a unique Idempotency-Key. If X-Request-ID is also sent, both values must match. Responses return the request ID, and structured problems include a correlation ID plus safe recommendations.
API audit records retain bounded status, timing, key fingerprint, path, and execution metadata. Raw API keys, reusable credentials, full queries, and result payloads are not audit content.
GPT-assisted API pentesting runs only against an isolated AWS environment with synthetic data. Production testing is limited to read-only smoke checks; mutation, load, injection, SSRF, and destructive testing stay out of production.
Customer-selected BYOAI
hunting:write remains local. A supported AI-assisted hunting workflow requires the separate hunting:generate scope and follows the tenant’s selected BYOAI provider and model route without hidden failover.
hunting:generate does not grant query execution, provider deployment, integration synchronization, or administrative override authorityPublic API access does not grant provider deployment, destructive operations, cross-tenant service access, or a bypass around review. Any supported model contact must be visible, explicitly scoped, bounded, and attributable.
Start with the workflow
Bring the collection, local action, tenant scope, expected volume, and review requirements. We will identify the least-privilege purpose profile and completeness checks.