The mechanism, not the policy
Every sharing decision on Co-Signal runs through one server-side authorization layer and one k-anonymity threshold, the same layer and the same threshold every time, on every read. The rest of this page shows exactly how that decision gets made, running live against fictional data.
Try it yourself
Flip Larkfield Dynamics's visibility level below and watch what they see change. This runs Co-Signal's own redaction functions and its real k-anonymity threshold against fictional data, entirely in your browser, with no network call.
One authorization layer, every surface
Every surface of the product, the web app, Slack, the AI agent, the MCP server, and CRM writeback, calls through the same server-side layer to decide what a partner may see. Sharing changes are written to an audit log, shaped like the specimen below.
Audit log specimen
| Event | Before | After | Actor | Timestamp |
|---|---|---|---|---|
| Visibility loosened | counts only | overlapping accounts | J. Alvarez | 2026-02-03 14:12 UTC |
| Fields changed | No extra fields | company type, open opportunity count | M. Chen | 2026-02-11 09:47 UTC |
| Visibility tightened | all accounts | overlapping accounts | J. Alvarez | 2026-03-02 17:30 UTC |
What we actually do
Encrypted CRM tokens
Every connected Salesforce or HubSpot token is encrypted at rest, never stored in plain text.
Server-side enforcement, every time
The same authorization layer decides what a partner sees whether the surface asking is the web app, Slack, the AI agent, the MCP server, or a CRM writeback.
An audit log of sharing changes
Every time a company loosens or tightens a partner's visibility, or changes which fields are shared, it is written to an audit log, not just applied silently.
Conservative sharing defaults
Every new partnership starts at counts only. Nothing is visible to a partner until a company explicitly opens it up.