Draft for review — October 13, 2026. Prepared for the Argent Reach security review group: Brad Gustafson (Consulting), Ethan Harris (MSSP), Sarah Goranson (vCISO / Advisory), David Godwin (Cybersecurity Architect), and JD Harris (CEO). This draft describes the security design for the Argent Reach Networking Hub as agreed in the October 13 working session. Items that depend on vendor confirmation are marked TO CONFIRM and are not presented as completed controls.

How to read this document.

• Answered: the control is part of the Hub design as built for the pilot.

• Planned: the control is agreed and scheduled, but not yet in place.

• To Confirm: the detail depends on a vendor or policy confirmation that is still outstanding.

1. Purpose and scope

The Argent Reach Networking Hub is a shared workspace for running enterprise sales pursuits as a team. It holds the coordination layer that a customer relationship management system (CRM) does not: the account plan, the pursuit artifacts, the named owners and deliverables, and the questions routed to subject-matter experts.

The Hub complements the CRM. It does not replace it. Each firm's CRM remains its system of record for accounts and pipeline stages, and only the pursuit data agreed by both firms enters the Hub. No partner data enters the Hub until this security review is complete.

This document covers the pilot configuration: one Argent Reach workspace in the Business Hub OS CRM, an Enterprise Pursuits pipeline, and private workspaces for the first partner cohort. It covers who can sign in, what each person can see, what data the Hub holds, how that data is stored and removed, what is logged, how the AI agents are bounded, and how outbound communication is controlled.

2. Identity and access model

Every person who uses the Hub signs in with a named, individual login. Shared logins are not permitted. Access follows the principle of least privilege: each person receives the smallest role that allows them to do their part of a pursuit, and access is removed when a person leaves a pursuit or a partner firm.

Multi-factor authentication is required wherever the platform supports it for the account type in use. The exact enforcement method for each login type is TO CONFIRM with the platform vendor before the pilot expands beyond the first cohort.

Each partner firm also holds a private workspace inside the Hub. A private workspace is visible only to that firm's own named users. Joining a shared pursuit grants access to that pursuit only; it never grants access to another firm's private workspace.

3. Visibility and data boundaries

Visibility in the Hub is set per pursuit and per firm. The lead partner on an account sees that account's pursuit workspace. A partner who is not on the pursuit does not see it, and a firm never sees another firm's unrelated accounts, contacts, or private notes.

• Shared by design: the account plan, the pursuit stage, named roles and deliverables, and the artifacts both firms agree to attach to the pursuit.

• Private by default: each firm's internal notes, its own agent workspace, and any account it has not agreed to share.

• Denied access: a user who requests or follows a link to a pursuit outside their permissions receives a denial, not the data. Denied-access events are recorded in the audit trail described in Section 6, so a boundary can be shown to have held rather than simply asserted.

Changes to who can see a pursuit require an Admin on the owning side and are logged with the name of the person who made the change and the time it was made.

4. Data inventory: what the Hub holds

The Hub holds pursuit data only. It is not a copy of either firm's CRM, and it must not be used to store passwords, credentials, or regulated data that the pursuit does not require.

If a pursuit needs a document that contains sensitive client information, the document is attached only with the owning firm's agreement, and that agreement is recorded on the pursuit. Where a summary will do the same work, the summary is stored instead of the full document.

5. Storage, backup, and deletion

Hub data is stored in the Business Hub OS CRM, which is hosted by the platform vendor. The Hub team does not store partner pursuit data on personal devices or in personal accounts as part of normal work.

The following are design requirements for the pilot. Each one is marked with its current status so reviewers can see what is confirmed and what is still outstanding:

• Encryption in transit and at rest: required. Vendor attestation of the encryption standard in use is TO CONFIRM.

• Backups: regular vendor backups are required so a pursuit workspace can be restored after accidental deletion or corruption. Backup frequency and restore testing are TO CONFIRM with the vendor.

• Export on exit: when a partner leaves or the pilot ends, that partner receives an export of its own pursuit data in a commonly readable format. The export format and delivery method are TO CONFIRM.

• Deletion on request: after an agreed export, the departing partner's private workspace and its copies of shared artifacts are deleted on request. The deletion timeline is TO CONFIRM; no retention period is stated in this draft because none has yet been confirmed by the vendor or agreed by both firms.

