Security

Salesforce already enforces field-level security, object rights and record sharing for every user. The moment a tool authenticates as something other than the person using it, all of that stops applying and someone has to rebuild it in application code. Nobody rebuilds it correctly.

So every function we write takes the calling user token. The platform enforces that user permissions natively. We never reimplement permissions.

• Named accounts issued to named ShareCo people, created and revoked by you, inside your own user administration.
• Multi-factor authentication on every account, including sandbox accounts.
• A permission set scoped to the work, reviewed at the start of the engagement and again when the scope changes.
• No shared logins. Not for convenience, not for a demo, not for one afternoon.
• Destructive or org-wide changes are flagged before they run and staged where staging is possible.
• Access removal is a line item in the closeout checklist, not something you have to chase.

An API key inside a Salesforce org has exactly one safe home: the password field of a named credential, merged into the request header by the platform. It never becomes an Apex value, so it cannot be logged, cannot land in an exception message, and cannot be echoed back to a caller.

A protected custom setting is not an access control in an unmanaged org. Protected visibility restricts subscribers of a managed package, so in your own org that field is readable by any API-enabled user. We do not put keys there and we will tell you if we find keys there.

• Nothing derived from a provider error body is returned to a caller. Only a status code and a clean enumerated reason, so a key fragment in an upstream error cannot be persisted.
• Provisioning secrets are read from a hidden prompt or a file created outside the shell, then unset immediately. They are never echoed and never written to disk.
• Secrets never enter version control. Repositories are private, and a secret found in history is rotated rather than deleted and forgotten.
• Redeploying a named credential from source control blanks its password. That is a documented footgun in our own runbooks, because the silent failure it causes looks like a model outage.

Your data stays in your systems. We work inside them. Where an analysis genuinely needs an extract, we agree the scope first, keep it in a location you control where that is possible, and delete it at sign-off.

• Exports generated by a tool land in the requesting person own storage, created with their own token, owned by them, shared with nobody. The service account never holds the file.
• If a delivery cannot be shared with the person who asked for it, the file is deleted and the failure is raised. A swallowed sharing error leaves data sitting somewhere while the requester sees a 404, and that is how a leak stays invisible.
• No domain-wide delegation. A mailbox is only ever reached with that user own token, and calendar events are created as that user so they own them.
• Person-level data is not sent to a model. Company, city and country are enough for the work we do, and contact names are excluded from prompts.
• Every delivery of exported data is audit logged.

An AI feature is a new way for a system to be confidently wrong, so it gets controls that ordinary code does not need.

• Token resolution fails closed. If the calling user identity cannot be resolved, the tool raises a plain permission error rather than falling back to anything broader.
• A token is never sourced from application-scoped state. Application-scoped keys are shared by every user of an agent, so a token stored there would run one person session as another. That is a cross-user data leak and it is enforced against in three separate systems.
• Every write is wrapped in a required confirmation, so the user approves the change rather than discovering it. The confirmation itself has an end-to-end test proving that declining leaves nothing behind.
• Record data reaching a prompt is truncated, stripped of angle brackets and control characters, and wrapped in a data envelope marked untrusted. Every system prompt ends with the instruction to ignore anything inside that envelope resembling an instruction and to mention it in the output.
• Model output is validated before persistence. Enumerated values are allow-listed, scores range-checked, arrays capped, strings length-capped. Anything failing is dropped, not stored.
• AI-generated advice is stored read-only. Nobody can hand-edit a recommendation into looking like it came from the system.

Nothing is done until it works for the person whose job it is. We match their permission set or log in as them, run the whole flow they would actually perform, confirm the result they would see, then delete every test record created. If a true permission-scoped test is impossible we mark the work pending verification and say so.

• Changes to calculated financial output are regression tested by snapshotting the totals, deploying, and recomputing. Any delta is treated as a defect in the mapping until proven otherwise.
• Test classes ship with the code. On the reference engagement, 46% of the Apex codebase is test classes, counted as 144 test classes against 170 production classes.
• Long-running integrations carry a heartbeat and an hourly watchdog. A sync that stops silently is worse than one that fails loudly, and we have watched a silent stop cost about twelve hours before anyone noticed.

If we confirm an incident affecting your systems or your data, you hear from us within one business day of confirming it. The first message says what we know, what we do not know yet, and what we are doing. We do not wait for a complete picture.

To report something to us, email security@shareco.ca. A good-faith report is never treated as an attack.

• Full-disk encryption and automatic screen lock on every machine that touches client work.
• Multi-factor authentication on every account we hold, with a password manager rather than reuse.
• Client work does not run on personal devices.
• Repositories are private, and access is granted per person and removed at offboarding.
• Continuous integration holds only the credentials a pipeline needs, scoped to that pipeline.

A security page that lists only strengths is a sales page. Here is the other half.

• We are not SOC 2 or ISO 27001 certified today. We will tell you if that changes.
• We hold no independent penetration test report for our own systems. We will complete your vendor security questionnaire honestly, including the questions where the answer is no.
• We are a small firm. Our resilience comes from keeping your data in your systems rather than from a large internal security function, and you should weigh that.
• We do not promise an accuracy figure for any AI system. We hand you the evaluation and its basis instead.