Built with boundaries.

How Sageridge Group protects client information and controls the AI systems we build and operate.

Last updated: 4 August 2026 · Reviewed every six months and after material changes

Who we are and what this covers

Sageridge Group is an AI consulting and implementation firm. We help small businesses put AI to work safely.

We maintain written security and data-handling rules, use staged testing before deployment, and require every system we operate to satisfy defined controls before it connects to client data or launches.

Client data stays in client systems

• Client records, customer lists, financial documents, contracts, and regulated data remain in the client’s own systems whenever practical. We work through scoped, revocable access instead of unnecessarily copying their contents into ours.
• Our internal records contain limited engagement notes, project status, and sanitized summaries. Our data-handling standard prohibits storing Social Security numbers, bank or account details, tax returns, credentials, or raw regulated records in our internal systems.
• When we retain call transcripts for shared founder context, they are stored with restricted access, labeled by sensitivity, and never shared or reused without review. Participants may ask us not to record or to delete a transcript, subject to applicable legal, contractual, and agreed retention requirements.
• When an AI system works with a client team’s conversations, it may hold working data. Where backups are required, they are encrypted, retention-limited, and stored separately from the working system. We explain what each system stores before it is connected.
• When an engagement ends, we document what was deleted, what access was removed, and what information remains subject to an agreed retention requirement. Client-owned materials are returned or remain available in the client’s systems.

How we control AI systems

Every AI system we build or operate has a written boundary defining what it may do independently, what requires human approval, and what it must never do.

Read and draft first

AI systems summarize, analyze, and draft by default. An assistant deployed inside a client’s team workspace may answer questions or post internal replies independently when that is an agreed part of its role.

Actions that are outward-facing or difficult to reverse—such as contacting customers, changing business records, or deleting information—require approval from a named human.

No autonomous sensitive actions

Our AI systems may not independently move money, execute trades, change billing, or take financial, legal, or compliance-sensitive actions.

Least-privilege access

Each tool receives the narrowest access the platform reasonably permits. Access is granted per engagement and revoked when it is no longer needed.

Some platforms cannot technically enforce every desired boundary. When that happens, we explain the limitation and use written operating rules, human approval, and action review as additional controls.

A named owner for every system

Before an automation goes live, it must have a designated human owner, an approval rule, defined test cases, a logging or review path, a shutdown procedure, and an offboarding procedure.

How we test before connecting client data

We distinguish between validating a platform and launching it for a specific client.

Platform validation

Before using a new AI platform with client data, we test it in a separate environment containing synthetic data. Testing includes:

• Stage gates. Each material stage has a documented pass-or-fail result. Client data is not connected and a client system is not launched until the relevant hard gates pass.
• Kill-switch verification. We prove the system can be stopped, its credentials revoked, and its access removed.
• Backup and recovery testing. When a system requires backups, we verify recovery through an actual restore before relying on the backup design.
• Recorded evidence. Results include checkable evidence such as command output, hashes, timestamps, and observed behavior. Failures remain failures until repaired and reverified.

Per-client launch checks

Every client deployment receives a configuration-specific review before real data is connected. We verify that access matches the approved scope, shutdown and revocation paths work, required backups operate, client-specific boundaries are documented, and mandatory deployment tests have passed.

Credentials and access hygiene

• Layered infrastructure protection. For hosted or Hermes-based agents, we use multiple overlapping safeguards instead of relying on any single control. Depending on the deployment, these include private-network administration through Tailscale-protected SSH, Docker container or VM isolation, non-root execution, per-client credentials and environments, restricted public exposure, logging and backups, and built-in agent controls such as user allowlists, command approvals, protected file paths, and session isolation.
• Credentials, API keys, and tokens are stored in a dedicated password manager or approved secret store—not in documents, source-code repositories, or chat threads.
• If a credential is exposed, it is revoked and replaced promptly, and the incident is documented.
• Automated tools are prohibited from operating on screens that display credentials. Those steps are handled by a human.
• Access is reviewed when an engagement begins, when its scope changes, and when it ends.

The tools we rely on

We use established platforms rather than building unnecessary security infrastructure ourselves. Depending on the engagement, these may include Anthropic, Google Workspace, Slack, GitHub, 1Password, specialized integration platforms, and the client’s own systems.

Before connecting a platform, we review its role, data practices, available permission controls, and revocation path. Clients are told which tools their engagement uses and what each tool can access.

• Independent assurance. Some third-party platforms used in particular deployments maintain certifications or assurance reports, which may include SOC 2. Sageridge Group itself is not SOC 2 certified, and vendor attestations apply only to the named vendors and services. We provide available vendor documentation when appropriate.

If something goes wrong

If we discover an incident affecting a client’s data or systems, we notify the affected client promptly and without undue delay. Our target is notification within 72 hours of discovery.

Initial notification may occur before every fact is known. We provide what we know, what may have been affected, what containment steps were taken, and when the client should expect the next update.

1. Contain the incident by stopping the system or revoking access.
2. Determine what happened and what was affected.
3. Notify the affected client.
4. Correct the underlying issue.
5. Document the incident and the changes made to prevent recurrence.

What we ask of clients

Security is shared. We ask clients to grant scoped access instead of sharing passwords, use built-in permission controls, maintain appropriate account security and multifactor authentication, and tell us promptly when their systems, requirements, or approved access scope change.

Questions and due-diligence requests

This policy is maintained by Sageridge Group’s founders and reviewed at least every six months.

Questions or vendor due-diligence requests can be sent to joe@sageridgegroup.com.