Repository navigation
Public-sector auditability profile for verifiable AI agents #209
Description
Spec section affected
§3 Trust Record fields; §4 Verification / conformance guidance; potentially an informative annex for sector-specific profiles.
Problem
The current TRACE specification appears to focus on general evidence records for verifiable AI agent activity, but it does not yet define a public-sector auditability profile for agents used in procurement, public oversight, or administrative decision-support.
For public institutions, auditability requires more than a record that an agent acted. Auditors and oversight bodies may need evidence of:
agent identity;
delegated authority;
authorized tools;
data access;
human approval or override;
policy exceptions;
incident or escalation triggers;
retention requirements for later review.
Without a public-sector profile, different agencies or vendors may implement evidence records inconsistently, making later audit, accountability, and oversight harder.
Proposed change
Add an optional, non-breaking public-sector auditability profile to TRACE, either as an informative annex or sector-specific guidance.
Proposed normative/informative text:
Implementations MAY support a public-sector auditability profile for AI agents used in procurement, oversight, regulatory, or administrative decision-support contexts.
When this profile is used, Trust Records SHOULD include sufficient evidence to support later institutional review of:
the identity and version of the agent;
the public authority, delegation, or approval under which the agent acted;
the tools, systems, or external services accessed by the agent;
the categories of data accessed or processed;
any human approval, override, denial, or escalation;
any policy exception or rule violation;
incident, near-incident, or escalation triggers;
retention metadata necessary for audit or oversight review.
This profile SHOULD NOT require disclosure of protected, confidential, classified, or legally restricted information in the Trust Record itself. Where appropriate, the Trust Record MAY reference protected evidence through controlled-access identifiers, hashes, or other mechanisms that preserve verifiability without exposing sensitive content.
This profile is intended to support public accountability, auditability, and institutional oversight without changing the core TRACE wire format.
Backward compatibility
Non-breaking (new optional field, informative addition)
Breaking (removes or changes required field, changes wire format, changes algorithm set)
Motivation
Public institutions are increasingly exploring AI agents for procurement, auditing, regulatory, and administrative workflows. In these settings, accountability depends not only on technical performance, but also on whether later reviewers can verify who authorized the agent, what it did, what data and tools it used, whether a human approved or overrode the action, and whether exceptions or incidents were escalated.
A public-sector auditability profile would help agencies, vendors, auditors, and oversight bodies use TRACE in a more consistent way. It could also connect TRACE with adjacent AgenTrust work, especially Agent Manifest fields related to identity, delegated authority, tools, policies, provenance, and human approvals.
This proposal could connect to Agent Manifest fields, but I am opening it here because the main contribution would be a TRACE profile for public-sector auditability and evidence events.
My background is in public oversight and procurement accountability, not core infrastructure engineering. I am interested in whether this kind of governance-focused profile would be useful for the AgenTrust ecosystem.
Related issues or PRs
None yet.
Activity
lywinged commentedon Aug 24, 2026
You asked whether a governance-focused profile would be useful here. Yes, and not as an opinion.
Three people have opened governance-shaped requests against this repository in the last few
days, from three unrelated directions: human approval outcomes in #191, an external
transition-closure layer, and now public-sector auditability. All three need the same thing,
which is a way to bind a governance fact that lives outside the record to the record itself. The
demand is real and it is arriving faster than the profiles for it.
The other half of the answer is that most of your eight bullets already have a field. What
follows maps them onto what is in
mainat 4785fa7, so the proposal can aim at the gap ratherthan at the covered ground.
subject, andmodelcarryingprovider,model_id,version,weights_digest,aibom_uridelegation(parent_record_hash,credential_id) for machine-delegated authority; theauthorized-intentreference for a decision made before execution and held elsewheretool_transcript(hash,call_count,transcript_uri); the PIC/TRACE authorization bridge binds a signed pre-execution authorization to the executed calldata_classapproval-outcomeis a registeredrelin §3.1.2, defined as "an attributable human approval attached to a step-up or defer decision", but the lifecycle behind it is #191, which is held behind #116's version boundarypolicy(bundle_hash,enforcement_mode,version,policy_uri) records the regime; a per-decision exception record is not therereferences.retention, an ISO 8601 duration naming the period the resolver undertakes to keep the entry resolvableYour paragraph about referencing protected evidence through controlled-access identifiers and
hashes describes the
referencesblock as merged in #199. An entry isrel,id,resolver,plus optional
retentionanddigest, and the rule that makes it safe for exactly your case is§3.1.2 rule 3: "A verifier MUST NOT reject a record because an entry in
referencescannot beresolved, and MUST NOT treat a resolved reference as attested evidence." A record can point at
classified material held by an agency, name who is obliged to resolve it, commit to its digest,
and stay verifiable to a reviewer who will never be allowed to resolve it. That is the property
your motivation section asks for, and it is already normative. The same rule sets the limit, and
for an auditability profile the limit matters more than the capability: a reference says where a
fact is held and who is obliged to produce it, never that the fact is true. A record can commit
to the digest of an approval without that approval having happened. Anywhere your profile
expects a reviewer to conclude something occurred rather than to know where to go and ask, it
needs evidence carried in the record or a separately verified artifact, not a reference.
So the shape of the remaining work looks less like new fields and more like two things. First, a
curated packaging: which of the existing fields a public-sector record is expected to carry
together, and what a reviewer should conclude when one is absent. Second, and the part that
decides whether a profile is real, conformance vectors. A vector is a small worked example with
a verdict attached: this record satisfies the profile, this one does not, and here is the
sentence that decides it. They are what lets two agencies and their vendors reach the same
conclusion about the same record without talking to each other.
docs/conformance-method.mdandtests/test_adequacy_all_sets.pyset the bar a set of them has to clear here. A profile writtenonly as SHOULD statements leaves every agency to decide privately whether a record satisfies it,
which is the inconsistency your problem statement is trying to prevent.
Two things I am not deciding. The normative parts go through the spec change process in
CONTRIBUTING rather than being settled on a thread, and the approval and escalation half
overlaps #191, which @imran-siddique is routing internally and which sits behind #116 until the
version boundary is settled.
Worth saying plainly: the procurement and oversight side is the scarce input. If you can
describe what an auditor actually asks for, in what order, and what makes a record useless to
them, that is harder to obtain than any field definition and it is what a sector profile has to
be built from.
fernandacamiladecarli commentedon Aug 25, 2026
Thanks — this is extremely helpful. Your distinction between references and evidence, and especially between adding fields and defining a sector profile, clarifies the direction considerably.
I agree that the useful contribution may be less about extending TRACE and more about specifying which existing evidence an independent public-sector reviewer would need to see together, what absence should mean, and how conformance could be tested consistently.
I can contribute from the procurement and oversight side. In my work, the sequence is usually something like: identify the authority for the action, reconstruct what happened, determine what evidence supports it, identify who could intervene, and assess whether the record is sufficient to support or challenge the decision.
I’d be happy to sketch 2–3 public-sector audit scenarios and corresponding pass/fail conformance vectors if that would be useful.
imran-siddique commentedon Aug 26, 2026
Maintainer answer, and the short version is yes, in the form you have both already converged on.
@lywinged's mapping is the right one and I am not going to repeat it. Six of your eight bullets have fields today, the two that do not are the per-decision policy exception and the incident/escalation trigger, and both are the #191 lifecycle. Your reframing yesterday, from extending TRACE to specifying which existing evidence an independent reviewer needs, is exactly the right move.
Where it lands, and in what form
As a non-normative page under
docs/, not as spec text. We merged the template for this an hour ago: #215, a verification-outcome interpretation guide. Read it before you write, because it is the shape I want and it solves a problem you would otherwise hit.What makes that page work:
docs/verification.mdorLIMITATIONS.mdalready makes it true, and each row names its anchor. Anything you cannot anchor goes in an "Open questions" section rather than into the body.The limit is the contribution here
@lywinged pointed at §3.1.2 rule 3 and I want to underline it, because for your sector it is more valuable than any capability:
A record can name classified material, commit to its digest, name who is obliged to keep it resolvable and for how long, and remain fully verifiable to a reviewer who will never be permitted to resolve it. That is your motivation section's requirement, already normative, already merged.
The second half of that rule is the one your profile has to carry loudly: a reference says where a fact is, not that it is true. An oversight body reading a resolved reference as attested evidence is precisely the failure a public-sector profile exists to prevent, and it is the mistake an institution is most likely to make in good faith.
Scope
In: mapping the evidence an independent reviewer needs onto fields that exist, with anchors, and the non-claims for each.
references.retentiondeserves its own treatment, since it states an undertaking rather than an enforced guarantee and that distinction will matter in a procurement context.Out, for now: the per-decision policy exception record and incident/escalation triggers. Both wait on #191. Name them as open questions rather than proposing fields, and the page stays correct when that lands.
@lywinged, your observation that three governance-shaped requests arrived in a week from unrelated directions is the more consequential half of your comment, and I have not lost it.
imran-siddique commentedon Aug 26, 2026
Tracking issue opened: #226, holding the
relregistry as one question across #191, #209, #220 and the transition-closure thread.imran-siddique commentedon Sep 7, 2026
The accepted contribution is a non-normative public-sector reviewer guide using existing fields, anchored claims, and explicit non-claims. The proposed audit scenarios can proceed within that boundary; new exception/escalation fields remain outside it.