Automation / Security
What is actually in place, what is not, and which parts are yours to decide. Written to be checked, not to reassure.
Each tenant's records live in their own Postgres schema, and a bot connects with its search_path scoped to that schema. The isolation is a property of the connection rather than of every query being written correctly. A query that forgets a tenant filter finds nothing instead of finding somebody else's row.
The small amount of shared platform data — which tenants exist, which bots serve them — is read through a role that can only read it. Verified rather than asserted: the registry role holds SELECT and is refused on writes, on metering, and on every tenant schema.
A workflow is given access to the systems it needs and no others, and those credentials are held in protected environment files on the server. That is not a managed secrets vault, and it is named here as what it is rather than dressed up.
A bot assembles a specific, bounded prompt for the step it is on: this request, these fields, these rules. A model is never handed a connection to your data and left to explore it, and the deterministic parts of a workflow — deduplication, routing, thresholds, approval gates — are code, not a model's judgement.
Nothing from your tenant is used to train a model, and CoreShift does not fine-tune on customer records. Where an engagement needs that written into an agreement rather than read on a page, it can be.
Wherever the consequence of being wrong is external — an email to your customer, a document, a payment reminder — a person approves before it leaves. A model that is confidently wrong produces a draft somebody rejects, not a message a customer receives.
Security
A dedicated Postgres schema scoped at the connection, not filtered in application code. Every meaningful action writes an append-only row you can read back.
The platform appends a record of each workflow action as it happens: what arrived, what was decided, what was refused, what was prepared, who approved it and what finally went out. Refusals and halts are recorded as carefully as successes — a log that only shows the happy path cannot tell you why something did not happen.
2026-09-14 09:12:04 request.received src=email id=REQ-2214 2026-09-14 09:12:04 duplicate.check result=new id=REQ-2214 2026-09-14 09:12:06 record.created owner=client-svc id=REQ-2214 2026-09-14 09:12:09 field.missing field=headcount action=halted 2026-09-14 09:31:52 draft.prepared type=reply approval=required 2026-09-14 10:04:18 approved by=operator edits=1 2026-09-14 10:04:19 email.sent to=requester id=REQ-2214
Illustrative shape, not a customer's log. Which records your engagement keeps, how long they are kept, and how you get them out are set in your agreement.
Approval thresholds, who owns each escalation, and which actions may ever run unattended are defined before a workflow goes live — not discovered afterwards.
A drafted action sits until a person releases it. Where a workflow has a send gate, nothing external leaves while the gate is held, and "the gate is held" and "the integration is broken" are distinguishable states rather than both looking like silence.
How a workflow is paused, who is alerted, and what happens to work already in flight are agreed at onboarding. A workflow should not continue quietly when its inputs or its permissions are wrong.
Traffic to every CoreShift site and endpoint is served over TLS 1.3. Internal services bind to the host or the private Docker network rather than the public internet, and the platform database is not published to a public port.
Encryption at rest is not in place on the production volume today. It is a planned change with a written procedure, and it is not finished. Database dumps and the secrets bundle are encrypted before they leave the machine for off-site backup; the volume itself is not yet encrypted. We would rather tell you that than let you assume otherwise from a padlock on a page — and if encryption at rest is a requirement for your engagement, ask where it stands before you sign, not after.
Your records are yours. Not "yours subject to the platform", and not held hostage by an export format nobody else can read.
Not only on the way out. If you can only get your data when you are leaving, you did not have it.
When an engagement ends you get a complete export, in an agreed format, within an agreed window. Put the window in the agreement.
CoreShift does not hold SOC 2 Type II or ISO 27001 certification, and does not claim to operate to those standards. We do not present a marketing page as evidence of compliance.
CoreShift can sign a Business Associate Agreement where an engagement requires one. No CoreShift system holds protected health information today; that is a statement about what exists, not a limit on what a workflow could be scoped to do.
No bot runs unattended for a client today. The Project Coordinator has delivered a month's packages to Precision Electric; everything else in the catalog is scoped and priced work, built to your setup — not a service already running that you are being added to.
Contact security@coreshift.technology. Describe the affected service and the issue. Please do not put passwords, private records or exploit material into the general inquiry form.
Where an issue affects your data, you will be told — with what is known, what is not yet known, and what is being done. The disclosure timetable for your engagement belongs in your agreement.
Contact CoreShift See how the platform is put togetherLet’s talk about the work
Show us the spreadsheet, the website, or the task you keep explaining. That’s enough to start a useful conversation. Start a project