Trust & security · v0.4 · May 2026
A trust page that leads with promises is a trust page that ages badly. So we lead with commitments we will not violate — and architecture that makes violating them difficult or impossible by design.
01 · Never
We will never write to your Epicor.
TalkERP runs read-only against your Epicor instance, period. To enable any write action, an admin must explicitly grant a per-tool write scope — and we ship without one.
02 · Never
We will never train on your data.
Anthropic’s standard API terms preclude training on customer queries or responses. A formal zero-retention enterprise agreement is on our roadmap for additional certainty.
03 · Never
We will never cross-tenant.
Memory accumulated in your tenant is yours. It is not pooled, embedded, or used to improve answers for other customers. Architecturally impossible, not just policy.
01 · The commitments, in full
Each commitment below is enforced by either architecture, contract, or both. If we ever change one of them, this page changes with it — and the change goes in the public changelog, dated, with a reason.
We will never write to your Epicor without explicit per-action consent.
After onboarding, TalkERP runs strictly read-only against your Epicor instance. Onboarding includes a single admin-authorized step: an Epicor admin from your team gives us your environment URL, instance, company number, and admin credentials so we can provision a read-only API keyfor your tenant — and that’s the only write that ever happens on your behalf. From there, every operation runs through that read-only key. To enable any subsequent write tool, an Epicor admin must explicitly grant a per-tool write scope — and we ship with none enabled.
We will never train AI models on your queries, your data, or your memory.
Anthropic’s standard API terms preclude training on customer queries or responses. Your memory and queries are stored in your tenant only. A formal zero-retention enterprise agreement is on our roadmap for additional contractual certainty.
We will never share data across tenants, for any reason.
Memory, queries, citations, audit logs — everything is tenant-scoped. We do not pool, embed, or aggregate across customers. The architecture cannot do it; the database is partitioned, not policy-gated.
We will never see what your Epicor RBAC says we shouldn’t.
Every user’s view of TalkERP mirrors their Epicor role exactly. If a user can see AR but not GL in Epicor, they see AR but not GL in TalkERP. This is enforced at the data layer— every query runs against your Epicor with the asking user’s own per-user credentials, so the Epicor API itself returns only what that user is allowed to see. No copied permission table to sync; no policy gate to drift.
We will never sell your data. Or your queries. Or your memory.
Not to advertisers, not to data brokers, not as anonymized training sets. Period. Selling your data is grounds for terminating our own existence as a company.
We will never retain your data after you leave.
Our commitment is full tenant erasure within 30 days of cancellation. Today this process is manual but reliably performed; full automation with hash-confirmation is on the roadmap. Customers who need accelerated deletion can request it.
We will never assert a fact without showing its source.
TalkERP is designed so every assertion is pinned to a source — a record, an email, a learned memory fact with a date. Tool calls return structured source data; the agent loop is instructed to cite that data inline with numbered references; citations render in the UI alongside the answer. You can drill in, audit, correct. As with any LLM-grounded system this is a regression-tested behavior we monitor, not a hard guarantee — and we treat exceptions as quality bugs and fix them on report.
We will never obscure what memory we hold.
Every accumulated memory fact is visible in your tenant. Any user with the right scope can list, filter, edit, and delete memory. No opaque embeddings, no “trust the model.” Memory is a queryable, deletable database.
We will never ship a connector you didn’t ask for.
Every external system TalkERP touches — Epicor, Plaid, M365, documents — is opt-in. No connector activates without an admin’s enable action and credential. New connectors do not auto-enable on upgrade.
We will never charge you to export your data or memory.
Free memory export is a contractual commitment, available on request today. A self-serve export endpoint (JSON, with Parquet planned) is on the roadmap. Including on the day you cancel.
We will never hide a security incident.
Any incident involving customer data is disclosed to affected customers within 72 hours, with a post-mortem within 14 days. Posted on the public changelog and the status page, dated.
We will never update these commitments without telling you.
Material changes to this page are versioned. The changelog at the bottom shows what changed, when, and why. Customers are notified by email seven days before any change takes effect.
02 · How the data flows
The single most important question on any trust review: who has my data, where, and for how long. Here’s the answer, end to end.
Data residency. All tenants currently run in a single US region on Railway (our hosting and Postgres partner). Multi-region (DR + EU) is on the roadmap. EU-based customers requiring EU data residency should contact us before signing.
WorkOS handles single sign-on across your TalkERP tenant — SAML, OIDC, Google, and Microsoft IdPs supported out of the box. Session issuance and refresh live with WorkOS; no passwords are stored in our database.
This is the gate to the product surface — chat, history, settings — but not the gate to your Epicor data. That is Layer 2.
Every read against Epicor uses the asking user’s own Epicor credentials. Permissions mirror Epicor’s native RBAC — if a user cannot see a table in Epicor, the agent cannot return it for them.
Onboarding: the tenant admin imports active Epicor users and manages per-user credential storage and access scope. Credentials are encrypted with a per-tenant key and used only on the user’s own behalf.
Under the hood
The 55 public-facing read agents are composed from 180+ underlying tool primitives — low-level operations against Epicor’s OData and Business Object endpoints (across AR, AP, GL, Cash Management, Sales, Orders, Jobs, Inventory, Purchasing, Engineering, Shipping, CRM, Labor, Quality, MRP, Service, Attachments, and Administration), plus the Plaid, Microsoft Graph, and document-parsing layers. Agents are the unit of use; tool primitives are the unit of capability.
03 · Compliance status
Some vendors plaster their site with badges that mean less than they suggest. We list the actual status of each — including the items that are in progress or out of scope with reasons.
SOC 2 Type II
Operating-effectiveness audit across Security, Availability, and Confidentiality trust criteria. On the roadmap; no auditor engaged yet.
SOC 2 Type I
Point-in-time controls audit. Planned to precede Type II; not yet engaged. We’ll post the auditor and audit window here as soon as it is set.
GDPR
DPA available on request. EU data residency is on the roadmap — contact us before signing if it’s required.
CCPA
California Consumer Privacy Act. Customer- and user-level data deletion supported on request today; self-serve UI on the roadmap.
HIPAA
Not pursued. TalkERP is for manufacturing operations, not healthcare. If you operate a hospital and want to use us, talk to us first.
ISO 27001
On the roadmap for after SOC 2. We will not pursue earlier — the controls overlap heavily with SOC 2 and we’d rather do one well.
Encryption
AES-256 at rest, TLS 1.3 in transit. Customer-managed KMS keys are on the roadmap, not available today.
Penetration test
Independent third-party pen test is on the roadmap; vendor not yet selected. We’ll publish the firm and scope here once engaged.
04 · Sub-processors
A short list, deliberately. Each vendor below has a documented purpose and operates under their standard data-processing terms — custom DPAs are available on request for Enterprise deals. We do not add a sub-processor without notifying customers and giving 30 days to object.
Provides the model that generates TalkERP’s responses. Operating under standard Anthropic API terms, which preclude training on customer queries and responses. A formal zero-retention enterprise agreement is on our roadmap.
Compute, hosting, and managed Postgres for the TalkERP product backend. Tenant data is encrypted at rest with TalkERP-managed keys; Railway personnel do not see plaintext customer data. Single US region today; multi-region on the roadmap.
Bank balance and transaction read access for the cash-management features. Only activated per tenant after explicit admin opt-in with named bank accounts. Tokens revocable by the customer at any time.
Email + calendar context for orders, customer threads, and vendor confirmations. Activated per tenant after explicit admin opt-in with OAuth scoped to the asking user. Read-only on the data we actually use.
WorkOS for SAML / OIDC / Google / Microsoft SSO at the SaaS login layer (today the internal deployment uses application-managed auth + per-user Epicor credentials). Multi-region Railway for DR and EU residency. Anthropic enterprise zero-retention agreement. SCIM directory sync.We will move each card up here once it’s live in production — not before.
05 · Asked & answered
01Can TalkERP modify our Epicor data?
Out of the box, no. TalkERP’s Epicor account is granted read-only API scope on installation. Write tools must be turned on individually, per Epicor module, by a named admin with a logged reason — and the default install ships with none enabled. Most customers leave it that way.
02Where physically does our data live?
Today: a single US region on Railway (our hosting + Postgres partner). Multi-region (DR + EU residency) is on the roadmap. If you are an EU-based buyer who requires EU data residency at signing, tell us before we sign anything — we will not promise what we have not yet built.
03Does Anthropic see our data?
Yes — for the duration of generating a single response. We operate under standard Anthropic API terms, which contractually preclude training on our customers’ queries or responses. We do not yet have a formal zero-retention enterprise agreement; that is on our roadmap and will be reflected here when in place.
04What happens if a TalkERP employee gets curious?
They can’t see your data. Customer tenants are isolated and TalkERP staff have no production access outside of incident response. Incident-response access is logged, time-boxed, named, and audited. There is no “support can see customer data” mode — because we built it without one.
05What happens when we cancel?
Our commitment: within 30 days your tenant is fully erased — memory, queries, logs, citations, every byte. Today this process is manual but reliably performed; a fully automated deletion endpoint with hash-confirmation is on the roadmap. Memory exports are free and available on request, including on the day you cancel.
06Are we on a shared model?
No. Nobody is on a shared model in the way that phrase usually means. Every TalkERP tenant runs against a stateless inference endpoint (Anthropic) with your own retrieved context, your own memory, and your own audit log. There is no cross-customer pooling, embedding, or fine-tuning. The model itself is a commodity; your tenant is where the value lives.
07Who at TalkERP can read our queries?
Nobody, in the normal case. In the abnormal case — a critical bug, a customer-initiated support request, an incident — named personnel can request time-boxed read access. The request is logged, approved by a different person, and shown to you in your audit log. You will know.
08Do you offer a self-hosted version?
Not yet. A genuinely self-hosted version, and a single-tenant dedicated-VPC option, are both on the roadmap and will be developed in response to specific cohort demand. If air-gap or VPC isolation is a deal-breaker for your shop, talk to us early — we’d rather know what to build than over-promise what we don’t.
For your security review
10 operational areas covered today, with honest disclosure of what’s on the roadmap.