From AI Governance to Continuous Assurance: Engineering Compliance Evidence for Agentic Systems

Policies and annual reviews describe intended control. Agentic systems need a second layer: evidence that the relevant control was enforced for the release, identity, action, and outcome that actually occurred.

Traditional governance artifacts answer important questions: who owns the use case, which policy applies, what risk tier was assigned, which controls were designed, and who approved deployment. Agentic systems add a harder question: did the relevant control operate when this release, acting under this identity and context, attempted this action?

The answer cannot come from a policy document alone. It also cannot come from a large pile of traces. Assurance requires a chain of claims connecting the obligation to a control objective, an enforcement point, preserved evidence, and a test that can distinguish pass, failure, exception, and unknown.

This is the practical meaning of continuous assurance. It does not mean every legal judgment is automated or every event is inspected in real time. It means assurance is maintained as the system changes, using evidence close enough to execution to detect when a previously valid claim no longer holds.

Start with an assurance claim, not a dashboard

Figure 1 shows the minimum chain. An obligation is translated into a system property; a named component enforces that property; records demonstrate what decision it made; and a test evaluates the records against explicit criteria. If any link is missing, a dashboard can show activity without proving that the intended control applied.

Consider the requirement “a human must approve high-value refunds.” It is too vague to test. A control objective might say: before a refund above a defined threshold is submitted, an eligible reviewer must approve the normalized operation once; the approval expires after fifteen minutes or after a material change to customer, order, amount, currency, or destination; the payment system must still authorize and commit the refund.

Now the enforcement points are identifiable. The application classifies value and material fields. A gateway or runtime holds the tool call. The identity system determines reviewer eligibility. The commerce platform applies refund policy and commits the effect. The evidence includes policy version, requester and agent, normalized operation digest, approval, timestamps, operation identifier, tool result, and reconciled refund record.

The assurance test can report more than pass or fail. “Unknown” is critical: missing correlation, suppressed evidence, clock skew, or an unobserved bypass should not be counted as success. Exceptions should name who accepted them, why, for which scope, and until when. This turns control design into an operational contract.

Separate control design from control operation

Design evidence shows that a control exists: architecture, configuration, policy, review record, test plan, and owner. Operating evidence shows that the control applied to relevant executions. Both matter. A perfectly configured gateway does not cover traffic that bypasses it. A runtime event does not prove the deployed policy was the reviewed version. A downstream transaction may prove an outcome without explaining which agent or approval produced it.

Build a coverage model. Enumerate in-scope agents, environments, model routes, MCP servers, direct API paths, credentials, and systems of record. For each control, identify its enforcement population and the evidence population. Then test for gaps between expected and observed traffic. Continuous assurance that ignores bypass paths can become continuous false confidence.

Control owners should define frequency by risk and evidence latency. Some claims can be evaluated on every request: an identity was present, a tool was allowed, a guardrail ran, an approval existed. Others require periodic sampling or batch joins: outcomes were reconciled, retention executed, access remained appropriate, or a population-level fairness metric stayed within an approved range. “Continuous” describes maintained linkage and timely detection, not necessarily millisecond evaluation of every obligation.

Build a layered evidence model

Figure 2 divides evidence into configuration, runtime, and outcome layers. Configuration explains what was intended and effective at the time. Runtime explains what the agent and control plane observed. Outcome evidence explains what authoritative systems committed and whom it affected. Correlation identifiers, effective-time records, and synchronized clocks join the layers; none can substitute for the others. Where evidence integrity matters, export, access control, retention, and tamper-evidence must be designed explicitly rather than inferred from the existence of a trace.

Configuration evidence includes agent and workflow release, model eligibility, prompt and skill revisions, tool schemas, identity grants, approval policies, guardrail policies, logging rules, and environment. Effective-time semantics matter. An auditor investigating an August run needs the policy and permissions that applied then, not the settings visible today.

Runtime evidence includes session and turn identifiers, actor and subject, selected model, token and latency metadata, tool intent, normalized arguments or protected digest, authorization and guardrail results, approval status, retry and cancellation events, and completion state. It should distinguish proposed, attempted, acknowledged, denied, and failed. A model message saying it will issue a refund is not a tool attempt; a tool response is not necessarily a committed refund.

