Security Practices

We keep the controls below in place across the platform and service surface:

• TLS for data in transit.
• Encryption at rest where supported by infrastructure providers.
• Role-based access and least privilege.
• Organization and workspace separation for customer work.
• MFA and SSO support where available for enterprise access and administration.
• Controlled handling of evidence, packets, and generated artifacts.
• No secrets through public forms.
• Vulnerability disclosure channel for responsible reporting.
• Human review for consequential AI-assisted deliverables.
• Customer data is not used to train public AI models.
• Engagement-specific SOW, DPA, ROE, and evidence terms may add stricter controls.

These practices apply, where available and as applicable, to:

• Public website, trust center, and legal pages.
• Platform and customer portal web UI.
• SecEng Copilot and LLM-powered chat.
• /scope and /start intake workflows.
• Generated packets, reports, and evidence packs.
• Private offers, contracts, and SOW workflows.
• Roles, entitlements, seats, and delegated legal, finance, IT, and security contacts.
• LMS, academy, and training seats or modules.
• Stripe checkout and subscription workflows.
• SSO, SAML, OIDC, and SCIM enterprise onboarding.
• OAuth and SaaS integrations, connectors, and customer-configured linkages.
• Browser extension and native app, if enabled.
• Runtime proxy, model gateway, or trace tooling if represented in product copy.
• Code scanner, adversarial range, RAG harness, artifact analyzer, and related security tools.
• Professional-services delivery and pentest/red-team readiness workflows.

Customer work is organized by account, organization, workspace, or engagement context. Access is intended to follow least privilege and the role assigned for the specific task.

• Admins may manage members, seats, roles, entitlements, and integrations where supported.
• Delegated legal, finance, and procurement users can receive contract or procurement tasks without automatically seeing sensitive technical evidence.
• Delegated technical and security users can receive scoping, access, evidence, and Rules of Engagement tasks.
• SSO, SAML, OIDC, and SCIM may be available or reviewed as part of enterprise onboarding.
• Access should be revoked when a user leaves, changes roles, or no longer needs access.
• We avoid assuming more than the relevant account, workspace, or engagement context unless a signed agreement says otherwise.

Security evidence is treated differently from ordinary contact data because it may describe systems, targets, vulnerabilities, prompts, logs, traces, architecture, or customer review materials.

• Evidence is minimized to what the scoped work needs.
• Approved channels are used for sensitive uploads, packet exchange, and review material.
• Restricted material is not accepted through public forms.
• Packet and report access is limited to people with a legitimate need for the engagement or platform feature.
• Redaction and masking are applied where appropriate before sharing broader copies.
• Retention and deletion follow the applicable policy and agreement path.
• Public-safe summaries may be produced, but customer-identifying publication requires approval.
• Stricter SOW, DPA, ROE, or evidence instructions control when they apply.

• Copilot assists with scoping, drafting, triage, packet generation, and security analysis where enabled.
• Copilot outputs may be saved with the relevant workspace, intake, packet, report, or project record when needed.
• Copilot does not replace human review.
• Final findings, attestations, claim language, and customer-facing evidence require human review.
• Customer data is not used to train public AI models.
• Restricted material should not be submitted to AI features unless the applicable agreement and secure processing path allow it.
• AI processing is governed by the AI Usage Policy, AI Governance, Privacy Policy, and Customer Data & Model Training pages.

• Customers should connect only systems they are authorized to use or administer.
• OAuth and connector scopes should be limited to the feature or service need.
• Connected data depends on the permissions granted by the customer and the third-party service.
• Integrations can be revoked where supported.
• Customer-configured integrations may involve third-party services controlled by the customer.
• Token and secret handling follows least privilege and approved storage practices where implemented.

• Users must only capture, process, or transmit page, file, or local context they are authorized to assess.
• Local and remote processing depend on enabled features and customer configuration.
• Diagnostic and security logs may be collected where configured for reliability or abuse prevention.
• Extension and native-app use remains subject to the Privacy Policy, Terms of Use, AI Usage Policy, Evidence Handling Policy, and Acceptable Use rules.

• Hosting, CDN, database, and storage providers support the platform and service surface.
• Backups and recovery are handled through the infrastructure and configuration we use for each system.
• Monitoring and logging support availability, security, and support workflows.
• Incident response has a defined contact path and escalation flow.
• Access reviews and offboarding are performed for production and support access.
• Dependency and vulnerability management are part of our operational baseline.
• Secrets are handled through approved storage practices and are not committed to source control.
• Security-sensitive changes receive review before production release.

aisecurity.llc is prelaunch and early-stage. We do not currently claim SOC 2, ISO 27001, HIPAA, PCI, FedRAMP, or similar certification unless a signed agreement or updated Trust Center notice says otherwise.

Until formal certifications are available, customers should rely on the Trust Center, the signed agreement path, packet-specific controls, and direct due diligence.

• Assign appropriate users, roles, and delegated contacts.
• Avoid submitting secrets through public forms.
• Identify sensitive, regulated, or third-party data before sharing it.
• Connect only integrations the customer is authorized to use or administer.
• Revoke access when it is no longer needed.
• Approve testing only through the applicable SOW, ROE, or engagement path.
• Provide accurate scope and authorization information for assessments and packets.
• Review generated packets and deliverables before external use.