AI Agent Access

If you already work by describing changes to a coding agent rather than clicking through a console — the habit that picked up the name vibe coding — the console is the part of Demeterics your agent cannot reach. A Console API key fixes that: it is a credential your agent holds that can read and edit the parts of your account it needs, and structurally cannot do anything else.

What a Console API key is

A Demeterics account can hold two different kinds of key, and they are not interchangeable:

The separation is the security story. A Console key holds none of the scopes the LLM routes accept, so a leaked one cannot run up a bill; an LLM key holds none of the management scopes, so a leaked one cannot rewrite your prompts. Neither can reach another user's account or our staff admin tooling — that boundary is in the request-handling layer, not a setting.

Creating one

1. Go to API Keys and choose New API Key.
2. Pick the Agent access (manage my account) purpose. If you do not see that card, Console API keys are not yet enabled for your account — ask us and we will turn them on.
3. Tick only the permissions the agent actually needs. Reading prompt history (prompts:read) and listing agents (agents:read) are enough for most debugging work; add prompts:write only when you want the agent to restore or relabel versions.
4. Choose an expiry — 7, 30 or 90 days. There is no "never", by design.
5. Copy the key. It is shown once. We store only a hash of it, so if you lose it the fix is to regenerate, not to look it up.

Then put it in the project's .env, which must already be gitignored:

DEMETERICS_CONSOLE_API_KEY=dmc_...

You can have as many as you want

There is no limit on concurrent Console keys, and holding several is usually the better shape. A key that lives in CI and a key that lives on your laptop want different scopes and different lifetimes; giving each its own key means revoking one never interrupts the other, and the audit trail tells you which one did what. Widening an existing key to cover a second use is the thing to avoid.

Reading the prefixes

Console keys carry their own naming so you can tell one apart from an LLM key at a glance — in a .env file, in a log line, in a support thread:

• The secret starts dmc_ (the "c" is for Console).
• The key ID — the part in the /api-keys/… URL, safe to paste into a ticket — starts con_.

Keys created before 28 August 2026 read dmt_a_ and apk_ instead. Both spellings are valid indefinitely and there is nothing to migrate. An older key keeps working exactly as it did; regenerating one is what moves it to the new naming, and only because that mints a fresh secret anyway.

What your agent can do with it today

Every call goes to https://demeterics.com/api/v1/console/ with an Authorization: Bearer header, and every call is scoped to the account that created the key — there is no user or account parameter to pass, and none would reach a different account if there were.

A first call, to check the wiring:

curl -s https://demeterics.com/api/v1/console/whoami \
  -H "Authorization: Bearer $DEMETERICS_CONSOLE_API_KEY"

A request needing a permission the key was not granted comes back 403, so whoami is the first thing to check when something is refused unexpectedly. The exact request and response shapes for every endpoint are in DEMETERICS.md.

Letting an agent edit the prompt itself

prompts:read and prompts:write cover two related things: the live prompt your widget serves right now, and its version history. The live prompt is the one that matters when someone says “the widget is still saying the old thing” — and it is what was missing from the first release of this API, which could read history that, for every agent created before it, was empty.

An agent can now list an agent's named prompts, read one, edit it, add a new one, and remove one it added. default is the prompt served unless the widget picks another, and it cannot be deleted — only edited. Every write leaves a version behind, marked as coming from the Console API rather than from you in the browser, so the history list distinguishes your edits from your agent's and either can be rolled back.

One prompt an agent cannot edit: one you have linked to Google Drive. That prompt's text lives in your .dmt file and the widget reads it from there, so a write through the API would change a copy nobody serves. Rather than accept it silently — which is what used to happen, complete with a success response — the API answers 422 and names the Drive file. The status is deliberately not 403: nothing is wrong with the key's permissions, so an agent that reads the response correctly will tell you to edit the Drive document instead of going off to debug scopes.

Seeing what the calls did, and which keys made them

