Security
Last updated: July 01, 2026
TL;DR
- Runs entirely on best-in-class managed cloud infrastructure — there is no server to patch and no exposed database to breach.
- Card data never touches the platform — payments are handled end-to-end by a PCI DSS Level 1 provider.
- Setup mistakes fail closed: the database denies everything by default, so an incomplete setup breaks features — it doesn't leak data.
- Every client workspace is isolated at three independent layers, and every AI action requires human confirmation before it can change anything.
- Single-tenant by design: your deployment holds only your business's data — never pooled with other companies.
- No black box: the owner holds the complete source code, so every claim on this page can be independently audited.
How Productive Focus AI Hub works — context first
Productive Focus AI Hub isn't a shared platform you sign up to. When you purchase Productive Focus AI Hub, you — the owner — spin up your own private CRM, under your own brand (“YourCRM”), running on accounts you control with best-in-class providers for data, payments, and hosting. One deployment, one owner. Your client workspaces live inside your deployment and nowhere else. Everything below describes how that deployment protects the data inside it.
Security claims are easy to make and hard to check. This page explains, in specific terms, how Productive Focus AI Hub protects the data inside it — the architecture, the defaults, and, honestly, the parts that are your responsibility as an operator.
1. Built on best-in-class managed services
Productive Focus AI Hub does not run on hand-managed servers. Data storage, payments, and hosting are each delegated to best-in-class managed cloud platforms — the same infrastructure providers trusted by banks, healthcare companies, and Fortune 500 enterprises.
That means there is:
- No server to patch. The hosting platform manages the operating system, network, and runtime — security updates are its job, applied continuously.
- No exposed database. The data layer has no open port, no connection string to leak, and no direct network access. It is reachable only through authenticated, permission-checked paths.
- No card data in the platform, ever. Payments are processed end-to-end by a certified payment provider (PCI DSS Level 1). Card numbers never touch Productive Focus AI Hub's code or database.
The most common causes of real-world data leaks — unpatched servers, exposed database ports, default credentials — are not risks this architecture merely mitigates. They are categories of mistake that cannot happen, because the components they apply to don't exist here.
2. Fail-closed by default
A fair question about any self-managed software: “what if the operator sets it up wrong?” The answer here is that the platform is designed to fail closed:
- The database denies all access by default. Access rules must be explicitly deployed before anything can be read — a skipped setup step produces a broken feature, not exposed data.
- Sign-up is locked. The first administrator account is restricted to a pre-configured email address, and every subsequent user must be explicitly invited. There is no open registration.
- Optional features ship off and must be deliberately enabled per workspace by the account owner.
In other words: the failure mode of an incomplete or incorrect setup is an app that doesn't work yet — not an app that leaks.
3. Workspace isolation, enforced three times
Productive Focus AI Hub is multi-workspace: each client workspace holds its own contacts, deals, conversations, and records. Isolation between workspaces is enforced at three independent layers, so a failure in any one layer is caught by the others:
- Database-level security rules — every read and write is checked against the caller's verified workspace membership, at the data layer itself, before any data moves.
- Server-side permission checks — every API endpoint independently re-verifies the caller's identity, role, and workspace membership from their authenticated session. Nothing is trusted from the browser.
- Record-level re-anchoring — whenever one record references another (a deal's contact, a task's owner), the platform re-verifies the referenced record belongs to the same workspace before acting. A crafted or mistaken ID cannot reach another workspace's data.
4. Roles and access control
- Authentication uses secure, signed session cookies managed by an enterprise-grade identity service — not home-rolled password handling.
- Access is role-based: account owners, workspace administrators, and collaborators each see and do only what their role allows.
- Feature availability is controlled per workspace by the account owner — a workspace cannot switch on capabilities it hasn't been granted.
- Removing a member takes effect immediately: their access is revoked, their sessions are invalidated, and their sign-in is disabled if they hold no other access.
5. Secrets and credentials
- The codebase ships with zero embedded credentials. Every service key is supplied by the operator and stored in the hosting platform's encrypted configuration — never in source code.
- API keys are stored as one-way cryptographic hashes only. The full key is shown exactly once at creation. Even a complete copy of the database cannot recover a working key.
- Keys are revocable and scoped: each API key belongs to one workspace and can only ever see that workspace's data.
- Secrets are masked in logs, so an accidental debug line can't leak a credential.
6. Public links that can't be forged
Some pages are deliberately public — a quote sent to a customer, a booking page, an unsubscribe link, a payment link. Every one of them is protected by a cryptographically signed token:
- Tokens are signed (HMAC) and cannot be guessed or forged.
- Only a one-way hash of each token is stored — the working link exists solely in the recipient's email.
- Re-sending rotates the token, which instantly invalidates every older copy of the link.
7. Verified integrations
Every inbound webhook — payment events, inbound messages, call events, scheduled jobs — is signature-verified before a single byte is processed. A request that doesn't carry a valid cryptographic signature from the expected service is rejected. There is no unauthenticated write path into the platform. Outbound webhooks are signed too, so your own integrations can verify that events genuinely came from your deployment.
8. AI, with a human in the loop
Productive Focus AI Hub includes AI assistants and AI conversation agents. They are governed by strict, structural limits:
- The assistant can only invoke a fixed, audited list of capabilities — it has no general access to the database and no way to compose its own queries.
- No AI action can modify data without a human explicitly confirming it first. Reads run instantly; every write requires a click.
- Every AI capability is anchored to the caller's own workspace, and an automated check runs on every code change to enforce that rule — it is a build failure, not a code-review hope.
- Every AI action — proposed, executed, or failed — is written to an append-only audit trail.
9. One deployment, one owner — a smaller blast radius
Unlike a traditional SaaS platform, where thousands of companies' data sits in one shared system and a single breach exposes everyone, each Productive Focus AI Hub deployment is single-tenant: it holds one business's data, in accounts that business controls. Your data is not pooled with anyone else's, is not mined or resold, and can be exported or deleted by you at any time.
10. No black box
Perhaps the most important difference: Productive Focus AI Hub is not a black box you have to take on faith. The operator of a deployment owns the complete source code. Every claim on this page is verifiable by reading it — or by having any security professional of your choosing read it. Closed platforms ask for trust; this one can be audited.
11. What's on you (honesty matters)
No architecture removes every responsibility. If you operate a deployment, the platform's security assumes you will:
- Protect the accounts behind your deployment — use strong, unique passwords and enable two-factor authentication on your hosting, data, and payment provider accounts.
- Treat your service keys and environment configuration as secrets — never commit them to a public repository or share them in chat/screenshots.
- Apply updates when they're published, and complete the documented setup steps (the built-in setup checker verifies the important ones for you).
These are the same obligations you'd have with any business software — including SaaS, where your team's passwords are just as much the weakest link.
12. Reporting a security concern
If you believe you've found a vulnerability, we want to hear about it — please report it privately rather than publicly, so it can be fixed before details circulate. and we'll take it from there. Good-faith reports are always welcome and never punished.