What's new

Elitea ships frequent, small releases. This page summarizes the most recent user-visible changes; it is not a full changelog.

One page layout on the web and the desktop

Every page now has the same layout in the browser and in the desktop app. The title bar shows a breadcrumb, for example Toolkits › New toolkit; select the section to go back to its list. Pages no longer show a second, large title or a back arrow. Under it, one toolbar has the page’s tabs or a count on the left, and on the right the search box, Filters, the card/table switch, secondary actions such as Import, and the primary + New button (for example + New agent or + New credential). The search text is kept in the page address, and / goes to it. Tags, type filters and the author card are now in the Filters tab of the side panel on the right, instead of a column over the page: in the desktop app it is an inspector tab, and the web app has a new side panel with the same tabs, which also holds the chat’s Conversation participants. The web sidebar now has the structure of the desktop sidebar: the project switcher, your chats and the platform sections, with a + on each section to create an item of that kind. It replaces the split + Chat create button. The desktop app now has the notification bell in its sidebar, and shows a system notification when a notification arrives while the window is not in focus; turn the system notifications off with Show system notifications under Settings › Notifications. See Page layout. The web sidebar now ends with the account menu of the desktop app: select your name to reach Settings, Credentials, the Catalog, help, Appearance, Language and Sign out, and to see the app and server versions (select the line to copy it). Administrators also get Admin portal, in the browser and in the desktop app. The admin console has the same menu, with Back to Elitea, and no theme switch of its own: it follows the theme you choose in the app. See Account menu.

Grounding indicators

An agent can now cite its sources. In the agent editor, open Advanced and select Require citations. The worker numbers each tool result of the current turn, and the model cites the results as [1], [2]. Under the answer, the chat shows N of M sources cited and K statements without a citation. Click the second part to see those statements. The message keeps the indicator as meta.grounding, and each run records a grounding_check step without the answer text. There is still no confidence score: a cited source does not prove the statement. An answer without tool results has no indicator. Upgrade every worker before you turn on citations. See Grounding indicators.

Clearer egress refusals and an OIDC relink command

Test connection now names the host that the egress allowlist refused, and tells where to add it: first a governance entry under Admin › LLM Governance (type Egress allowlist), then the GATEWAY_EGRESS_ALLOWLIST floor of the LLM gateway. The machine-readable reason (egress_not_allowed) does not change. A toolkit check names the refused host and ELITEA_TOOLKIT_CHECK_ALLOWLIST, with one message for every refusal; the elitea-main log gives the reason and says whether an allowlist entry can help. A refused listing of a provider’s models names the refused host too. Vertex AI needs its regional host, for example europe-west4-aiplatform.googleapis.com. See When the egress allowlist refuses a provider.

When an identity provider re-creates a user, the user’s OIDC sub changes and the login is refused with 409. The new operator command elitea-main oidc-relink moves the account to the new subject, or clears the old link so that the next login links again by email. It prints a plan first, refuses ambiguous cases and SCIM-provisioned accounts (use --clear for those), and writes a security audit event with no subject in it. The 409 now names its cause: only the re-created-subject case points to the command, and a SCIM account points to the provider’s adopt_scim_users setting. See When an OIDC login answers 409. The authentication page also states the OIDC sign-in rules: "email_verified": false is always refused, whatever OIDC_REQUIRE_EMAIL_VERIFIED says. See Relink an account.

Simpler Helm values for a production install

One value now fills the public URL everywhere. Set global.publicUrl and the chart fills DEPLOYMENT_URL, the OIDC redirect URI, the authentication document’s public_origin, the gateway’s self origins, the worker’s base URL and SPIFFE ID and the Ingress host, where you have not set them. global.trustedProxyCidrs fills both trusted-proxy lists. certManager.issuers names the two mTLS issuers once for every component, and certManager.issuers.create: true makes the chart create them, namespaced, over your existing runtime CA. The chart refuses a values file that still holds a <...> placeholder, and lists each path. Components export traces to the bundled collector by default, or turn export off when there is none. Every container requests at least 50m CPU, the GKE Autopilot minimum. deploy/scripts/mint-secrets.sh mints every generated secret as one flat JSON object for a secret manager. values-gke.yaml uses all of this; read “Release-wide settings” in docs/UPGRADING.md before you upgrade an install made from it. See Configuration and Deploy on GKE with Argo CD.

