BULLSAI Labs Information Security Policy

Version 1.0, effective October 1, 2026. This posted version is the controlling version.

1. Document control

Version 1.0 of this policy takes effect on October 1, 2026 and governs all BULLSAI Labs work from that date. The version posted at bullsailabs.com is the controlling version.

Prior versions are retained for at least seven years and are available to clients on request. A later version applies to an active engagement only if it maintains or strengthens the protections in place for that client. Any change that reduces protection requires the client's written consent.

2. Purpose, scope, and framework alignment

This policy sets the minimum controls for how BULLSAI Labs receives, stores, processes, transmits, and destroys client data, including its use of AI models. Where a client agreement imposes stricter terms, those terms govern for that client.

Scope. The policy applies to:

• All principals, employees, and contractors who perform BULLSAI work ("personnel")

• All devices, accounts, software, and third-party services used for BULLSAI work

• All data that clients provide to BULLSAI, and all material BULLSAI derives from it

Framework alignment. BULLSAI maps its controls to the following publications. BULLSAI does not claim certification or attestation under any of them. BULLSAI completes client security questionnaires and supports reasonable client audit requests (Section 11).

Definitions. Client data means any information a client provides to BULLSAI, in any form, and any records derived from it. Restricted zone means the encrypted workstation and vaults where client data is processed. Development zone means the code repositories, documentation, and synthetic data used to build software, which contain no client data.

3. Roles and personnel obligations

Only named principals may access client data. Contractors build and test software without access to client data, client systems, or encryption keys.

Before receiving any access, each person:

1. Signs a confidentiality and intellectual property assignment agreement that survives termination

2. Completes a background check, or a stricter check where a client requires one

3. Acknowledges this policy in writing and completes a security briefing

4. Acknowledges BULLSAI's restriction on trading, or tipping others to trade, the securities of any client

Acknowledgments are renewed each year and whenever this policy changes materially. Contractors may not subcontract any part of their work. BULLSAI names its personnel to a client on request and gives notice before adding anyone to that client's engagement.

At departure, company accounts are disabled the same business day. Repository access is removed, shared secrets are rotated, and the departing person signs a statement that they retain no company or client material.

4. Data classification and handling

BULLSAI classifies all information into four classes, and the class decides where it may be stored, which models may process it, and how it moves. When a file mixes classes, the strictest class applies to the whole file.

Clients are asked to pseudonymize extracts at source, so that BULLSAI never receives names, government identifiers, birth dates, or contact details it does not need. Pseudonymized data remains Restricted. Synthetic data is created by a principal from schema and summary statistics and contains no real records.

Labeling. Notes, transcripts, reports, and other Confidential records relating to a client are labeled with that client, so they can be located and handled under the client agreement at engagement close.

Processing in the restricted zone and release of results

Code that processes Restricted data, including AI-generated code reviewed under Section 5, runs on a restricted-zone device or virtual machine with no network access during processing. Code enters the restricted zone through a principal, and results leave it only as described below.

Results leave the restricted zone only after an automated check and a principal's review. The check blocks:

• Any value that appears in the client's text fields, such as names, addresses, or account identifiers

• Any string matching common identifier patterns, such as account numbers, phone numbers, or email addresses

• Any statistic describing fewer than 10 records, or a stricter threshold set by the client

Minimum and maximum values are reported only where they do not describe a single identifiable record. Results that pass both the check and the review are classified Confidential.

5. Use of frontier models

BULLSAI uses frontier models from commercial AI providers to write and review software, draft documentation, and work with Internal and approved Confidential information. Restricted data does not enter a frontier model unless the client has authorized a named provider and terms in writing.

Frontier model means a proprietary large language model that is accessed through its developer's service, such as an API, a coding agent, or a business chat workspace.

Provider approval

The Security Owner approves each frontier provider before use and records it in BULLSAI's AI model register. The register lists each provider, the account plan, the data classes it may receive, and its retention terms. It is available to clients on request. A provider is approved only if all of the following hold:

1. Service is under commercial or enterprise terms, not consumer terms

2. Those terms prohibit training on BULLSAI inputs and outputs

3. A data processing addendum is in place

4. Data retention is defined in writing, and zero data retention is used where a client requires it and the provider offers it

5. Data is encrypted in transit and at rest

6. The provider holds a current independent security attestation or certification

7. Accounts are company-managed, issued per person, and protected by multi-factor authentication