• Retention during the pilot: pursuit data is kept only while the pursuit is active or under review. A formal retention schedule is PLANNED and will be agreed with the review group before the model expands beyond the first cohort.

Nothing in this section should be read as a certification claim. No compliance certification is claimed for the Hub in this draft.

6. Audit trail

The Hub records who did what, and when. The audit trail exists so either firm can answer, for any pursuit, who viewed the record, who changed it, who sent a communication from it, and who changed its permissions.

The completeness of view-level logging depends on platform capability and is TO CONFIRM. Where the platform cannot log an event directly, the gap will be stated in the final version of this document rather than filled with an assumption. Audit records for a pursuit are available to the firms on that pursuit on request.

7. AI boundaries

Each partner firm has its own dedicated AI agent inside its private workspace. The agent helps that firm draft follow-ups, summarize calls, track deliverables, and answer questions from its own pursuit materials.

• What an agent can see: only its own firm's private workspace and the shared pursuits that firm is part of. An agent has no access to another firm's private workspace.

• No cross-partner training: one firm's materials are not used to train, tune, or improve another firm's agent. Each agent works from its own firm's workspace only.

• Human approval before sending: an agent drafts; a person sends. No agent message, email, or follow-up leaves the Hub without a named person reviewing and approving it first.

• What agents retain: agents work from the workspace they are given. Whether conversation content is retained by the underlying model provider, and for how long, is TO CONFIRM with the provider, and the answer will be added to the final version of this document before agents handle live pursuit data beyond the pilot cohort.

8. Communications compliance

Outbound communication from the Hub follows the same discipline as the pursuit itself: named sender, agreed audience, and a record of what was sent.

• Consent: contacts are emailed or texted only where a lawful basis or consent for that contact is held by the sending firm. The Hub does not create consent; it records the basis the sending firm relies on.

• Opt-outs: an opt-out is honored across the pursuit. Once a contact opts out, neither firm contacts that person again from the Hub about that pursuit, and the opt-out is recorded on the pursuit record.

• Sender verification: messages are sent only from verified sending identities belonging to the sending firm. The verification method for each sending domain or number in the pilot is TO CONFIRM before the first campaign or event follow-up is sent.

• No unapproved sending: event and trade-show follow-up, referral introductions, and any bulk message require human approval of the final text and the recipient list before anything is sent.

9. Incident reporting and review

Any user who suspects unauthorized access, a misdirected message, or data shared with the wrong firm reports it the same day to an Admin on their own side and to the Pursuit Lead. Speed matters more than a complete first report; a short early report is better than a detailed late one.

On a report, the Admins on both sides will preserve the relevant audit records, confirm who currently has access, remove any access that should not be there, and agree what the affected contact or firm needs to be told. The incident, the action taken, and the outcome are recorded on the pursuit and in the review log.

The review group named at the front of this document reviews Hub access and this document on a regular cadence during the pilot. The cadence for the pilot is PLANNED to be set at the first review meeting; access for every named user is re-confirmed at each review, and users who no longer need access are removed at that point rather than left active.

Appendix A. The six review questions

These are the six questions raised for the October 13 working session, with the status of each answer in this draft.

* Question 3: the design is answered in Section 5. Backup frequency, export format, deletion timeline, and the encryption attestation remain TO CONFIRM with the vendor.

** Question 5: the boundary design is answered in Section 7. Model-provider retention remains TO CONFIRM.

Appendix B. Items to confirm before go-live

The following items must close before partner data beyond the pilot cohort enters the Hub. Each item names what is needed; none of them is assumed in the body of this document.

• Vendor encryption attestation: the standard in use for data in transit and at rest.

• Backup and restore: frequency, retention of backups, and evidence of a tested restore.

• Audit capability: which of the events in Section 6 the platform logs natively, and which it cannot.

• Export and deletion: export format, delivery method, and the deletion timeline after a partner exit.

• Authentication: how multi-factor authentication is enforced for each login type.

• AI provider retention: whether agent conversation content is retained by the model provider, and for how long.

• Sender verification: the verification method for each sending domain and number used in the pilot.

• Review cadence: the date of the first access review and the standing interval after it.

Argent Reach | Security Documentation — Draft for Review | Confidential — for the named review group