Content guardrails at the LLM gateway

A new governance entry type, Content guardrail, checks model content at the LLM gateway. An entry runs on the request before the provider call (input) or on the answer (output), for a platform, project, model or agent scope. Its detectors find bounded RE2 patterns and terms, the platform secret rules (for example AWS keys, GitHub tokens and private keys), or the findings of a classifier that you operate, through a documented HTTP adapter contract. Each detector blocks, masks or flags. A blocked request gets HTTP 400 guardrail_blocked; a blocked stream ends with a typed error event. A streamed mask holds back a short window of text, so that the client never gets a matched value, also when the value is split across chunks. Each check is recorded as a verdict without the matched text, and the run steps API returns the verdicts of a run. Nothing changes until you create an entry. See Guardrail pipeline.

Output contracts

Agents and pipeline LLM nodes can now have an output contract: a JSON Schema, a regular expression, or a named format (json, markdown or csv). Set it under Advanced › Output contract in the agent editor, or in the settings of an LLM node. The worker sends a JSON Schema to providers that support a response schema, and validates each final answer. If an answer is not valid, the model gets one more try with the validation error. If the second answer is also not valid, the run stops with OUTPUT_CONTRACT_VIOLATION, and a pipeline does not run the next node. A save with a contract that is not correct fails with OUTPUT_CONTRACT_INVALID. Each check is a run step record. Upgrade every worker before you save a contract. The platform does not give a confidence score; the same page tells why, and how to get a confidence field from the agent. See Output contracts.

AI disclosure, platform preamble and untrusted content

Outbound tools now add an AI disclosure marker to the text that they send outside the platform: Jira, GitHub, GitLab, Bitbucket, Azure DevOps and Aha! comments, GitHub, GitLab, Bitbucket and Azure DevOps pull request descriptions, new GitHub and Jira issues, new Azure DevOps work items, Confluence pages, Salesforce cases, Figma file comments, Slack messages and Gmail messages. The default text is Generated with Elitea AI, and Markdown targets also get the run id in a hidden comment. Administrators set the text under Configuration › AI Disclosure, and a project can change it in its AI disclosure project setting, but it cannot remove it. Every tool result now reaches the model in an <untrusted> envelope, and a short built-in preamble tells the model that this text is data, never an instruction. Administrators can add their own Platform preamble, which goes before every agent’s system prompt; each change is a revision with an audit event, and each turn keeps the revision that it started with. At the high and critical tiers, a delete, external_send or payment call after a tool result in the same turn asks for an approval (approval_rule source untrusted_read_then_act). See Content controls.

Agent circuit breaker

A new routine checks every agent once a minute. An agent is stopped when more than 50 % of its latest 20 runs failed, or when one tool failed 5 times in a row in one run. Limits for spend per hour and runs per hour are also available, but they are off by default. The stop is a kill-switch suspension: new runs are refused, runs in flight are cancelled, and the agent stays stopped until a person resumes it. A platform administrator must resume a high-tier agent, and two different platform administrators must resume a critical-tier agent. The agent’s owners and the project admins get a notification, the security audit log gets an agent.breaker event, and Admin › Kill switch shows the rule and the observed value. When many agents fail at the same time (more than 5), the breaker stops none of them and raises an alert, because a shared dependency is the likely cause. Set the limits per risk tier under Configuration › Circuit Breaker; an agent’s registry record can only make them tighter. The Helm chart adds Prometheus alerts for breaker trips and active suspensions; a platform stop is critical. See Agent circuit breaker.

Throttles per agent and per user

A Rate limit entry under LLM Governance can now name agents (scope.agent_ids) or users (scope.user_ids). Each named agent or user then gets its own per-minute counter at the LLM gateway, in addition to the project rate limit. When the counter is full, the gateway refuses the call with 429 and Retry-After; the agent and the user are not suspended. Like the project rate limits, throttles fail open when the shared counter is not available. The toolkit reference pages now also show the category of each tool, generated from the tool category contract. See Throttles per agent and per user.

Run caps per risk tier

