Safeguards and correctness
An agent must not give an unsupported claim. Two layers of safeguards hold it to that. Capability safeguards bound what an agent can touch: only its manifest's tools, only its own project, no shell, no files, fail-closed access control. Correctness safeguards bound what it can say: a scope, tools-only grounding, a verifier pass over every draft, a tool budget and a refusal text, all configuration on the manifest and enforced by the platform after the agent answers and before the person sees anything. Every guarded answer leaves a ledger record, and the agent test kind turns expected behaviour into scheduled tests.
Capability safeguards
These hold whatever the model does. The process model behind them is on Agents and MCP.
- The agent's child process receives an MCP configuration with one server and an opaque handle. The server resolves the handle to the fork and the manifest and registers exactly the manifest's tools. The runtime has no built-in tools; on the coding-agent runtime path several independent switches remove shell, file, web and command tools.
- Every tool call runs on the agent's own fork. Headers or arguments cannot redirect it.
- A pinned chat is a roster of one.
- One shared access rule serves every service that decides access and fails closed on an unknown project, a lapsed membership or a store error.
- Row and column data policies compile to a grant signed with a per-project secret; an unsigned or forged grant falls back to strict compilation.
- Every configuration change is a commit authored by the bearer's identity. A fleet job acting for a person carries that person's identity or is refused.
Correctness safeguards
The safeguards section of a manifest is the agent's correctness contract, edited on the Agents page and validated by one shared rule that the page, the runtime and the tests all use.
| Setting | Effect |
|---|---|
| Scope | What the agent may answer, in plain language. A request outside it is answered only with the refusal text. |
| Grounding | With grounding set to tools, every factual statement must come from a tool result of this run. An answer produced without a single successful tool call is refused. A clarifying question or an explicit "not found" carries no claim and passes. |
| Verify | A second, tool-less model pass reads the task, the scope, the tool evidence (every call with its input and result) and the draft, and returns a verdict with the unsupported claims. |
| On failure | Refuse (the default): the person sees the refusal text and the reason, never the unverified draft. Annotate: the draft is delivered under a visible warning listing the unsupported claims. |
| Refusal text | The text shown instead of a refused answer. |
| Tool budget | A hard cap on tool calls per run. Exceeding it ends the run as an error the orchestrator sees, never as a confident answer assembled from a runaway loop. |
| Disclosure | The agent is told to state what it could not verify instead of filling gaps (on by default). |
The three enforcement moments
Before the run, the safeguard section is appended to the agent's instructions. During the run, every tool call is recorded (name, status, input, result excerpt) as the evidence, and the tool budget is checked on each call. At the end of the turn, the platform evaluates grounding and budget from the run's own evidence, runs the verifier when asked, and delivers what the decision says. Until then the draft is only a draft.
The verifier
The verifier is the same headless agent runtime the agent ran in, started with no tools and the same model transport. It receives the task, the scope, the recorded tool evidence and the draft, and returns one structured verdict: pass, or fail with the list of unsupported claims. It sees nothing the agent did not see, so it cannot import outside knowledge to rescue a draft. A verifier that crashes or times out is recorded as "did not run" and never turns an answer into a refusal by accident; the answer is delivered as unverified and the ledger says so.
The chat badge
A guarded answer shows the verdict beside the agent's name: "checked: grounded, verified", "refused by safeguard" or "unverified", with the reason on hover. The orchestrator is told that a refusal is final and must not answer the question itself. An application that embeds the chat shows the same badge.
The ledger
Every guarded answer is a record in the platform database: the project, the agent, the person, the verdict, whether the person saw a refusal, the reason, the checks with their outcomes, the number of tool calls, the elapsed time, the task and the draft. The Agents page shows the latest records and a summary (guarded answers, passed, failed, refused) under Safeguards. The same records are available through the API (Integrations and API), so an auditor can read why any answer was refused.
Agent tests
An agent test names the agent and a prompt, and asserts on what came back: whether the answer was refused, how many tool calls were made, whether the answer contains a number or a phrase, and what the safeguard verdict was. Two typical tests for a data-quality assistant: "the open-exception count is answered from the tools" (not refused, at least one tool call, a number in the answer, verdict pass) and "a legal question outside the scope is refused".
The runner asks the agent through the assistant's evaluation surface, exactly as the chat would, for the person who ran the suite. Agent tests are linked to the requirement they prove like every other test. They run on demand and after each deploy, and on the scheduled watchdog when the environment opts in, since each test is one model run. A customer archive has no agents target and skips the kind. Tests assert the number, the refusal, the tool calls and the verdict, never exact prose. The format is on Tests and health.
Correctness elsewhere in the platform
- Requirement drafting, requirement derivation from documents, task planning, build previews, test writing and test review run as jobs with a schema contract. The answer is normalised against it and, where a rule is involved, re-validated and retried.
- A requirement's origin quote is re-found in the source text by the platform; a quote the text does not hold is marked unverified, never dropped. As-built requirements are read from the live implementation, never from a document about it (Requirements and knowledge).
- Model-enriched fields carry a confirmation flag until a person confirms them.
- A risky workflow path is routed to a human gate, and a failing run stays open for a person (Business workflows).
- A report whose query does not return every declared field is rejected before rendering.
- Agent-written tests are checked by a second session that can only read evidence, and a functional requirement on a project with a screen must have a browser test.
A team that adopts cortex writes an agent's contract as a handful of settings on a page. The engineering effort that remains is the endpoints that give the agent true data.