> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.
# How the investigation agent is governed
> What the Investigate agent is allowed to do: read-only tools, checks before every tool call, organization scoping, approvals, prompt-injection handling, limits per run, and what the audit log records.
The agent behind **AI Assistant → Investigate** decides, one step at a time,
which tool to call next. This page describes the rules it runs under — what it
can reach, what stops it, and what is recorded — so you can decide how far to
rely on it.
**The short version.** The model's only influence is *which registered tool
to call, with which arguments*. Every registered tool is read-only. Your
organization is taken from your signed-in session and cannot be chosen by the
model or by a request. Each run has fixed limits on steps, tool calls, time,
tokens and estimated cost.
For what the Investigate page shows, see
[AI Assistant and Investigate](/guides/ai/assistant).
## Every registered tool is read-only
The agent can only call tools from a fixed registry, chosen before the run
starts. They read telemetry and configuration your organization already has —
service health and dependencies, logs, metrics, traces, SLOs and error budgets,
alerts and incidents, recent deployments and changes, infrastructure health,
and past incidents and runbooks from your knowledge base.
**Every registered tool is read-only**, and that is enforced by a test in the
product's build: registering a tool in any other class fails it. The agent
cannot restart, roll back, scale, delete or change anything in your systems or
in aiAxonIQ.
The **Tools offered** panel on each investigation lists exactly which tools
that run was allowed to use.
## What every tool call passes
Before a tool runs, the request the model made goes through these checks, in
order. A refusal at any step is returned to the model as a failed call with the
reason, so it can correct itself rather than guess.
The name must match a registered tool exactly. There is no near-match
fallback, and a name is never treated as a URL, a statement or a command.
Checked against the role of the person who started the run, **recorded
when the run started**. A run that pauses and resumes later is bound by
what it was allowed when it began.
Arguments are checked against the tool's declared schema. An argument the
tool does not declare is **refused, not ignored**. Some names are refused
whatever the tool declares: an organization or tenant identifier, SQL, a
table name or a database name.
The call must fit the run's remaining limits, including the limit on
repeating the same call with the same arguments.
Only for a tool that declares it needs one. No registered tool does today.
## Scoped to your organization
* **The organization comes from your session.** It is recorded on the run when
you start it and passed to every tool by the product — never as an argument
the model writes. An argument naming a tenant, organization or account is
refused outright.
* **The tools write their own queries.** A tool does not accept SQL. It builds
its query from typed arguments, with your organization's filter bound into
it, and clamps the time window to your organization's retention.
* **Starting, reading and acting on a run requires a signed-in person.** Other
credential types — license keys, service credentials — are refused by the
investigation routes.
* **Investigations started automatically** — one per incident an alert opens —
take the organization from the incident record and are authorised as a
**Viewer**. They cannot ask a question or wait for an approval, because
nobody is there to answer.
* **A run in another organization does not exist for you.** Opening one
returns the same "not available" answer as an id that never existed, so the
response reveals nothing about which ids exist.
## Tool classes and approvals
The runtime defines three tool classes:
| Class | Policy |
| :---------------- | :---------------------------------------------------------------------------------------------------------------- |
| `READ_ONLY` | Runs without approval. **Every registered tool is in this class.** |
| `SAFE_WRITE` | Needs a person's approval for the exact call, and a run started by someone below **Editor** cannot use it at all. |
| `DANGEROUS_WRITE` | Refused. No approval can authorise it today. |
Because no write tool is registered, the approval flow below is not reachable
in practice today. It is described so you know how it behaves when one is.
**Who may approve.** A signed-in person in the same organization with the
**Editor**, **Admin** or **Owner** role, checked at the moment they decide — not
the role of whoever started the run. **Auditor** cannot approve: it is a read
role, not a rung on the ladder. A run cannot approve its own action, and a
read-only support-access session cannot approve. See
[Roles and permissions](/concepts/roles).
**What is approved is the call, not a summary of it.** The **Approval
required** panel shows the tool and its full arguments, verbatim. To approve,
you type the tool's name, and you can add a note that is recorded with the
decision. The approval is bound to those exact arguments: if the pending call
changes, the approval no longer applies. If two people decide at once, the
first decision recorded wins; a rejection cannot be turned into an approval by
a second click.
**Approvals require the evidence ledger.** An approval is recorded as a
signed entry in the evidence ledger *before* it takes effect, and the call
runs only if that entry is found and verified. On a deployment where the
ledger is not enabled, **approving is refused** with *Approvals need the
evidence ledger, and this deployment does not record them.* Rejecting still
works — it is the safe direction — but is then not recorded in the ledger.
Whether the ledger is enabled depends on your deployment. It is off unless an
operator turns it on (see [Configuring AI providers](/guides/ai/configuration#governance-settings)).
## Prompt injection
Telemetry is written by whoever can reach your error paths, so a log line can
contain text such as *"ignore your instructions"*. The product treats every
value a tool returns as data, and its defence has two layers.
**Mitigations — these reduce the chance a model is misled:**
* Your question, the conversation so far, tool results and evidence are placed
in labelled data sections of the prompt, separate from the instructions.
* Before a prompt leaves for the model provider, values that the product's
capture policy classifies as credentials are redacted from it.
* Suspicious text is not deleted from the evidence. Removing it would destroy
evidence about the incident itself, and would teach an attacker which
phrasings get filtered.
**The boundary — these hold even if the model is misled:**
* The model can only name a registered, read-only tool, with arguments that
pass the schema.
* The organization is never something the model can influence. A sentence in a
log asking to read another organization's data fails on the organization
scope, not on the prompt.
* **An answer cannot cite evidence no tool produced.** Each piece of evidence
gets an identifier derived from its own content. A claim citing an identifier
the tools never returned is dropped and counted, and the page says how many
claims did not survive validation.
* **Confidence is computed from the evidence, not stated by the model.** There
is no field in which a model could supply one.
**The model's reasoning is never streamed to your browser.** The run's event
stream has no field for it. What a step shows is the tool call the runtime is
about to make — because raw reasoning is where a model repeats back whatever
it was given, including a secret that happened to be in a log line.
## Limits on every run
Each investigation runs under fixed ceilings, recorded on the run when it
starts. Reaching any of them ends the run; the answer then says so and shows
what had been concluded by then.
| Limit | Default |
| :---------------------------------------------- | :----------------------------------------------- |
| Steps | 12 |
| Tool calls (weighted by each tool's cost class) | 24 |
| Time | 300 seconds |
| Tokens, prompt and completion together | 150,000 |
| Model input for one step | 64,000 tokens |
| Estimated model cost | 2,000,000 micro-units of the currency (US\$2.00) |
| The same tool with the same arguments | 2 calls |
| Consecutive failed tool calls | 3 |
| Size of the working context | 400,000 bytes |
A request can lower these limits and can never raise them. The last permitted
step is told it must answer, so a normal run concludes inside its budget. A run
that stops early — at a limit, on a failure or when cancelled — ends with a
list of what the evidence it had already collected established, assembled
without another model call.
**Cost is estimated, never billed.** It is computed from token counts and a
versioned model price table. A model the table does not know is priced at the
table's most expensive rate, so a new model cannot outspend the ceiling while
appearing cheap.
**Across runs**, starting investigations is limited to **20 per minute per
organization**, and there is a cap on how many of your organization's
investigations run at once, with a deployment-wide queue limit behind it. A
refused start says which limit applied and when to retry.
## What is recorded
**In your audit log.** The actions a person takes on a run are written to the
same audit event stream the [Audit log](/guides/audit) reads, whether or not the
evidence ledger is enabled:
| Action | When |
| :-------------------------------------------- | :------------------------------------ |
| `agent.run.started` | An investigation started |
| `agent.run.denied` | A start was refused at a limit |
| `agent.run.cancelled` | A run was stopped |
| `agent.run.resumed` | A stalled run was resumed |
| `agent.run.replied` | Someone answered the agent's question |
| `agent.tool.approved` / `agent.tool.rejected` | A decision on a parked tool call |
| `agent.tool.decision_failed` | An approval attempt that was refused |
Each entry carries who (from the signed-in session, with their role), the run
and its conversation, the tool and decision where there is one, the note
entered with a decision, and the outcome.
**Deliberately not in the audit log:** the text of your question, because it is
often customer data and audit entries are exported; and the individual tool
calls the agent makes, because the agent — not a person — makes them.
**Where tool calls are recorded.** Every tool call, its status and its result
are kept on the run itself and shown on its Investigate page. Where the
evidence ledger is enabled, each tool call also has an intent recorded
*before* it runs and an outcome after, and a failure to record either stops the
run.
## Limitations
* **Approval policy is per tool, not per organization.** You cannot require
approval for every tool, or for none.
* **Limits are fixed defaults.** Per-organization daily spend budgets are not
enforced today.
* **Prompt-injection handling reduces risk; it does not remove it.** What makes
a misled model harmless here is that its tools are read-only, scoped to your
organization, and its answers are checked against evidence.
* **The investigations you read are validated for citations, not for reasoning
quality.** A model can still draw a wrong conclusion from real evidence.
## Next
What each page does and what it shows.
For operators: providers, the ledger and the private AI service.
Filter to agent actions and export them.