Every agent run now has caps on its tool calls, model turns, spend and records read, set for each risk tier under Configuration › Run Caps, next to the existing maximum run time. A run now stops after 200 toolkit or MCP tool calls by default. The other caps are off until you set them. Agent authors can lower a cap for one agent in meta.run_caps; a save that raises one is refused with RUN_CAP_ABOVE_TIER. A run that reaches a cap ends with CAP_REACHED and a message that names the cap. A user with the new safety.override_cap permission (project admins and platform administrators) can let the conversation’s next run pass that cap once; each override is a security audit event. Save the per-tier caps after every worker runs this release. See Run caps.

Approval ledger and unattended runs

Every pause and every decision of a sensitive tool or a pipeline review node is now a row in an append-only approval ledger, with the actor, the tool, the toolkit, the digest of the arguments and the decision. Each row is also a hash-chained agent.approval event in the security audit log, for every run. When two people decide the same step at the same time, one decision applies and the other gets HTTP 409. Runs that a schedule or a trigger started never approve a step. By default (fail), such a run now ends with approval_required_unattended when it gets to a step that needs approval. Set on_approval_required on a schedule or a trigger to skip (the model is told that the step was skipped) or notify_and_wait (the owner is notified and the run waits, 24 hours by default). The platform default is under Configuration › Approvals. See Approval evidence and unattended runs.

Approval policy by risk tier and tool category

Every built-in tool now has a category: read, write, delete, external_send, payment or code_execution. Under Configuration › Approval Policy, administrators select for each risk tier the categories whose tools pause for a human approval. The default asks for delete, external_send and payment tools at the high and critical tiers. The policy adds to the sensitive action tools, and agent authors cannot remove an approval. Each pause names the rule that caused it (approval_rule). The same section can require a hitl node before every external_send or payment tool node in pipelines at selected tiers; a pipeline that breaks the rule does not start (PIPELINE_HITL_REQUIRED). The policy applies after the section is saved; save it after every worker runs this release. See Tool categories and approval policy.

Nested pauses

A HITL node can now pause a pipeline that an agent or another pipeline calls, with a maximum of 3 delegations above the node. Each pause shows one approval card with the path of its callers. After you approve or reject, the paused pipeline continues one time, and then each caller continues. When you reject, the caller reads the result of the Reject route. An attached pipeline that can pause in a position that the worker cannot resume is no longer offered to the agent. Before, such a pipeline failed when it paused. The worker log names the pipeline and the pause kind. See HITL nodes in nested agents and pipelines.

Delegation narrowing

When an agent calls a saved agent or pipeline, a pipeline node runs one, or an agent starts a sub-agent, the delegated agent now runs with only the toolkits, tools, credentials, data classes and egress hosts that its caller also holds. A delegation that needs more is refused with DELEGATION_GRANT_MISSING, which names the missing grant. The model reads the refusal, and the run does not fail. Configuration › Delegation sets the maximum delegation depth (default 4) and a report mode that records missing grants without refusing them. Save it after every worker runs this release; data class narrowing starts when it is saved. Each delegation step records its depth and a digest of its grants. Compositions deeper than 4, and callees that hold toolkits their callers do not hold, are refused after the upgrade. See Delegation narrowing.

Signed assertions for remote agents

An agent’s calls to a remote MCP server can now carry a short-lived signed assertion of which agent, run and user called, and with which toolkits (header Elitea-Agent-Assertion). The receiver verifies it against this deployment’s published keys. Nothing is sent by default: administrators choose allowlist (named servers only) or on under Configuration › Remote Agents; governed runs always send one. The platform’s MCP endpoint accepts these assertions from the issuers that an administrator lists under Configuration › Remote Agents, refuses replays and expired assertions, and limits every agent and tool that the caller calls to the caller’s toolkits. In the governed profile, an agent invoked through MCP needs an OAuth token or a verified assertion; a personal access token alone is refused. A2A is not supported. See Remote agents.

Connector approval, credential inventory and permission trimming

A new catalogue mode, approved_only, makes toolkit types and MCP servers usable only after a connector request is approved by someone other than the requester; approval grants the type and adds its hosts to the egress allowlist, and a custom MCP server’s tools are pinned. The default stays open, and the governed profile forces approved_only. Admin › Credential inventory lists every credential an agent can use with its last use, and flags credentials unused for 90 days (revoking stale tokens is opt-in). The Permission trimming report compares what each agent is granted with what it used, for one-click audited removal, and notifies owners weekly. See Least privilege and trust.

Entitlement export for access reviews