interactions:read lets an agent read your LLM call history: model, provider, application, status, tokens, latency and cost, filterable by any of those and by date, and searchable by text. It is the permission that turns “something is wrong with the widget” into a specific failing call.

It is the only LLM data permission a Console key may hold, and the reason is worth stating plainly: reading history spends nothing. Everything that could spend — making a call, ingesting one, running an evaluation — remains impossible on a Console key, and not because of a permission that could be granted later. A Console key is refused on every LLM route by kind, whatever it holds.

The results are metadata only. The text of the prompts and completions is not returned, though the search does look inside it — so an agent can find the call you mean and tell you where to look, without your conversations flowing through it.

llm_keys:read answers the neighbouring question: which LLM keys does this account have, which are BYOK versus managed, and which providers have a key configured on each. That is usually enough to explain why a call billed the way it did. No key value is ever returned — provider status is a yes/no, not a masked string — and there is no API to create, rotate or revoke an LLM key. Those stay in this console, on purpose.

Letting an agent maintain your knowledge base

The seven knowledge: permissions are what turn a Console key from “reads my prompts” into “keeps my documentation current.” An agent that has just changed something in a repository can write the corresponding page into your knowledge base in the same session, and the retrieval index updates itself — a write re-embeds the file it wrote, so there is nothing to run afterwards.

Reorganising is a first-class operation rather than a delete-and-rewrite. knowledge:move relocates a file and carries its place in the search index with it: the new path is indexed before the old one is removed, so the document is never briefly missing from search, and the old path's entries, its topic summary and the project index are all cleaned up afterwards. The response says which of those steps actually completed, so a partial result is visible rather than silent.

knowledge:metadata is the gentlest permission of the set. It edits a file's display name and tags and nothing else — no content, no re-embedding, no cost. The trade-off is stated rather than hidden: because tags are not embedded, they organise your library but do not influence what search returns. A term you want search to find has to be in the document.

knowledge:test answers the question you actually have when you wonder whether any of this is working: given a question, which of my documents match, and how strongly? It runs a real search over the index and reports matched files with their scores and line ranges, best first — so an agent can check that a page it just wrote is findable, or find the right document to open next.

Two guard rails are worth knowing about, because they are not configurable:

• Generated files stay generated. Topic summaries (any file whose name starts with _) and system/index.md are produced by the Knowledge Engine and are refused for write, delete, labelling, and as either end of a move. An agent maintains the source documents; the summaries follow.
• Rebuilding the index is its own permission. knowledge:vectorize re-embeds an entire project — minutes of work and real embedding cost — so it is separate from ordinary writes, which index themselves for free. Most keys should not have it.

These permissions ride on top of your account's Knowledge Engine access. If that is not enabled for you, the endpoints answer 403 whatever the key is granted, and the fix is account access rather than a new key.

What it deliberately cannot do

• No LLM calls. Every /groq, /openai, /anthropic, /google, /gemini and /chat path returns 403 for a Console key. It cannot spend credits, and it cannot be talked into spending them. This holds even for a key granted interactions:read: the confinement is by key kind, so no combination of permissions reaches an LLM.
• No billing, no vendor keys. It can neither read nor write the provider (BYOK) keys stored on your account, and it cannot touch billing. llm_keys:read reports that a provider key exists, never what it is, and no API can create, rotate or revoke a key.
• No other account, ever. Including ours — a Console key reaches no staff admin surface regardless of the owner's role.
• No permanent life. Expiry is mandatory and capped at 90 days. Calls that used to work and start returning 401 are usually an expired key, not a broken one.

Handling the key safely

• Keep it in .env, on your machine, gitignored. Demeterics never reads, writes, or syncs that file.
• Never paste a raw key into a commit, an issue, or a chat transcript. The con_… key ID is the safe thing to quote — it identifies the key without being the key.
• Revoke rather than reuse. A key you are no longer sure about costs nothing to replace, and revoking it does not disturb your other keys.

Create a Console API key Download DEMETERICS.md