Agent Trust & Assurance

This is the operations manual for the whole Agent Trust & Assurance stack. It is the single place an administrator comes to understand why the assurance capabilities exist, what each one is, and how to operate them together as one process — Grounding, Guardrails, Evaluation, Observability/Ops, the Ontology and its Governance, the Trust Membrane, Agent Authority, and Data-Product Governance.

This document is self-contained in its Why, What, and How. You can read it end to end and fully understand the mission, every capability, and how to operate the whole process — without opening anything else. The architecture documents linked throughout are optional deeper reading on internals (data models, code seams); they are never required to understand what a capability is, why it exists, or how to run it. If you administer a production Uderia deployment, this is your runbook.

Version: last updated 18 July 2026. This manual tracks a fast-moving platform; verify capability status against the linked architecture and roadmap documents for anything time-sensitive.

Part 1 — WHY: the mission

1.1 The trust problem

An LLM agent is powerful and, by default, untrustworthy for enterprise use. Left ungoverned it will:

• Hallucinate — answer confidently from parametric memory instead of your data.
• Drift out of scope — reach for data it was never meant to touch. (Uderia's own documented failure mode: an agent received a complete, scope-correct 21 KB knowledge enrichment, ignored it, brute-forced 19 calls across unrelated databases, and produced a confident, wrong 230-day answer.)
• Act with borrowed authority — a scheduled task or a sub-agent runs as you, with your full permissions, unattributed.
• Consume unvalidated ingredients — ground on a knowledge graph, skill, or pack nobody checked, shared from who-knows-where.
• Leak or absorb harm — leak personal data, or be steered by a hidden instruction buried in a document.
• Degrade silently — quality erodes turn over turn with nothing measuring it.

Enterprises cannot deploy what they cannot trust. Every one of these is a trust failure, not a security failure — the platform can be perfectly secure and still produce a confidently wrong, out-of-scope, unattributable answer.

1.2 The mission

Make agents trusted. Turn an AI agent from an opaque generator into a grounded, guarded, measured, attributable, and verifiable participant in the enterprise — without sacrificing the openness that makes the platform useful.

Trust is not one feature. It is a stack of independent, composable layers, each closing one failure mode, each safe to run on its own, and each strongest when run together.

1.3 The two pillars — and where this manual sits

Uderia separates two concerns that are often conflated:

Security keeps the doors locked. Assurance makes the thing inside the doors trustworthy. Both map onto external frameworks (EU AI Act, NIST AI RMF, GDPR) — see §5.

1.4 The design principles (why the stack behaves the way it does)

Every capability in this manual was built to the same principles. Knowing them tells you how the whole system will behave under your hand:

1. Safe by default. Every capability ships off, or observe-only. A fresh deployment behaves exactly like an ungoverned one until you turn something on. You are never surprised; you opt into rigor deliberately.
2. Show, don't block (for sharing). Trust is visible and verifiable, and by default it informs rather than blocks. Sharing stays open; enforcement is a choice you make.
3. When in doubt, refuse (for enforcement). Where a capability does enforce (grounding, guardrails, agent-identity limits), any internal error denies — it never quietly permits.
4. Applies to every kind of agent. Assurance works the same for all five kinds of agent (Ideate, Focus, Optimize, Coordinate, Conversation) — not just the tool-using ones.
5. Trust ≠ access. A checked thing is not an authorised one. Signing proves an agent and its parts are intact and unchanged; it grants no permissions. Authority is a separate concern (Agent Authority).
6. Defence in layers. No single control is the whole answer. A turn passes through several independent checks; each catches what the others miss.
7. Honest about limits. Where a capability is the attainable form of a larger goal, this manual says so plainly (e.g. Agent Authority limits what an agent can do today; limiting what data it can see is the OBDA future — of which the observable governed-data lane (§2.10) is already live, while structural data-slice grounding remains the future part).

Part 2 — WHAT: the assurance stack

2.0 The trust lifecycle of a single turn

The capabilities are not a menu — they are a pipeline. One agent turn passes through them in order, and that ordering is the assurance process:

                    ┌─────────────────────── one agent turn ───────────────────────┐
  user / trigger →  │ ① INBOUND GUARDRAIL  → ② IDENTITY (who is acting, scope set)   │
                    │        → ③ GROUNDING trusted-scope stamped                     │
                    │        → engine runs: every tool call ④ IDENTITY-ENFORCED       │
                    │        → answer drafted                                         │
                    │        → ⑤ OUTBOUND GUARD (personal data/toxicity) → ⑥ GROUNDING │
                    │        → ⑦ EVAL scores the turn → ⑧ PROVENANCE sealed (signed)  │  → answer
                    └───────────────────────────────────────────────────────────────┘
        everything grounds on ⓪ THE ONTOLOGY;  the agent + its ingredients carry a ⑨ TRUST BADGE;
        the whole flow is watched in ⑩ OBSERVABILITY (Agents / Sessions lenses)

Each numbered stage is a capability below. Read Part 2 to know what each is; read Part 3 to know how to operate them.

2.1 ⓪ The Ontology — the knowledge foundation

Everything trustworthy an agent says is anchored to a knowledge model of your business — the ontology. It captures both the business view (the entities that matter and their attributes) and how that maps to the real data (the tables and columns behind them), plus business concepts, metrics, and domain terms.

• Why it matters for trust: the ontology is the boundary grounding holds the agent to, and its concepts are what the agent should reason over instead of guessing. No ontology → nothing for grounding to check against.
• The Platform Ontology ("Ontology" view) is the whole-deployment map, centred on your agents — showing agents, their memory, sessions, knowledge, components, and configuration — so you can see what grounds what.
• Deeper reading (internals, optional): ONTOLOGY_ARCHITECTURE.md · PLATFORM_ONTOLOGY_ARCHITECTURE.md · KG_INSPECTOR_ARCHITECTURE.md

2.2 ③⑥ Grounding — anti-hallucination, enforced

Grounding checks every answer against the knowledge the agent was actually given, and can pass · annotate · block confident-but-wrong drift. It closes the failure mode in §1.1.

• What "declared scope" is: the specific data the agent's knowledge model says it is allowed to draw on — for example, the sales databases and their tables. An answer that reaches for anything outside that (a different database, an invented table) is drift.
• Process (how it runs): a quick check flags any answer that references data outside the declared scope; a second opinion then confirms whether it is genuine drift — an honest "that isn't in my scope" refusal is allowed through, a confident answer built on out-of-scope data is caught. If the second opinion can't run, the turn is only flagged, never wrongly withheld.
• Modes (set per agent): observe (measure only, changes nothing) · annotate (deliver the answer with a note) · review (withhold exactly as enforce, but park the original for the owner's disposition — human oversight, nothing lost) · enforce (withhold a confirmed out-of-scope answer).
• Proof it works: a published test showed it went from catching none of the drift to catching all of it, with no false alarms — out-of-scope answers reaching users dropped to zero.
• Deeper reading (internals, optional): AGENT_OPS_EVAL_ARCHITECTURE.md §6a/§6b · TIER_1.1_GROUNDING_GATE.md · TIER_1.4_BENCHMARK.md

2.3 ①⑤ Guardrails — protection on both edges

Fast, free protection at both ends of the conversation (it adds no cost — no extra model call):

• Incoming — catches a hidden instruction planted in a request or document trying to hijack the agent. When enforcing, that request is refused before the agent ever reads it.
• Outgoing — catches personal data (email addresses, national ID numbers, card numbers, phone numbers, access keys, bank account numbers, IP addresses) and toxic content. When enforcing, personal data is masked and toxic answers are withheld.
• Process (how it runs): the incoming request is screened before the agent sees it, and the drafted answer is screened before it's delivered; either way a note records what was caught.
• Privacy promise: the note names the category found — never the actual value.
• Modes: observe · annotate · review (enforce with retention — the original is parked in the Assurance Inbox for the owner's disposition) · enforce. The outgoing mode (personal data, toxic content) and the incoming mode (prompt-injection: observe / annotate / enforce — refuse before the model ever reads it) are both chosen per agent on its Guardrails card, under the overall guardrails switch.
• Deeper reading (internals, optional): TIER_1.3_GUARDRAILS.md

2.4 ②④ Agent Authority — the agent as a governed principal

When an agent acts on its own — a coordinator's expert, a scheduled task, a step in a flow, a call from another system — it takes on a limited identity derived from its owner: a strict subset of what the owner could do. Every attempted action is checked against that limit before it happens (and refused if it fails, safely), and every such action is recorded as done by the agent, not the person who owns it.

• Scope (set per profile): may it act unattended at all · read-only (no writes) · specific tools it may never use · which connectors it may reach · a spending cap per run. A scope can only ever remove authority, never add — an agent is always a subset of its owner.
• Process (how it runs): the moment an agent starts an unattended run it takes on this limited identity; every time it tries to use a tool, that attempt is checked against the limit before it happens, and refused if it's outside scope. The refusal is recorded, and the whole run is attributed to the agent rather than the owner.
• Honest scope: this limits what the agent can do. Limiting what data it can see ("cannot query outside its slice of the business model") is the next step — see the OBDA vision.
• Deeper reading (internals, optional): AGENT_AUTHORITY_ARCHITECTURE.md

2.5 ⑦ Evaluation — measuring every turn

Every turn is measured, for all five kinds of agent (not just the tool-using ones):

• Automatic scoring (free, always on): a suite of quick, rule-based checks grades each turn on cost, speed, tool success, whether it stayed in scope, how much work it took, whether it ended cleanly, how much of its data came from a governed data product (vs the agent free-forming its own query), and more. Each is banded Healthy / Review / Danger.
• Independent judging (optional, sampled): for the open-ended questions rules can't answer ("is this answer actually supported by the data?"), a panel of independent models judges the turn. Kept to a sample so it stays cheap.
• Process (how it runs): the instant a turn finishes it is scored automatically, off to the side so it never slows the answer; a fraction of turns is also judged. The result is recorded against that exact turn so it can be reviewed later.
• The Quality card appears on every turn (live and on reload), grouped into plain sections (Core · Resource · Tasks · Tools · Knowledge · Planning · Coordination · Quality). A turn might read speed 3.2 s (green), tool-success 100 % (green), stayed-in-scope: 3 out-of-scope calls (red), work 5 steps (amber) — each banded, so a degraded turn is legible at a glance. Nothing here alters the answer; evaluation measures, it does not gate.
• Deeper reading (internals, optional): AGENT_OPS_EVAL_ARCHITECTURE.md

2.6 ⑩ Observability & Ops — the two lenses

Assurance you can watch. Two views onto the same tamper-evident record of what happened:

• Sessions ("Session Performance") — the per-conversation view: cost, speed, the full trajectory of a past turn, and its Quality card.
• Agents ("Agent Performance") — the per-agent view: a colour-coded health roster (each agent's pass-rate, cost, speed, failing checks), a history of its runs, coordination trees for multi-agent work, and side-by-side comparison. Admins can switch between my agents and the whole system.
• Process (how it runs): every turn is sealed into a tamper-evident record as it completes; both views — and the quality scores and trust checks — read from that same unforgeable record, so what you see is what actually happened.

2.7 ⑨ The Trust Membrane — verifiable trust for agents & artefacts

A tamper-evident signed badge on every agent and every shareable thing, on one principle: an agent is trusted exactly when everything it is built from is — its knowledge model and every skill, extension, and repository it uses must each be signed.

• Three states: ⚪ unsigned · 🟢 trusted (signed and unchanged) · 🟠 changed (signed, but the content has since moved — so trust is honestly withdrawn until re-signed).
• Compositional: the consumer reads one badge — on the agent — and the whole catalogue of parts hides behind it. Signing an agent is a single act that vouches for its whole make-up; if any part is unsigned, the agent can't be signed and you're shown exactly which part is blocking.
• Verifiable by anyone, even offline, with nothing but the signer's public identity; trust ≠ access (a signed thing is checked, not authorised); badge, not gate — nothing is ever blocked from being shared.

Every kind of thing that can be exposed — what gets signed, and what "trusted" means for it. Anything that can be shared (published to the marketplace) or built into an agent can be signed. There are ten kinds, and sign-off runs the right check for that kind — so "trusted" is transparent and means something specific each time (a signed skill was screened for hidden instructions; a signed extension had its code inspected for unsafe actions; a signed knowledge model was checked for validity). This table is the whole surface — nothing exposable is left uncovered:

Kinds 1–8 are individual things (signed on their own content); kinds 9–10 are bundles (signed only when all their parts are). Every check returns a plain verdict — clean (ready to sign), caveat (sign, with a note), or blocked (fix it first) — so sign-off is never a rubber stamp: it tells you exactly what, if anything, is wrong. A shared copy shows 🟢 only if it is an exact, unmodified copy of what was signed — which is why trust survives the marketplace: publish it, and whoever installs, subscribes to, or forks it sees the same honest badge.

• Deeper reading (internals, optional): TRUST_MEMBRANE_ARCHITECTURE.md · the full validator-per-class reference: TIER_5.2_VALIDATORS.md

2.8 Governance of products — ontology, packs, metrics

Trust's governance face — turning knowledge assets into governed data products with a release lifecycle:

• Ontology governance: a draft → propose → approve → release → retire lifecycle for the knowledge model, gated by a validity check — a thing can't be a governed ontology unless it's a valid one. Releasing fixes a version and signs a verifiable record of it.
• Agent-pack governance: the same lifecycle for a bundled agent (a "pack"), plus a service tier; you can require that a pack be trusted before it's published, so a distributed data product is always a governed one. Retiring a pack archives its conversations and stops new copies.
• Governed metrics: a business metric is defined once in the ontology and consumed by both the AI and business-intelligence tools from that one definition; each answer shows whether the metric comes from a governed, trusted ontology.
• Deeper reading (internals, optional): PACK_GOVERNANCE_ARCHITECTURE.md

2.9 Operational trust — consumption & cost

An agent you cannot bound is not operationally trustworthy. Per-user consumption limits (requests per hour, usage per month, configuration changes) and consumption tiers (Free / Pro / Enterprise / Unlimited) stop runaway cost; when a limit is reached, the request is refused rather than quietly allowed. Configured under Administration → App Config → Security. (Full detail lives with the platform-security pillar — noted here so the assurance stack is complete.)

2.10 Every trust process at a glance

Every trust-related process in one view — what value it delivers, how the process runs in plain terms, where you operate it, and how you see it working. Nothing in the stack is a black box.

2.11 The closed trust loop — how the new layers compose

The stack above no longer just measures and reports — it closes the loop:

1. Every turn renders its Trust Journey (the §2.0 pipeline as a live strip in the turn's trace) and offers the consumer an answer receipt.
2. Every agent's measured conduct feeds its behavioral trust state; the seal (integrity) and the ring (conduct) are one glyph on the roster.
3. Exhausting the trust budget trips the circuit breaker — alerting, and optionally freezing autonomy, instead of waiting for a human to notice.
4. Before tightening any policy, the backtest replays it over sealed history so enforcement decisions are made on evidence.
5. The two firewalls (memory, retrieval) close the indirect-injection paths the edge guardrails cannot see; trust-aware routing makes compositional trust operative at coordination time, not just visible on a badge.

Nothing in this loop weakens the founding principles: everything ships off or observe-only, every enforcement fails closed, every action is attributable and visible, and computing any of it costs zero tokens.

Part 3 — HOW: operating the assurance process

This is the runbook. It assumes an admin-tier account.

3.1 The operating posture — a maturity ladder

Do not switch everything to enforce on day one. The stack is designed for a graduated rollout: observe → measure → tighten. Every capability starts safe (baseline), so you climb the ladder deliberately.

You can stop at any rung; each is stable. Most production deployments live at stage 3–4.

3.2 The control map — where every switch lives

Persistence note: the Agent Evaluation & Grounding card has its own Save button; its settings (eval, grounding master, guardrails master, thresholds) persist across restart. Per-profile cards save with the profile.

3.3 Runbook — standing up assurance on a new deployment

1. Turn on measurement. Config → Operations → Agent Evaluation & Grounding → enable online eval → Save. Leave judges sampled (or off to start). Nothing changes for users; you now have data.
2. Set grounding + guardrails to observe (switches on; the grounding and outgoing-guardrail modes at observe). Run real traffic for a few days.
3. Read the Agents roster. Left nav → Agents. Look for red/amber health, out-of-scope drift, personal-data exposure, cost outliers. This tells you which agents need enforcement.
4. Curate the ontology for the profiles that need grounding. Build/refine the KG; run the validity check; fix issues.
5. Tighten. Move the data-touching / externally-answering profiles to grounding enforce and guardrails enforce. Leave exploratory profiles at observe.
6. Attest. Sign your production agents (§3.5). Optionally enable Ontology/Pack governance approval.
7. Constrain autonomy. For any profile used by a scheduler, genie coordinator, or flow, set an Agent Authority scope (§3.8).
8. Establish a monitoring cadence (§3.9).

3.4 How the layers compose on one turn (defense in depth)

Understanding the ordering tells you what catches what, so you know which control to reach for when something slips through:

1. Inbound guardrail — a prompt-injection is refused before the model sees it.
2. Agent Authority — if autonomous, the principal + scope are set for this turn.
3. Grounding trusted-scope — the profile's bound-ontology scope is stamped onto the turn.
4. Tool calls — each MCP/component/connector call is identity-enforced (denied if out of scope).
5. Outgoing guard — personal data masked, toxic answers withheld.
6. Grounding gate — a confident out-of-scope answer is annotated or withheld.
7. Eval — the turn is scored; drift/cost/quality banded.
8. Provenance — the whole turn is sealed into the signed chain; the agent's trust badge reflects its (unchanged) composition.

A hallucination that slips past grounding may still be caught by evaluation; a personal-data leak the model generates is caught outbound; an injection is stopped inbound. No single layer is load-bearing.

3.5 Workflow — signing an agent (bottom-up trust)

1. Open the agent — its shield shows ⚪ unsigned and what is blocking it (unsigned parts).
2. Sign each blocking part from its own badge (the knowledge model, the skills, …). The screen walks you through it — "to sign this agent, these parts need signing first."
3. Sign the agent — its badge turns 🟢. That one act vouches for the whole make-up.
4. If any part later changes, the badge honestly flips 🟠; re-sign to re-affirm.
5. Anyone can verify the badge is genuine — including offline, on hand-off.

3.6 Workflow — governing an ontology (validity → release)

1. Open the ontology's Govern dialog. Read its validity report: valid / partial / invalid, with the specific issues listed.
2. Fix what's invalid (the report is specific). A partial ontology can still be released, with a noted caveat.
3. Walk it through the lifecycle: draft → propose → approve → release. Releasing fixes a version and signs a verifiable record of it. If approval is required, the approver must be authorised and (by policy) not the owner.
4. Retire it when it's no longer current — a recorded, auditable act.

Honest note: "release" here means marking this version as the official one, which is a different act from sharing it on the marketplace. Today, releasing does not yet change which knowledge the agents actually use — they use the live model. Making release govern what agents ground on is a planned next step.

3.7 Workflow — governing an agent pack / data product

Open the pack's Govern dialog: a lifecycle stepper, a trust hero (affirms or nudges you to sign off), one primary CTA (the recommended next action), instant SLA pills, an activity timeline. Enable require-approval / require-trust in the admin Agent Pack Governance policy to enforce that a published pack is approved and trusted. Deprecation archives the pack's sessions and blocks new forks.

3.8 Workflow — scoping an agent that acts on its own

For any agent used unattended (scheduled tasks, a coordinator's experts, flow steps, calls from other systems):

1. Profile editor → Agent Authority card.
2. Decide the limits: keep it read-only? bar it from specific tools? restrict which connectors it may reach? cap its spend per run? Or switch off unattended use entirely.
3. Save. From then on, unattended runs act under those limits; the owner's own interactive use is unaffected.
4. Confirm in the audit trail: unattended actions show as done by the agent, and any blocked attempt is recorded.

3.9 Monitoring & triage

3.10 Recommended production posture (checklist)

• ☑ Online eval on; judges sampled (raise the rate for high-stakes deployments).
• ☑ Grounding enforce on every profile that answers from data or answers externally; observe on exploratory profiles.
• ☑ Guardrails on: enforce the outgoing mode on every externally-facing agent; incoming protection on via the overall switch.
• ☑ Production ontologies conformant and released; production agents signed (🟢).
• ☑ Every autonomously-used profile carries an Agent Authority scope (least privilege).
• ☑ Agent Pack Governance requires approval + trust for published packs (if you distribute).
• ☑ A weekly cadence on the Agents roster; triage any profile trending amber/red.

Part 4 — the capability & control reference

Part 5 — compliance mapping

Agent Trust & Assurance is how a Uderia deployment evidences AI-governance obligations:

• EU AI Act / NIST AI RMF — grounding (accuracy), guardrails (safety/robustness), evaluation (measurement/monitoring), provenance (traceability), agent identity (accountability), governance lifecycle (risk management).
• GDPR — personal-data detection and masking on the way out (categories only, never the raw value); consumption and data-product governance; the ability to erase what an agent remembers.
• The tamper-evident record of every turn, plus the signed quality and trust verdicts, give an auditor evidence they can verify independently — even offline.

Related documents

• Architecture (internals): AGENT_OPS_EVAL_ARCHITECTURE.md · TRUST_MEMBRANE_ARCHITECTURE.md · AGENT_AUTHORITY_ARCHITECTURE.md · ONTOLOGY_ARCHITECTURE.md · PLATFORM_ONTOLOGY_ARCHITECTURE.md · PACK_GOVERNANCE_ARCHITECTURE.md
• Roadmap / tier docs: TIER_1.1 · TIER_1.3 · TIER_1.4 · TIER_4.2 · TIER_4.3 · TIER_5.2 Trust Membrane · LEAPFROG_ROADMAP
• The future: OBDA_VISION — where grounding and identity become structural.
• The other pillar: SECURITY_ARCHITECTURE.md