Outcome evidence lives in authoritative systems: the refund transaction, changed access grant, sent notification, created support case, deployed artifact, or customer-impact record. Reconciliation joins the operation identifier to that state. This layer is essential for effectiveness testing because a control can operate exactly as designed while the business outcome still fails—or an unobserved path can produce an outcome without expected runtime evidence.

Minimize evidence without destroying verifiability

Compliance programs often respond to uncertainty by retaining everything. For agentic systems, that can create a second risk: prompts, tool payloads, retrieved documents, and model responses may contain personal data, credentials, privileged communications, source code, or regulated records. Evidence design should begin with the claim and retain the minimum fields needed to test it.

Use structured metadata for identity, release, model, tool, policy, decision, and correlation. Store normalized field digests when reviewers need to prove that an approval matched an action without retaining the full payload in the central trace. Keep sensitive bodies only where the purpose requires them, with redaction, strict access, retention, and deletion. Maintain mappings to the authoritative record rather than copying every business object into the AI observability store.

TrueFoundry’s documented logging configuration is a useful example of the distinction. Rules determine whether request and response bodies are stored and which sensitive patterns are redacted in the stored copy. Cost, token, latency, and metadata remain recorded. That can support privacy-aware evidence design, but the organization still chooses lawful purpose, retention, access, localization, and whether predefined or custom patterns are sufficient for its data.

Do not turn telemetry into a compliance verdict

Traces are an evidence substrate. They are not an evaluator, a control test, or a legal conclusion. An assurance service needs explicit logic over those records: population definition, expected events, allowed sequences, timing, exceptions, outcome joins, and handling for missing data.

For behavioral controls, use offline regression sets and trajectory checks against versioned releases. For operating controls, evaluate production events and outcomes. For statistical obligations, define denominators, cohorts, confidence, materiality, and escalation. A single “compliance score” tends to hide which claim failed and whether the evidence was absent or adverse.

Keep legal interpretation and technical test logic connected but separate. Counsel or compliance owners determine which obligations apply and approve the control objective. Engineering implements enforcement and evidence. Internal audit or assurance functions assess whether the design and operation support the claim. A gateway vendor should not declare the customer compliant merely because a feature is enabled.

Make assurance change-triggered

Figure 3 closes the loop. Release, model, tool, identity, policy, and regulatory changes can trigger targeted re-evaluation before or during rollout. Production behavior and reconciled outcomes can trigger containment or recertification afterward. A prior approval remains valid only while its assumptions, scope, and evidence remain valid.

Calendar reviews are still useful, but material events should not wait for them. A new tool changes authority. A model-route update can change behavior without changing application code. A skill revision can change procedure. An identity-provider mapping can change who receives access. A logging-policy change can remove evidence. A new regulatory interpretation can change the control objective even if the system is unchanged.

Classify changes by the claims they threaten. Prompt or model changes trigger behavioral and trajectory evaluation. Tool and sandbox changes add capability, dependency, and containment tests. Identity and policy changes trigger authorization and negative-access tests. Logging changes trigger evidence completeness and privacy tests. Downstream schema changes trigger reconciliation and postcondition tests.

Use staged rollout, narrow populations, monitoring, and rollback for material changes. Rollback is not always restoration: if an agent already committed external effects, the organization may need compensating action. Assurance should therefore include containment and recovery evidence, not just release promotion.

Map transparency obligations to architecture carefully

The European Commission stated that from August 2, 2026, specified interactive AI systems must inform people that they are interacting with AI, while certain AI-generated or manipulated content is subject to applicable labeling or machine-readable marking requirements. The exact obligation depends on role, system, content, exceptions, and implementing guidance. Engineering should translate the applicable legal conclusion into testable claims rather than copying a generic “AI disclosure enabled” checkbox across every workflow.

For an interactive agent, a testable claim might cover disclosure text, channel, timing, language, persistence across handoff, and evidence that it rendered. For generated content, the claim may cover which output classes require marking, where the mark is applied, whether transformations preserve it, and which exceptions apply. An agent runtime can record that it produced disclosure metadata; the delivery channel or content platform must prove that users actually received or retained it.