Individual plans. The Security Owner may approve an individual AI subscription plan, issued to one named person and protected by multi-factor authentication, that does not meet every criterion above. An individual plan may receive Internal and Public data only, must have model training on user content turned off in its account settings, and is recorded in the AI model register as an individual plan.

Rules of use

1. Approved accounts only. All accounts must be approved by the Security Owner.

2. Data class limits. Content entering a prompt, file upload, or agent context must be permitted for frontier models under Section 4.

3. Coding agents. AI coding agents run only in the development zone. They are configured to deny access to vault mounts, data directories, and credential files. They do not run on a device while a client vault is unlocked on it, unless the agent is isolated from the vault.

4. No credentials. AI agents hold no credentials to client systems, the restricted zone, or production environments.

5. Connectors. A connector that gives an AI tool access to BULLSAI email, files, or other accounts is enabled only on company-managed accounts, and never to a store that holds unencrypted Restricted data.

6. Human review. A principal reviews all AI-generated code before it runs against client data, and all AI-assisted content before it is delivered. BULLSAI is accountable for every deliverable.

7. Client alignment. Where a client has an AI policy or approved vendor list, BULLSAI uses only the providers it permits for that engagement. For public-sector clients, this includes any applicable state restriction on AI tools.

8. Third-party code. Open-source components suggested by AI tools are checked for license and known vulnerabilities before use. Software dependencies are pinned to exact versions with verified hashes and are updated deliberately, not automatically.

Automated workflows and untrusted content

BULLSAI automation that uses AI models, including scheduled jobs that read company email, notes, or client documents, follows these rules:

• Structured output only. Models that read client documents, inbound email, or other untrusted content return structured output and hold no tools that send, delete, or modify data.

• Validated actions. Deterministic code validates that output and may take only actions on a fixed, documented list.

• Approval for client messages. Messages to clients are sent only after a principal approves them.

• Least-privilege service accounts. Automated jobs run under dedicated service accounts with the minimum permissions they require.

• Enforcement and logging. A policy check in code enforces the data class limits in Section 4 before any content leaves the device, and every model call is logged with its provider, model, data class, and time.

• Notifications. Push notifications and alerts never contain Restricted data.

Prohibited uses

• Uploading client files to a frontier model outside the limits in Section 4

• Using any model to re-identify individuals in pseudonymized data

• Using AI tools to bypass, disable, or test security controls without written authorization

• Connecting an AI tool to a client system without the client's written authorization

Any suspected entry of prohibited material into a frontier model is handled as a security incident under Section 10.

6. Use of hosted and locally run models

BULLSAI runs open-weight models in two ways: through an approved third-party hosting provider, or on BULLSAI-owned hardware. Restricted data is processed by a model only on BULLSAI-owned hardware in the restricted zone, unless the client authorizes otherwise in writing.

Open-weight model means a model whose weights are published for others to run. Third-party hosted means the model runs on an inference or cloud provider's infrastructure under a BULLSAI account. Local means the model runs on hardware BULLSAI owns and controls.

Third-party hosted models

1. The hosting provider must meet every approval criterion in Section 5 and is recorded in the AI model register.

2. Processing occurs in the United States, or in the region a client requires.

3. BULLSAI uses the hosting provider's service, not a service run by the model's developer, unless that developer is itself approved under Section 5.

4. Data class limits in Section 4 apply exactly as they do to frontier models.

Local models

1. When a local model processes Restricted data, it runs on a restricted-zone device. Outbound network access is blocked for the duration of processing.

2. Model serving endpoints listen only on the local device or an isolated network segment, require authentication, and are never exposed to the internet.

3. Telemetry and automatic update checks are disabled in inference software used with Restricted data.

4. Prompts, outputs, logs, and caches produced from Restricted data are written only inside the client's vault, so that they are covered by destruction under Section 9.

Model provenance and integrity

1. Weights are obtained only from the developer's official release or a verified repository, and file checksums are verified before first use.

2. Formats that cannot execute code on load, such as safetensors, are preferred. Executable formats from unverified sources are not loaded.

3. The register records each model's name, version, source, the developer's country of origin, and checksum.

4. Where a client or applicable law restricts models by the developer's country of origin, BULLSAI applies that restriction to every deployment type, including local models.

5. BULLSAI does not send data to any model service operated by a developer located in a country designated as a foreign adversary under 15 C.F.R. § 7.4.

Training and fine-tuning

