PARTNERS

Add selected Workbench capabilities through bounded OEM and partner integrations

aisecurity.llc

Secure SDLC

Our Secure SDLC applies security review, threat modeling, testing, dependency management, and human review to the platform, Workbench Copilot, integrations, generated packets, training products, and professional-services tooling we build.

Public policy summaryEarly-stage vendor · draft

We build the same product and service surface we describe in our Trust Center. Security-sensitive changes get extra review, and the SDLC is designed to catch auth, evidence, AI, payment, and integration risks before release.

SDLC Snapshot

  • Security review for security-sensitive changes.
  • Threat modeling for auth, integrations, AI, evidence, and testing workflows.
  • Code review for production changes.
  • Dependency scanning and dependency review.
  • Secrets scanning.
  • Schema validation at system boundaries.
  • Testing where practical, including security-focused regression coverage.
  • Release checks before deployment.
  • Human review of AI-assisted code and content.
  • Vulnerability intake, triage, and remediation.
  • Documentation updates for trust, legal, and security-impacting changes.

Security-Sensitive Change Categories

These changes receive elevated review because they can affect authorization, evidence handling, payments, or customer trust:

  • Auth and session changes.
  • Organization, workspace, role, and entitlement changes.
  • Legal, finance, IT, and security delegation changes.
  • SSO, SAML, OIDC, and SCIM changes.
  • Stripe, checkout, and seat provisioning changes.
  • Private-offer, SOW, and contract workflow changes.
  • Packet, report, and evidence rendering changes.
  • Workbench Copilot changes.
  • Model-provider, prompt, retrieval, or workspace-context changes.
  • Browser extension changes.
  • Native app changes.
  • Connector and OAuth scope changes.
  • Runtime tracing, model gateway, or trace-handling changes.
  • Code scanner, adversarial range, or RAG harness changes.
  • Database migrations and RLS or policy changes.
  • Uploaded-file and artifact-handling changes.
  • Trust-center and legal route changes.

Design Review and Threat Modeling

We review design changes for the failure modes that matter most to this product line:

  • Tenant and workspace isolation.
  • IDOR and broken authorization.
  • Role and entitlement escalation.
  • Evidence and artifact exposure.
  • Private-offer and contract packet exposure.
  • Prompt and evidence leakage.
  • Connector and OAuth scope abuse.
  • Copilot misuse or overreach.
  • Payment and seat-provisioning abuse.
  • Testing authorization and ROE boundary failures.
  • Public claim and attestation misuse.
  • Unsafe handling of target details, logs, traces, prompts, or reports.

Implementation Controls

  • TypeScript and schema validation at the boundary where data enters the system.
  • Explicit authorization checks on the server side.
  • Privileged secrets handled server-side only.
  • No service-role keys in browser code.
  • Least privilege and secure defaults.
  • Safe error handling and logging without secrets.
  • Input validation and output encoding where relevant.
  • Dependency review before adoption and release.
  • Secure handling of migrations.
  • Review of generated or AI-assisted code before merge.

AI-Assisted Development and Review

  • AI may assist with drafting, code review, analysis, refactoring, tests, and documentation.
  • AI-generated code and content require human review.
  • Security-sensitive paths require extra scrutiny.
  • Customer secrets and restricted customer evidence should not be pasted into AI coding tools unless the applicable agreement and processing path permit it.
  • AI assistance does not replace security review.

Testing and QA

  • Unit tests where useful.
  • Integration tests for API and state transitions.
  • Browser and end-to-end tests for customer journeys.
  • Auth and role tests.
  • /scope and /start funnel state tests.
  • Anonymous-to-authenticated continuation tests.
  • Stripe test mode for checkout and entitlements.
  • Packet generation tests.
  • Contract, ROE, and evidence flow tests.
  • SSO and SCIM fixtures where available.
  • Regression tests for security-sensitive routes.

Release and Change Management

  • Preview or staging review where available.
  • Feature flags if used.
  • Migration review before deployment.
  • Rollback planning for security-sensitive releases.
  • Monitoring after sensitive releases.
  • Route and metadata updates when product surfaces change.
  • Updating Trust Center docs when product behavior changes.
  • Reviewing customer-facing legal and security copy when capabilities change.

Vulnerability Management

  • Dependency updates.
  • Vulnerability disclosure intake.
  • Triage and severity assessment.
  • Remediation tracking.
  • Verification and retest.
  • Customer notice where appropriate.
  • Lessons learned flow back into the SDLC.

Special Review Gates

The following changes require elevated review before release:

  • New AI provider or model route.
  • New OAuth scope or connector.
  • New browser extension permission.
  • New native app capability.
  • New way to ingest or upload evidence.
  • New way to generate public-facing claims.
  • New payment or entitlement workflow.
  • New admin or role permission.
  • New red-team or pentest workflow.
  • New cloud or testing boundary feature.

Secure SDLC - aisecurity.llc - Last updated June 27, 2026

<- Back to Trust Center