Your data, your tenancy,
your audit trail.
CoreShift handles business-critical workflows for small companies. That means handling sensitive operational data — vendor pricing, customer contacts, financial roll-ups, employee records. Here's how we approach that responsibility, and what we commit to.
Your data lives in its own database container.
Every CoreShift customer gets a dedicated Postgres schema — a named container inside our database that holds only your tables. Other customers cannot read, write, or query your data.
This is enforced at three layers:
-
Database-level: search_path scoping.
When a bot opens a database connection to handle your request, the connection is configured to only see your schema. SQL queries like
SELECT * FROM bid_bidsresolve toyour_schema.bid_bidsautomatically — and cannot resolve to anyone else's table.This is not application-layer filtering ("WHERE tenant_id = ?"). It's connection-level scoping enforced by Postgres itself. If our application code had a SQL injection vulnerability tomorrow, the database would still refuse to serve another tenant's data through your connection.
-
Routing-level: gateway enforces the tenant in the URL.
Every API call into CoreShift includes your tenant identifier in the URL path:
/t/your-tenant/bot-name/.... The gateway verifies your tenant exists, is active, and that you've subscribed to that bot before passing the request to bot code. There is no API route that operates without an explicit tenant context. -
Credential-level: your integrations use your own secrets.
Your Twilio account, your Microsoft 365 tenant, your CRM API key — each lives in a per-customer secrets path. Bots running for your tenant can only access credentials scoped to your tenant. A bot servicing customer A cannot mistakenly send SMS from customer B's Twilio number.
Every action is recorded. Append-only. Reviewable.
Every meaningful action a bot takes on your behalf writes a row to your audit_log table:
2026-05-18 14:32:17 bid_coordinator sms_received +1858XXX "STATUS YDP2"
2026-05-18 14:32:17 bid_coordinator sms_sent +1858XXX bid YDP2 in REVIEW_PENDING
2026-05-18 14:35:02 bid_coordinator state_transition — YDP2: REVIEW_PENDING → APPROVED
2026-05-18 14:35:02 bid_coordinator pdf_generated — /artifacts/YDP2-final.pdf
2026-05-18 14:35:14 bid_coordinator gc_submitted — emailed to gc@whitnergc.comThis isn't a marketing log — it's a forensic record. Three properties:
Audit rows can be inserted but not modified or deleted. If a correction is needed, a new row references the original. There is no version of CoreShift where someone can "edit history."
Every inbound message, every state transition, every outbound action, every approval, every error writes a row. If the bot did it, it's in the log.
The audit log lives in your tenant schema. Once we ship the customer dashboard, you'll query and filter the timeline directly. Until then, we provide audit exports on request.
What our AI models see — and what they don't.
CoreShift bots use language models from Anthropic and Google for specific tasks: classifying scope, summarizing documents, drafting outbound emails. We're explicit about how that works.
| What models see | What models do not see |
|---|---|
| The content of the specific document or message being processed (e.g. "this incoming bid email") | Other customers' data — never, by construction |
| The specific business context needed for the task (e.g. your scope rules when classifying) | Your full database — only the records relevant to the current decision |
| Templated instructions about how to do the task | Credentials, API keys, or auth tokens |
We use AI model providers (Anthropic, Google) with enterprise data processing agreements that prohibit using your data for model training. Your data passes through their inference APIs to generate task responses, then is discarded by them — not retained, not used for training, not seen by their staff.
For specific bots in sensitive domains — Contract Review, Paralegal, Compliance, AP — additional restrictions apply, including human-in-the-loop approval gates for every external action and the option to run on-premises models for customers with regulatory requirements.
Encrypted in transit, at rest, and between services.
In transit
All connections to CoreShift use TLS 1.3 (with TLS 1.2 fallback for older clients). Webhook signatures are cryptographically verified before any handler runs. We do not accept plaintext HTTP traffic on any endpoint.
At rest
Production database storage is encrypted at the volume level using AES-256. Database backups are encrypted before leaving the host. Backups are retained for 14 days locally and archived to encrypted cold storage for compliance retention.
Between services
Internal service-to-service traffic inside the CoreShift platform runs over a private virtual network with no external exposure. The only paths into our infrastructure are the public webhook endpoints (signed) and admin SSH (key-based, IP-restricted, audited).
Secrets
Your integration credentials (Twilio, Microsoft, accounting APIs) live in a managed secrets vault, not in environment files or source code. Access is logged. Rotation is supported.
Who can see your data inside CoreShift.
-
Automated bot processes — by default.
Bots running for your tenant access your schema continuously to do their job. Their access is scoped to your tenant only. They cannot see other tenants' data.
-
CoreShift staff — only with your approval, time-limited.
CoreShift staff do not have standing read access to customer data. When support is needed — debugging a bug you've reported, helping with a tricky bid configuration — staff request a time-limited "support session" against your tenant, with a stated reason and a duration. The session is logged in the platform audit log (visible to you), and access automatically expires.
For high-sensitivity changes (modifying financial data, exporting full records), the session requires customer approval before opening.
-
Subprocessors — only what's necessary for the service.
We use a small set of external services to run CoreShift: AWS for infrastructure, Anthropic and Google for language model inference, Twilio for SMS, Stripe for payments. Each receives only the data necessary to do its part of the job — never your full dataset. We publish a current list of subprocessors on request.
Your data is yours. You can take it with you.
Three commitments we make about data ownership:
- You own your data. Everything in your tenant schema is yours — your contacts, your bids, your audit logs, your custom rules. We're the operator, not the owner.
- You can export it any time. On request, we provide a full export of your tenant schema as a Postgres dump or CSV. No engagement fee, no waiting period.
- If you leave, you can take everything. Cancellation triggers a final export delivered within 30 days. Data deletion follows on your schedule — immediate, 30 days, 90 days — your choice.
Honest disclosure on certifications.
We're a young company. We do not yet hold SOC 2 Type II or ISO 27001. We're on a path to those certifications as we scale; in the meantime, we operate to those standards even where we can't yet attest to them.
HIPAA-eligible — we sign BAAs with customers whose workflows require it. Healthcare clinics, billing operations, and other workflows touching PHI can be onboarded under a BAA as part of the standard onboarding process.
For customers in other regulated industries (financial services with regulated data, legal practices with privileged communications), we recommend reviewing the certifications above against your requirements. We'll be specific about SOC 2 and ISO 27001 timeline as it becomes concrete.
Found a security issue?
Email security@coreshift.technology with details. We acknowledge security reports within 24 hours and provide a fix or disposition within 72 hours for confirmed issues. We do not run a paid bug bounty yet, but we credit responsible disclosure on a public security page once one exists.