BULLSAI does not train or fine-tune any model on client data unless the client agreement permits it. Weights, adapters, embeddings, or indexes built from client data are Restricted. They are stored in the client's vault and destroyed with it.

Models deployed in client environments

Where BULLSAI deploys a model in a client environment, client data stays in that environment. Status reports leaving it are limited to a fixed schema that BULLSAI provides to the client in advance: run times, record counts, score distributions, drift statistics, and error counts, with no record-level data. Reports are sent outbound only, through a channel the client approves, and each carries a unique identifier. A missing report is treated as an alert.

Before a model or prompt change reaches a client's production system, it is tested against a fixed evaluation set with pass thresholds set in advance, and the results are retained.

7. File transmission through Box

BULLSAI uses Box as its file transfer channel. Restricted files are encrypted under BULLSAI or client keys before upload wherever the client can support it.

Box encrypts content in transit with TLS 1.2 and at rest with AES-256 (Box). Box also copies each upload to a backup facility and holds deleted items for a period before final purge (Box). Because BULLSAI cannot destroy those provider-held copies directly, it encrypts Restricted files before upload, so any residual copy is unreadable without BULLSAI's keys.

Account controls

1. BULLSAI uses a company-managed Box business account administered by the Security Owner. Personal Box accounts are not used.

2. Every BULLSAI user has a unique account with multi-factor authentication.

3. Each client engagement has its own folder. Collaborators are limited to named client contacts and BULLSAI principals. Contractors are not invited to client folders.

4. Box AI features and third-party app integrations are not used on client folders unless the client approves in writing.

5. Box desktop sync tools are not used for Restricted data, and client vaults are never placed in a Box-synced directory.

Inbound files from clients

1. The client uploads to its engagement folder or an upload-only request link.

2. BULLSAI asks the client to encrypt Restricted files before upload, using a Cryptomator vault or an AES-256 encrypted archive, with the password sent by a separate channel.

3. A principal moves the file into the client's vault and confirms it is complete, by checksum or record count.

4. Where a client uploads an unencrypted file, BULLSAI follows the same steps.

Outbound deliverables

1. Deliverables containing Restricted data are encrypted before upload. The password or key is sent by a separate channel, such as a phone call, and never in the message that carries the link.

2. Confidential deliverables are shared only with named collaborators, or by a password-protected link.

3. Public "anyone with the link" sharing is not used for any material that is not Public.

4. Shared links are removed when the transfer is confirmed.

Email and consumer file-sharing services are not used to transmit Restricted data. Where a client requires its own transfer channel, such as SFTP or a client-managed share, BULLSAI uses it instead of Box.

8. Encryption of client data with Cryptomator

Each client engagement has its own Cryptomator vault, created for that engagement and used for nothing else. Vaults sit on workstations with full-disk encryption, so client data has two independent layers of encryption at rest.

How a vault protects data. Each vault has its own randomly generated 256-bit encryption and authentication keys. File contents are encrypted with AES-GCM under per-file keys, and file and folder names with AES-SIV. The vault keys are wrapped with a key derived from the vault password by scrypt, and stored in the vault's masterkey file (Cryptomator security architecture). Without the password or the recovery key, the vault contents cannot be read.

Vault rules

1. One vault per client. A vault never holds data from more than one client. This lets BULLSAI destroy one client's data without affecting any other.

2. Passwords. Each vault password is randomly generated by the business password manager, is unique to that vault, and is at least 20 characters. Passwords never appear in code, repositories, chat, email, or AI prompts.

3. Recovery keys. A recovery key is generated when the vault is created. It is stored in the business password manager, with at most one offline copy kept in a locked location.

4. Access. Only principals hold vault passwords and recovery keys.

5. Locking. Vaults lock automatically after a period of inactivity and are locked at the end of each work session. An unlocked vault is readable by software running on the device, which is why Section 5 keeps AI agents away from unlocked vaults.

6. Working files stay inside. Intermediate tables, notebook outputs, logs, caches, and model files derived from client data are written inside the vault.

7. No cloud sync. Vaults holding client data are not synced to Box or any other cloud service.

8. No backups of client data by default. The client remains the system of record. Where a client agreement requires a backup, it is an encrypted copy of the vault, recorded in the key and copy register, and destroyed with the vault.

9. Rekeying. Changing a vault password does not change the vault's underlying keys. When a person who held a vault password leaves, or a compromise is suspected, BULLSAI creates a new vault with new keys, moves the data, and destroys the old vault under Section 9.

