Skip to main content
BYOM is built on one assumption: the AI is not trusted. Kina, the model behind it and any AI client you connect all sit outside BYOM’s trusted boundary. BYOM is the boundary. It holds the credentials, the company records and the authority to change anything, and it gives an AI only what one piece of work needs.

​
The boundary

OUTSIDE THE BOUNDARY
Kina’s runtime and modelShort lived access scoped to one run
AI clients you authoriseOAuth grant for the data classes you consent to
No store, helpdesk or marketing credentials
BYOM · THE TRUSTED BOUNDARY
Tool gatewayChecks company, permission and operation on every call
Company memory and recordsScoped to one company by the database
  1. Action
  2. Approval
  3. Single write path
  4. Receipt and audit
Credentials encrypted and held here
YOUR SYSTEMS
Store, helpdesk, marketing and paymentsRemain the systems of record

​
Company isolation

Every record in BYOM belongs to one company: work, memory, connections, Actions and receipts. The database enforces that scope on every application request, so a query made without a company context returns nothing rather than another company’s rows. Within a company, roles decide who can read, edit, share and approve. A new Readout is private to its maker until it is shared.

​
Credentials stay with BYOM

Kina never receives a store, helpdesk or marketing credential. It never sees a token in a prompt. When Kina works, BYOM issues it short lived access scoped to that run, and that access can only reach BYOM’s own tools.

​
How Kina reaches anything

Kina works in its own runtime, outside the boundary. It reaches your business only by calling BYOM tools through the tool gateway. Advertising a tool to Kina grants nothing: every call is checked at the gateway against the company, the connection’s permissions and the operation. Each request has limits that Kina cannot change:
  • A step ceiling. A request can make only a bounded number of tool calls.
  • A spend check before every step. Your company’s cap and any stop set by BYOM apply mid request, not only at the start.
  • An honest stop. When a limit stops a request, BYOM records it as stopped and discards any answer that claims the work finished.
Usage and cost are measured where calls enter BYOM, never taken from what the AI reports about itself.

​
How a change reaches your systems

Nothing writes to a connected system except through this path:
  1. Proposal. Kina, a Rail or an authorised AI client proposes an Action. The target, the exact payload and the evidence are fixed at that point.
  2. Approval. A person with authority approves or rejects that exact version. A changed payload is a new proposal. Approvals expire. High risk changes ask for your password again, and a batch approval never stands in for one.
  3. Execution. BYOM sends the approved change through its single governed write path. No other part of the product writes to your systems.
  4. Receipt. BYOM records what was attempted and what the system returned, item by item. An uncertain result is reconciled against the provider before anyone retries.
Undo is offered when the change has a safe reversal, and the reversal is itself a reviewed change with its own receipt.

​
Memory belongs to BYOM

Kina’s working notes inside a run are disposable. Durable memory is stored in BYOM, scoped to the company and governed there: company memory needs an owner or admin to approve it, and anything saved can be corrected or forgotten through the supported controls.

​
Other AI systems

An AI client you connect, such as an assistant using the Shopify MCP connector, signs in with OAuth and PKCE and gets a grant you consent to. The grant names the data classes it may use and whether it may propose changes. It never gets Kina’s private access, its runtime or its credentials, and it can never approve its own proposal. The Shopify connector masks customer email addresses and does not read phone numbers. See Data and access.

​
Audit

Decisions and executions are recorded with who acted and when. You can export the governance record for an Action or a date range.

​
What is still being built

We state the gaps rather than imply the target is already met.
  • Model calls. Tools, memory and changes to your systems already follow the rules above. Model calls from Kina’s runtime are moving onto the same metered BYOM entry point.
  • Dedicated runtimes. A dedicated, isolated runtime for each paying company is the target. Not every account has one yet.
  • Certifications. BYOM does not currently hold a security certification. Hosting location, retention and contractual commitments are in the legal and account documentation for your service.
This page will deepen as each of these is finished. Reviewed 4 October 2026.