Enterprise controls
This section is for security, risk and compliance reviewers, and for the operators who run Elitea for them. For each control, the table below states:
- what the platform does;
- whether it is Available, Partial (available with the stated limits) or Planned (with the tracking issue);
- where to configure it;
- what your organisation keeps.
We keep the table truthful. A control is listed as Available only once it has shipped in a release. A Partial row states what is missing.
Related pages:
- Shared responsibility — what Elitea deliberately leaves to your own systems, and how it integrates with them.
- Evidence guide for auditors — where each evidence stream lives and how to verify it.
- Hardening checklist — the settings a regulated deployment turns on.
- Content controls — AI disclosure, the platform preamble and untrusted content.
Identity, access and trust
Section titled “Identity, access and trust”| Control | What Elitea does | Status | Configure | Your organisation |
|---|---|---|---|---|
| Service and worker authentication | Every internal hop is gRPC over mutual TLS. Worker commands are signed, and each worker holds a workload identity. | Available | Helm install | Certificate authority policy |
| Agent identity and least privilege | With credential governance on, each agent runs under its own identity. Every credential use must pass independent checks: binding, an exact grant, operation scope, and delegation or mandate. With it off, agents use the invoking user’s credentials. | Partial (off by default) | Credential governance | Identity provider (Entra ID or Elitea-native assertions) |
| Credential use approval | Credential use grants need an approver who is not the proposer. This is enforced in code and in the database. | Partial (governed profile only) | Credential governance | Who may approve |
| Tool allow-list | Administrators allow, block or restrict toolkit types per project, and can block individual tools. Catalogue mode approved_only makes the catalogue default-deny: only approved connectors are usable. | Available | App requests and toolkit types, Connector approval | Which tools are approved |
| Connector approval | In approved_only mode, toolkit types and MCP servers require a request approved by someone other than the requester; approval grants the type and allowlists its hosts, and pins a custom MCP server’s tools. | Available | Connector approval | The architecture review behind an approval |
| Domain and egress allow-lists | Private, link-local and cloud-metadata addresses are always refused. Sandbox and code-runner traffic uses per-project host allow-lists. In allowlist mode, every outbound call of an agent’s tools is limited to the platform’s and the project’s entries and the hosts of the run’s own toolkits; governed runs always use it. Every run turn records the hosts reached and refused. | Available (off by default; governed runs always on) | Least privilege and trust | Which hosts are approved; network policy at your perimeter |
| Multi-agent delegation | A delegated agent, pipeline or sub-agent runs with only the toolkits, tools, credentials, data classes and egress hosts that its caller also holds; a missing grant is refused by name. An administrator caps the delegation depth (default 4). Each delegation step records its depth and the digest of its grants. | Available (enforced by default; data class narrowing starts when Configuration › Delegation is saved, and data classes are declared metadata) | Delegation narrowing | Data class labels in the agent registry |
| Remote agent assertions | Calls to remote MCP servers can carry a signed delegation assertion (agent, run, user, scope; at most 5 minutes). The platform’s MCP endpoint accepts assertions only from allowlisted issuers, refuses replays and expired assertions, limits every agent and tool that the caller calls to the asserted scope, and in the governed profile refuses agent invocations that come with a personal access token alone. | Available (outbound off by default, allowlist or on to send; governed runs always send; no issuer trusted by default) | Remote agents | Which issuers to trust; A2A is not supported |
| User sessions | Browser sessions have an absolute expiry, an idle timeout and server-side revocation. Administrators set maximums for both, and every session start, expiry, sign-out and revocation is an audit event that can be joined to the runs the session started. | Available | Authentication | Your identity provider’s sign-in and MFA policy |
| User provisioning and roles | SSO (OIDC and SAML) and SCIM provisioning, with roles per project. | Available | Authentication, Users and roles | Joiner, mover and leaver processes |
| Access review evidence | Who holds which role on the platform, each project and each agent, and what it allows, as CSV or a read-only SCIM tree. | Available | Entitlement export | Review campaigns in your identity governance tool |
| Credential review | An inventory of every credential an agent can use, with owner, last use and the agents using it; stale credentials are flagged, and stale tokens and grants can be revoked automatically. | Available | Credential inventory | Rotation in your secret manager |
| Permission trimming | Granted tools, toolkits, credential grants and egress hosts compared with use in the run step records; unused grants are removed one by one, audited, and owners are notified weekly. | Available | Permission trimming | Acting on the report |
Runtime safety
Section titled “Runtime safety”| Control | What Elitea does | Status | Configure | Your organisation |
|---|---|---|---|---|
| Kill switch | Suspend one agent, one toolkit type, one project or the whole platform. Agent, project and platform stops cancel the runs already in flight, and nothing restarts until someone with authority resumes it. A daily self-test proves the switch works. | Partial: a toolkit-type stop refuses new runs and new tool calls, but runs already in flight keep the toolkit until they end (issue 1498) | Runtime safety, Emergency stop runbook | Who may stop and resume |
| Spend caps | Project budgets are hard ceilings: further model calls are refused once a budget is reached. | Available | Budgets and LLM governance | Budget amounts |
| Per-run caps | Caps per risk tier on a run’s tool calls (default 200), model turns, spend and records read, and a platform-wide cap on its whole duration. Authors can lower a cap for one agent, never raise it. A reached cap stops the run with CAP_REACHED; only safety.override_cap lets the next run pass it, once, with an audit event. | Available | Runtime safety | Thresholds |
| Throttles | Rate limits per project and model at the LLM gateway, and throttles per agent and per user. A throttle adds to the project limit and refuses with 429 and Retry-After; it never suspends. | Partial: throttles fail open when the shared counter or the agent lookup is not available | Runtime safety, Budgets and LLM governance | Thresholds; alert on fail-open |
| Circuit breaker | Every minute, a breaker checks each agent’s error rate over its latest runs, its spend and runs per hour, and the same tool failing again and again in one run. A rule that trips suspends the agent and cancels its runs in flight, and the agent stays stopped until a person resumes it: any admin at the low and medium tiers, a platform administrator at high, two platform administrators at critical. Limits are set per tier; an agent can only tighten them. Each trip is a hash-chained agent.breaker audit event, notifies the owners and project admins, and raises a Prometheus alert. | Available (on by default: error rate and tool failure rules; spend and runs per hour off) | Agent circuit breaker | Thresholds; paging and on-call routing of the alerts |
| Human approval of sensitive actions | Administrators list sensitive tools, and those tools always pause for approval. An approval policy by risk tier and tool category (read, write, delete, external_send, payment, code_execution) adds approvals: by default delete, external_send and payment tools pause at the high and critical tiers. Agent authors cannot remove an approval. Each pause names the rule that caused it. | Partial: the policy applies after Configuration › Approval Policy is saved; every decision in the audit trail is issue 1491 | Tool categories and approval policy, Sensitive action authorization | Which categories need approval at each tier, and the business thresholds |
| Approval evidence and unattended runs | Every pause and decision of a sensitive tool or review node is an append-only ledger row (actor, tool, toolkit, argument digest, decision), written in the decision’s transaction and mirrored as a hash-chained agent.approval audit event. Racing approvers get one winner. Runs started by a schedule or a trigger never approve: they fail, skip the step, or notify the owner and wait, by on_approval_required. | Available (unattended default fail) | Approval evidence and unattended runs | Which automated runs may skip or wait; who answers a waiting run |
| Staged execution | Pipelines split work into nodes, with human-in-the-loop and decision nodes between them. At the tiers an administrator selects, a pipeline with a path to an external_send or payment tool node that has no hitl node does not start. | Available (off by default) | Required approval in pipelines, Pipeline node reference | Which flows must be staged |
Lifecycle and change control
Section titled “Lifecycle and change control”| Control | What Elitea does | Status | Configure | Your organisation |
|---|---|---|---|---|
| Version control | Every publish creates an immutable release with its definition digest and toolkit pins; published versions are read-only; every draft save is a revision with its author and diff; runs record the release they executed. | Available | Agent lifecycle | — |
| Change control | Above the low tier, publishing needs an approved change request: one or two approvers who are not the author, some from the governance role, by risk tier. A database constraint refuses self-approval. The final approval publishes. | Available. Projects cannot set their own higher minimums. | Change requests and approvals | Your change-management policy; which people approve |
| Rollback | One step makes an earlier release current again, with the reason in the audit event. A release whose toolkits changed since it was published is refused rather than run with new settings. | Available | Roll back to an earlier release | Rollback criteria |
| Pre-release evaluation and regression testing | Gate suites run against every change request: thresholds per dimension, “no worse than the current release”, and a regression suite that names each case that used to pass. A failed gate blocks approval unless the governance role overrides it with a reason. Gate suites can re-run on a schedule. | Partial: evaluation runs test instructions and model in one call, without tools or toolkits | Evaluation gate | Test cases and pass criteria |
| Agent registry and recertification | Every agent has a record with owners, risk tier, intended use, data classes and certification state, listed across projects with CSV and JSON export. A certification comes due on a cadence per tier, on a new release, on toolkit drift and on a failed scheduled evaluation; when it lapses the agent is flagged or suspended. | Partial: no model-retirement signal (mark the agent due through the API) | Registry, Recertification | Risk classification; drift monitoring of production traffic |
| External reviews (architecture, legal, model risk, data owner) | Recorded as typed attestations with an expiry and an evidence link, required by risk tier before approval, and writable over the API by your GRC tool. | Available | Attestations | Performing the reviews |
Audit, evidence and data
Section titled “Audit, evidence and data”| Control | What Elitea does | Status | Configure | Your organisation |
|---|---|---|---|---|
| Administrative audit trail | State-changing and refused requests on admin and security routes are recorded and can be searched. | Available | Audit trail | — |
| Tamper-evident security audit | Identity, credential and governance decisions are written to an append-only, hash-chained log that you can verify. | Partial (governed profile events only) | Credential governance | — |
| Export to your SIEM | Audit evidence is sent in one versioned schema over OpenTelemetry logs or a signed webhook. | Available | Audit trail, Audit event schema | Immutable storage; correlation and alerting |
| Retention and legal hold | Administrators set a maximum age per data class, enforced by scheduled sweeps. A legal hold on a project, an agent or a user suspends deletion. | Available | Audit evidence and retention | Your records-retention schedule |
| Step logging and output audit trail | Every agent run records each model call, tool call, retrieval, approval, delegation, cap, error and its answer, in order, tied to the agent release. Records are hash-chained per run, anchored in the security audit log and exported. Content is kept by digest and reference under its own retention class, minimised per toolkit. The admin audit trail is hash-chained too. | Available | Audit evidence and retention, Reconstruct an agent run | The immutable (WORM) copy; who may read step content |
| Retrieval logging | Each search records the index, query, filters and every returned document with its score and rank. The answer’s step lists the retrieved sources it names. | Available | Run step records | Judging whether an answer was faithful to its sources |
| Monitoring | Prometheus metrics with alert rules for platform health and audit export, and a Grafana dashboard of runs, tool calls, errors and spend per agent. | Available | Operations | Alert routing; anomaly detection |
| LLM gateway | All model traffic from agents, DeepWiki and Inventory goes through the platform’s gateway, which handles model allow-lists, budgets, rate limits and per-request logs. | Available | LLM proxy | Approved models and providers |
Content
Section titled “Content”| Control | What Elitea does | Status | Configure | Your organisation |
|---|---|---|---|---|
| Content guardrails | The LLM gateway checks requests before the provider call and answers (streamed or not) with ordered detectors: bounded RE2 patterns and terms, the platform secret rules, an HTTP adapter to the classifier you operate, adapters for Azure AI Content Safety, AWS Bedrock Guardrails and Google Cloud Model Armor, and adapters for self-hosted Llama Guard and Presidio. A prompt-injection slot attaches a classifier to tool results. Each detector blocks, masks or flags; a streamed mask never sends the matched text. Every check is a verdict without content, joined to the run’s step records. | Available | Guardrail pipeline | Classifier choice and category taxonomy |
| Format enforcement | An output contract (JSON Schema, regular expression or named format) on an agent version or a pipeline LLM node. The worker sends a JSON Schema to providers that support it, validates the answer, retries one time with the error, and then stops the run with OUTPUT_CONTRACT_VIOLATION. A pipeline does not run the next node. Each check is a step record. | Available | Output contracts | The contract of each agent |
| AI disclosure | Chat shows agent output as AI output, with the agent’s name and version in the participant list. Outbound tools that write text outside the platform (comments, chat messages, emails, pull request and issue descriptions) add a disclosure marker, Generated with Elitea AI by default; Markdown targets also get the run id in a hidden comment. A project can change the text but not remove it; only a platform administrator can let projects opt out, per toolkit type. | Partial: only the tools in the disclosure contract add the marker; custom MCP tools and update tools that take a JSON document (for example Jira update_issue) do not | AI disclosure | Disclosure wording per jurisdiction |
| Platform preamble | An administrator’s instruction text goes before the system prompt of every agent, nested agent and pipeline LLM node. Agent authors cannot change or remove it. Each change is a revision with its author and a hash-chained config.changed audit event. | Partial: a change needs no second approver | Platform preamble | The preamble text |
| Untrusted content | Every tool result reaches the model in an <untrusted> envelope, and a built-in preamble tells the model that the envelope holds data, never instructions. After a turn reads a tool result, a delete, external_send or payment call in the same turn asks for an approval (on by default at the high and critical tiers). | Partial: the envelope and a prompt-injection classifier reduce indirect prompt injection but do not prevent it | Untrusted content | Risk tiers of agents; approvers |
| Confidence communication | Elitea does not attach model-reported confidence scores, because they are not calibrated. An agent with Require citations cites its tool results as [n], and the chat shows how many sources the answer cites and which statements have no citation. Agents can be given a required confidence field, which evaluation measures. | Available | Grounding indicators | Whether a use case needs a stated confidence |