Authentication, MFA, and sessions
Role-aware access, protected account functions, MFA support, and inactivity-based session controls guard the application boundary.
Security at Threat Foundry
Controls designed for sensitive threat operations workflows.
Security is treated as an operating boundary: identity, tenant ownership, source policy, secrets, AI eligibility, provider contact, generated artifacts, customer publication, readiness, and audit history all matter.
Workflow-specific RBAC
Read, create, review, approval, execution, export, publication, configuration, and tenant-scope operations require their exact permissions.
Tenant-owned work and publications
Operational records, background work, lookups, uniqueness rules, service artifacts, and customer-safe publications preserve tenant scope.
Purpose-bound credential references
Workflows use protected configuration and opaque references. Passwords, tokens, keys, and service-account values do not belong in prompts, packages, or displayed workflow state.
Distribution and currentness gates
Markings, restrictions, revocation, expiry, content versions, selected entities, and tenant data policy are rechecked before downstream use.
Optional, bounded, and review-first
Allowed model routes, data eligibility, tenant policy, budgets, warnings, and stop thresholds constrain calls. AI output cannot approve or deploy itself.
Current state before confirmation
High-impact actions show the tenant, content version, connector, telemetry, fields, limits, provider-contact state, change boundary, warning, and exact action. If the underlying state changes, approval must be reviewed again.
Explicit read-only contact
Supported search, validation, verification, inventory, and refresh actions require current readiness and explicit review. Provider content mutation and endpoint response stay outside the workflow.
Durable decisions and handoffs
Sources, versions, tests, evidence references, tuning decisions, approvals, packages, cases, overrides, and publications remain attributable and linked.
Liveness, readiness, and safe failure
Separate probes distinguish a running process from a service ready for database-backed work; missing prerequisites and unsupported actions remain blocked rather than simulated.
Responsible reporting
If you believe you found a security issue, do not include sensitive customer data in the initial message. Contact [email protected] with a concise description and a secure way to coordinate.
Start with the workflow
Need a deeper security walkthrough?
Request a security architecture conversation and we will review the deployment model, service boundaries, provider-contact controls, and data handling relevant to your environment.