This illustrates the central pattern: obligations cross system boundaries. The model, gateway, runtime, application, user interface, and system of record each hold part of the evidence. Continuous assurance is the disciplined join, not a claim that one platform owns the law.

How TrueFoundry and TrueForge fit

An implementation can tag each request with use-case, environment, release, control set, and operation identifiers; route model and MCP traffic through the intended control planes; preserve TrueForge event sequences; and export the relevant metadata. A separate assurance process then evaluates expected controls, joins authoritative outcomes, and opens exceptions. This division keeps enforcement close to traffic while keeping compliance judgment explicit and reviewable.

Worked example: customer-support refunds

A customer-support agent can answer order questions and propose refunds. Refunds under a low threshold may execute automatically for eligible orders; larger or unusual refunds require human approval. The organization also needs an AI disclosure in the chat channel and must avoid retaining unnecessary payment or identity data in observability bodies.

The control set pins the agent, prompt, and skill release; defines eligible models and tools; requires the channel to render the disclosure before the first agent response; limits the refund tool by identity; and applies a one-time approval to high-value calls. Logging rules suppress or redact sensitive bodies while preserving identifiers and decision metadata. The commerce service independently evaluates refund eligibility and supports an idempotent operation identifier.

Runtime assurance tests every refund population for authenticated subject and agent, expected policy version, authorization result, required approval, operation identifier, and terminal event. A scheduled join compares successful tool calls with commerce transactions and flags both orphan tool successes and transactions with no governed runtime path. A channel-level test samples sessions to verify the disclosure actually rendered, not merely that the agent emitted disclosure metadata.

When the refund threshold changes, the approval-control test and affected scenarios rerun. When a model route changes, behavioral regression and trajectory tests rerun. When the chat client changes, disclosure rendering is recertified. When a correlation gap appears, the system reports “unknown,” opens an exception, and investigates rather than treating missing evidence as compliant behavior.

Build an audit packet that answers a claim

A useful audit packet is claim-oriented. It includes scope and population, obligation source, approved control objective, owners, architecture, relevant release and policy versions, enforcement points, evidence schema, test method, period results, exceptions, remediation, and known limitations. Samples link through correlation identifiers to protected underlying records where authorized.

It should also state what the evidence cannot establish. For example: gateway logs cover routed traffic but not direct vendor calls; runtime events record a tool response but the commerce ledger proves commitment; body suppression limits content reconstruction; fairness analysis is performed in a separate outcome dataset; legal applicability was determined by the organization, not by the platform.

This candor improves assurance. A narrowly supported claim is more defensible than an expansive dashboard label that obscures missing coverage.

Continuous assurance is maintained evidence, not continuous certainty

Agentic systems change too often, cross too many boundaries, and make too many runtime choices for periodic documentation to carry the entire governance burden. But the answer is not universal surveillance or automated legal judgment.

The better design is a maintained chain: applicable obligation, approved control objective, named enforcement point, privacy-aware evidence, explicit test, accountable exception, and authoritative outcome. TrueFoundry and TrueForge can provide important control and telemetry surfaces across models, tools, identities, approvals, and runtime state. Organizations still own coverage, business policy, evaluation, legal interpretation, and the final assurance conclusion.

That division of responsibility is not a limitation to hide. It is what makes the system auditable. Infrastructure should produce reliable, bounded evidence; assurance should say exactly what that evidence proves.

References

1. IBM — From AI governance to AI assurance: What we shared at Think 2026.
2. European Commission — Enforcement and transparency requirements from August 2, 2026.
3. European Commission — AI Act policy overview.
4. OWASP — Top 10 for Agentic Applications for 2026.
5. TrueFoundry — Logging Configuration.
6. TrueFoundry — MCP Gateway.
7. TrueFoundry — MCP Tool Approvals.
8. TrueFoundry — Agent Registry.
9. TrueForge — SDK Concepts.

Editorial disclosure. This article reflects TrueFoundry’s engineering interpretation of the cited public materials as of September 13, 2026. Product capabilities are scoped to the linked documentation. Examples are illustrative, not legal advice, an audit opinion, an independent benchmark, or a guarantee of compliance or security.

‍