Administrators can download who holds which role on the platform, on each project and on each agent, with what each role allows (configure agents, approve change requests, attest, approve connectors and more), as CSV from the admin console’s Users page. Identity governance tools can read the same data over a read-only SCIM tree at /api/v2/scim/v2/entitlements; no SCIM client can read it until an administrator lists it under Configuration › Entitlement Export. Every export is audited. See Least privilege and trust.

Enterprise controls documentation

A new Enterprise controls section lists every agent-risk control the platform provides. For each control it says whether the control is available, partial or planned, where to configure it, what evidence it produces and what stays with your organisation’s own systems. The section also includes a shared responsibility page, an evidence guide for auditors and a hardening checklist.

Run step records and chained audit trail

Every agent run now keeps a step record of each model call, tool call, retrieval (with the documents it returned and their scores), approval, delegation, cap, error and its answer, in order and tied to the agent release. The records are hash-chained per run, anchored in the security audit log, exported to your SIEM as the run_steps stream, and readable over the API with the new runs.evidence.read permission. Step content is kept by reference under the new step_content retention class, and a toolkit’s evidence_fields setting limits what is kept of its results. The admin audit trail is now hash-chained too, with a verification endpoint. Both new retention classes keep forever by default, and no existing data is deleted. See Audit evidence and retention and Reconstruct an agent run.

Agent registry, change requests and release gate

Every agent now has a registry record with its owners, risk tier and certification state. Above the low tier, publishing needs a change request approved by someone other than the author, after the agent’s evaluation gate passes. Agents that existed before this release start at tier medium, so publishing them now needs one approval; agents in personal projects and new agents start at low and publish as before. Certifications come due on a cadence and lapse if they are not renewed. Reviews done outside the platform are recorded as attestations. See Agent lifecycle.

Agent releases and rollback

Publishing an agent now records an immutable release, and every save of a version records who changed what. Open Release history from the agent’s ⋮ menu to see each release, what changed, and to roll back to an earlier release in one step. Published versions can no longer be changed in place. See Agent lifecycle.

Session policy and run time cap

Platform administrators can set a maximum idle timeout and a maximum lifetime for browser sessions, and a maximum time for one agent run. Every session start, expiry, sign-out and revocation is now an audit event. Stopping a toolkit type with the kill switch now also cancels the runs in progress that use it. All new limits are off until you set them. See Session policy and Runtime safety.

Worker egress allowlist

Platform administrators can limit the public hosts that agents, toolkits and MCP servers reach from the worker. Configuration › Worker Egress shows the hosts that runs reached in the last 30 days and copies them as an allowlist. In allowlist mode, a run may reach only those entries, its project’s entries and the hosts of its own toolkits; any other host is a tool error that names the host. The default stays open. See Least privilege and trust.

A stop of an agent’s answer before it writes anything no longer deletes the question on a conversation under legal hold.

Kill switch

Administrators can stop one agent, one toolkit type, one project or the whole platform at once. Stopping an agent, a project or the platform cancels the runs already in progress. Nothing starts again until someone with authority resumes it, and every stop and resume is recorded in the audit trail. See Runtime safety and the emergency stop runbook.

Audit export to your SIEM

Audit evidence can be sent to your SIEM over OpenTelemetry logs, or to a signed webhook, in one versioned schema. Export is off until an operator configures it. See Audit event schema.

Data retention and legal hold

Platform administrators can now set how long conversations, gateway request logs and audit records are kept, and place a legal hold on a project, an agent or a user. The defaults keep today’s behaviour, so an upgrade deletes nothing new. A conversation under a legal hold cannot be deleted, not even by its owner.

Deployments now sign people in through OIDC or SAML, with SCIM provisioning. The local username/password sign-in is off unless an operator turns it on, and every local user now needs a real e-mail address — none is invented from the login any more.

Client deployment readiness

You can now configure a fresh deployment entirely from the UI — set the first global administrators, create a project, and add an AI provider — without running SQL by hand.

Platform parity wave

A broad pass closed gaps across several areas at once: issue triage fixes, the toolkit catalogue, the support assistant bot, Inventory, and wiki source connections all received fixes and completions.

Post-release fixes

Follow-up fixes landed for session handling, admin 403 errors, invite links, the maintenance splash screen, voice configuration, artifact bucket access-control lists, and the admin Tasks page. The secrets vault also gained write locking, so concurrent edits to the same secret no longer overwrite each other silently.