Security

At a glance

• KinetiX acts as the signed-in person in Epicor, with that person’s own permissions. It has no standing account of its own in your ERP.
• In chat and the side panel, nothing in Epicor changes until the user approves it on a card.
• A connection can be read-only. Write access is a separate choice at sign-in, and read-only connections cannot run changes.
• Stored connection secrets are encrypted at rest with AES-256-GCM. The key is a Worker secret, not kept with the data.
• MCP clients sign in with OAuth 2.1 and PKCE. Access tokens last one hour.
• Administrators sign in with an emailed one-time code, limited to an allow list.
• BAQs are validated against Epicor before the approval card appears.
• Nothing is installed on your Epicor server. KinetiX uses Epicor’s REST API.

KinetiX runs as you, with your permissions

To use the chat, the side panel or an MCP client, you sign in on KinetiX’s own page with your Epicor username and password and choose an Epicor connection. KinetiX checks the login against Epicor before it accepts it. Every request after that is sent to Epicor as you.

That means Epicor’s own security applies: your roles, your company access, and the change tracking Epicor records against your user. If Epicor would refuse you something, it refuses KinetiX too. The connection’s API key is what Epicor asks of REST clients; requests are still made with your login.

One exception, by design: comparing environments and promoting between them. When you compare your connection with another one (for example Pilot with Live), or copy BAQs, reports and menus from it, KinetiX reads the definitions of those customizations in the other environment with that connection’s stored API key and service account, because you are signed in to only one. It reads customization definitions only, not business records. What is created by a promotion is created in your own connection, as you, after you approve the plan.

Approvals and read-only connections

In the chat and the side panel, the assistant can look things up on its own, because reads change nothing. Anything that would change Epicor stops and comes back as a card showing exactly what will run: a record edit, a new or changed BAQ, a report, or a menu entry. It runs only after the user approves, one change at a time. This gate is in KinetiX’s code, not in the model’s instructions, so a record or a page title that tries to talk the model into a change still cannot run one without a click from you.

Building a query, report or menu runs in order: BAQ first, then report, then menu. Each step needs its own approval.

The sign-in page grants read access by default. Write access is an extra box the person must tick. A connection without it refuses every change, in the chat and over MCP. In the chat, a read-only connection is labeled as such in the header.

Over MCP, how a third-party client asks you to confirm an action is up to that client. If you do not trust a client to ask first, grant it read access only.

BAQs are checked before you approve them

When the assistant proposes a new BAQ, KinetiX first validates it against your Epicor without saving anything. The approval card shows the result: the tables, fields, joins and criteria that Epicor accepted, or why it refused. You see whether the BAQ is valid before you decide.

Encryption of stored secrets

An administrator adds an Epicor connection with its REST address, company, and an API key or a service account. The API key and password are encrypted with AES-256-GCM before they are written to storage. Each value gets a fresh random 12-byte initialization vector, and the connection id is bound to the ciphertext as additional authenticated data, so an encrypted value copied onto another connection does not decrypt.

The 256-bit key is held as a Cloudflare Worker secret, separate from the stored data. The admin page never shows credentials back: they can be written and replaced, but not read.

When someone signs in, their Epicor password is kept inside the OAuth grant, which the OAuth library encrypts so that only the holder of the token can unwrap it. The grant expires with the refresh token, up to 30 days after sign-in, and signing out revokes it. The Privacy Policy lists everything that is stored and for how long.

Sign-in and access tokens

• MCP clients and the chat use OAuth 2.1 with PKCE (the S256 method). The plain method is refused. The consent page names the app asking and the address access will be sent to, and warns when that address is on your own computer.
• Tokens are scoped. Access tokens last one hour and refresh tokens up to 30 days. The OAuth library stores tokens hashed. Signing out in the chat revokes the grant.
• Administrators sign in to /admin with a six-digit code emailed to an address on an allow list. The code expires after 10 minutes, is stored only as a hash, and is blocked after five wrong attempts. The resulting session lasts 7 days.
• Static operator token. An operator may set one access token for terminal agents that cannot do a browser sign-in. It also opens the administrator API. It is optional: if it is not set, that route is closed. It is outside the OAuth consent flow, so treat it as an operator credential.

Network and hosting

KinetiX runs on Cloudflare Workers. Traffic between your browser and KinetiX is served over HTTPS by Cloudflare. KinetiX calls your Epicor at the address stored in the connection. The connection form also accepts http addresses, so use an https address for any instance that holds real data. The KinetiX server reaches Epicor over the public internet, so an on-premises Epicor must be reachable that way. The epi command-line tool is the option that runs from inside your network, because it talks to Epicor from your own machine.

We have not restricted processing to a single region, so Cloudflare may handle requests in any of its data centers.

What the AI model sees

The chat model runs on Cloudflare Workers AI. It receives your conversation, your Epicor username and company id, and the lookup results Epicor returns for you. It never receives your Epicor password or API key. It can call only a fixed list of Epicor tools. Cloudflare states that it does not train AI models on content processed by Workers AI. See the Privacy Policy for details and links to Cloudflare’s own terms.

What stays in your hands

• Epicor roles. KinetiX can do only what the signed-in user can. Giving people the right Epicor roles is the strongest control you have.
• Who may sign in. Your Epicor administrator decides which users and which connections exist.
• Write access. Leave it unticked for people who only need answers.
• Test first. Use a test connection to try a build before you approve the same change in Live.
• Nothing on the server. KinetiX does not install anything on your Epicor server. It needs the REST API, an API key and the user’s own login.

Logging

Cloudflare Workers Logs are enabled for the KinetiX server. They record request details and the messages the code writes. The code writes sign-in error categories and email send failures. It does not write chat messages or Epicor results. Cloudflare keeps these logs for the retention period of our Cloudflare plan.

What we do not claim

This page describes how KinetiX is built and run. It is not a certification or an audit report, and we make no claim of SOC 2, ISO 27001 or similar attestation for KinetiX. If your security review needs more detail, talk to us and we will answer in writing.

Reporting a vulnerability

If you find a security problem in KinetiX, email support@opexcg.com with “Security” in the subject. Say what you found and how to reproduce it. Please give us a reasonable time to fix it before you share it more widely, and do not access data that is not yours or disrupt the service while testing. We will confirm that we received your report and keep you informed.