10. Software. Cryptomator is obtained only from its official source and kept on a supported version.

BULLSAI keeps a key and copy register for every vault. It records the client, vault name, every location of the vault and its key files, who holds the password, where the recovery key is stored, and any backup copy. The register holds no key material. It is the checklist used for destruction.

9. Key destruction and cryptographic erase

BULLSAI destroys client data by cryptographic erase: it destroys every key that can decrypt the client's vault, which leaves the encrypted data permanently unreadable. Destruction occurs within 30 days of engagement close, or sooner on the client's written request, and is confirmed by a signed certificate.

NIST SP 800-88 Rev. 2 recognizes cryptographic erase as a purge method (NIST). The technique is also called crypto-shredding. BULLSAI relies on it because deleting or overwriting files on solid-state drives cannot be reliably verified, while destroying a small, inventoried set of keys can be.

What is destroyed

Procedure

1. Confirm with the client that final deliverables are accepted and that no further work requires the data.

2. Review the key and copy register. Search the workstation, repositories, and Box for any copy or derivative of client data outside the vault, and move or destroy any found.

3. Lock the vault. Delete the vault password and recovery key from the password manager, including history and trash, and shred any offline copy.

4. Delete the masterkey file, its backup copies, and the vault configuration file, then delete the vault folder and any recorded backup copy.

5. Permanently delete the client's Box folder contents, including Trash, and remove all shared links.

6. A second principal verifies each step against the register.

7. BULLSAI issues a signed certificate of destruction within five business days.

The certificate states the data destroyed, each location, the method (cryptographic erase consistent with NIST SP 800-88 Rev. 2), the date, the person who performed it, the person who verified it, and any material retained under the client agreement, such as aggregate deliverables or source code containing no client data. Certificates and register entries are kept for seven years. Neither contains key material.

Limits of cryptographic erase, and how they are covered

Device retirement

Storage media from any device that held Restricted data are purged before reuse or disposal, by cryptographic erase of the full-disk encryption key together with the drive's built-in sanitize command, or are physically destroyed. Where disposal is outsourced, the vendor provides its own certificate of destruction.

10. Supporting controls and incident response

The controls below support Sections 5 through 9 and apply to every engagement. BULLSAI notifies an affected client within 24 hours of suspecting an incident involving its data.

Incident response

An incident is any actual or suspected loss, theft, unauthorized access to, or unauthorized disclosure of client data, credentials, or systems used for client work. Examples include a lost device, a compromised account, malware on a work device, prohibited material entered into an AI tool, or client data found outside its vault.

1. Contain. Lock vaults, isolate the device, disable affected accounts, and rotate credentials. Preserve logs and evidence.

2. Notify. Notify the client's named security contact within 24 hours of suspicion, by phone and email, without waiting for confirmation. A shorter window in a client agreement governs.

3. Investigate and recover. Determine what data was involved and how, engage outside forensic support where needed, and confirm controls before resuming work.

4. Report. Provide updates at least every 24 hours and a written report within 10 business days covering timeline, data involved, root cause, and corrective actions.

BULLSAI cooperates with each client's own investigation and with the client's legal disclosure obligations, including securities and state breach notification requirements. The incident plan is tested once a year with a walkthrough exercise.

11. Client assurance, exceptions, and contact

BULLSAI supports client security review and will demonstrate any control in this policy on request. Questions and incident reports go to the security contact below.

Client assurance. BULLSAI completes client security questionnaires and vendor risk forms, including those used by public companies and state agencies. On request, it provides evidence of controls, such as a screen-share walkthrough, configuration records, the AI model register, and the vendor list. BULLSAI signs data processing agreements and supports reasonable audits on advance notice.

Exceptions. An exception requires written approval by the Security Owner, a recorded reason and compensating control, and an end date no more than 12 months out. An exception that affects a client's data also requires that client's written consent.

Enforcement. A violation of this policy may result in removal of access and termination of the person's engagement with BULLSAI. Violations involving client data are handled as incidents under Section 10.

Changes. Each revision is recorded in the version history in Section 1. Clients with active engagements are notified of material changes.

Contact. Security inquiries and incident reports: security@bullsailabs.com or 404.667.6920.

References

• NIST, SP 800-88 Rev. 2, Guidelines for Media Sanitization, September 2025

• NIST, Cybersecurity Framework 2.0

• Cryptomator, Security Architecture

• Box, Data Encryption at Box

• Box, Manage Trash