June 23, 2026 · 6 min read

Bring your own key: how AI runs in Elliptic

Every AI feature in Elliptic runs on your own model key, encrypted at rest and written to an audit log. Here is how it works, and why it is the safe way to run agents.

By Ege Çelebi

AI features in most work tools run on the vendor's model key, through the vendor's pipeline, behind the vendor's logging. Your prompts and your data pass through infrastructure you do not control, and you pay a markup on tokens you never see. Elliptic takes the opposite position. Every AI feature, the in-product assistant and the autonomous agents alike, runs on your own OpenAI or Anthropic key, against your own endpoint, with a full audit trail. This is what bring your own key means here, and this post explains exactly how it works.

Elliptic is an open-source, self-hostable, agent-native work platform. It unifies projects, tasks, sprints, meetings, notes, and a company wiki, and it ships a built-in MCP server that lets AI agents read and write the whole workspace. Letting agents act on real work raises an obvious question. Whose key are they using, and who can see what they send. The answer is yours, and only you.

Why bring your own key

BYOK is not a billing convenience. It is a trust boundary. When the key belongs to your organization, three things follow.

Trust. Your prompts and completions go directly from your deployment to the model provider you already have a contract with. There is no intermediary reading, retaining, or training on your data. The vendor relationship for AI is the one you choose, not one bolted on by the platform.
Cost control. You pay the provider directly at the provider's rate. There is no per-seat AI tax and no opaque token markup. You see usage on your own provider dashboard, and Elliptic records every run so the two reconcile.
Data residency. Because you pick the endpoint, you decide where inference happens. If you run against an Azure OpenAI deployment in a specific region, or an Anthropic endpoint under your own agreement, your data stays inside that boundary. The platform never routes it somewhere else.

For a security-minded buyer, the short version is this. The platform orchestrates AI. It does not own your AI. That separation is what makes the rest of the design defensible.

How keys are stored

A key is only as safe as the way it sits at rest. Elliptic treats provider keys as secrets from the moment they are entered.

Every key is encrypted at rest with AES-256-GCM. The data-encryption is wrapped under a per-deployment key-encryption key, the KEK, which lives with your deployment and never with the application data it protects. Decryption requires the KEK, so a dump of the database alone yields nothing usable.

Two further rules hold without exception. Keys are never written to logs, not in plaintext and not in any reversible form. And in the interface, only the last four characters of a key are ever shown, enough to recognize which key is configured and nothing more. There is no view, no endpoint, and no log line that returns a full key after it has been saved.

The guarantees, in one place

Keys are encrypted at rest with AES-256-GCM under a per-deployment KEK. Keys are never logged. Only the last four characters are ever displayed. Keys are decrypted only at call time, in memory, for the duration of a single request. Every AI run is written to an AIRun audit record. Agent activity is scoped to one organization and bounded by a budget. Self-hosted, your data never leaves your infrastructure.

How a call flows

The lifecycle of a single AI call is deliberately short and observable. Nothing about it is hidden from the org that owns the deployment.

Decrypt at call time
When an AI feature runs, the stored key is decrypted in memory using the per-deployment KEK. It exists in cleartext only for the duration of that request. It is never cached to disk and never written back anywhere in plaintext.
Call your provider directly
The request goes straight to your OpenAI or Anthropic endpoint. Elliptic does not proxy your prompt through a shared service or a vendor-owned model. The traffic is between your deployment and the provider you configured.
Record the run
When the response returns, the result and the token usage are written to an AIRun audit record. That record captures what ran, on whose behalf, and what it cost in tokens. You get a durable, queryable history of every AI action taken in your workspace.

Because the result and token counts land in an AIRun, the audit trail is not an afterthought attached to a black box. It is the natural output of the call path. Every prompt the assistant or an agent issues leaves a record you can inspect, attribute, and reconcile against your provider bill.

Agents and budgets

The reason BYOK and auditing matter so much in Elliptic is that agents do real work. They are members of the workspace, not a chatbot in a sidebar. Through the built-in MCP server, with about 144 tools mounted at /api/v1/mcp, an agent can create tasks, move them across statuses, comment, schedule, and close work. When something can act unattended, the controls around it have to be real.

Scoped to one organization. Every row in Elliptic carries an org_id, and there are no global list endpoints. An agent operating in one org cannot read or touch another org's data. The isolation is enforced at the data layer, which is what makes it safe to let an agent run on its own.
Spend caps. An agent can be given a budget. Once it reaches the cap, it stops. Because every call lands in an AIRun with token usage, the budget is measured against actual recorded spend, not an estimate.
Sandboxed runner. Agent execution happens in a sandboxed runner, so an agent's reach is bounded by the tools and scope you grant it, not by whatever it can reason its way into.

Put together, an agent in Elliptic runs on your key, inside one org, under a budget, in a sandbox, with every action it takes written to an audit record. That is the difference between an agent you can deploy and a demo you have to babysit.

Self-hosting

All of this assumes the platform itself is yours to run, and it is. Elliptic is open source under Apache-2.0. The backend is FastAPI with async SQLAlchemy and Postgres in a single container, the web app is Next.js, and the whole thing comes up with one docker compose. Your data, your keys, and your AIRun history live on your infrastructure and do not leave it.

bash

git clone https://github.com/woosal1337/elliptic.git
cd elliptic
cp .env.example .env
docker compose up --build

Then open http://localhost:3000 for the app. The API runs on http://localhost:8000. Set your OpenAI or Anthropic key in the workspace, and every AI feature, assistant and agents, runs on that key from that moment on.

A clean test

Configure your provider key, run one assistant prompt, then check your provider dashboard and the AIRun history side by side. The token usage should match. That reconciliation is the whole point. Nothing happens that you cannot see, and nothing runs on a key that is not yours.

Run AI on your own terms

AI in a work platform should run on your model key and your infrastructure, with a record of everything it does. Not on a vendor key. Not through a pipeline you cannot inspect. Elliptic is built that way from the storage layer up, and it is open source so you can verify the claim rather than take it. Read the code at github.com/woosal1337/elliptic and the full documentation at docs.elliptic.sh, then bring your own key.

Run Elliptic yourself

It is open source and self-hostable. Bring your own model keys, and your data never leaves your own infrastructure.

GitHub Docs