The Agent Action Evidence Contract: What Every AI Action Must Record

TL;DR

The Agent Action Evidence Contract defines what a consequential AI action must record, which component is responsible for each fact, and what evidence is required before the workflow can call the action complete. It connects authenticated identity, delegated authority, approved intent, execution attempts, independently observed results, and recovery obligations.

Version 0.1 is a proposed DTD design contract, not an industry standard or a completed implementation. Its central requirement is that an agent’s explanation cannot substitute for an authorization record or independent confirmation of the result. Missing evidence must remain visible as uncertainty, with defined consequences for execution, reconciliation, and escalation.

An action is not complete because the agent wrote a convincing completion report.

Introduction

Consider a hypothetical access-management workflow. An agent requests a temporary deployment role for one service identity in one production project. Approval permits execution during a five-minute window and fixes the grant’s expiration at a specific time twenty minutes after the request.

The execution call times out. A separate observer then finds a matching grant in the identity system.

Did this attempt create it? Was it already present? Did another workflow create it concurrently? Can the system retry without creating another grant or extending the access period?

A report saying “failed” is premature. A report saying “verified” may be equally premature. The observed configuration answers one question, but the missing operation record leaves another unresolved.

Article 3 assessed the independence of assurance boundaries. This installment defines the records those boundaries must produce for each action. The example assumes a custom access service with supported expiry enforcement and an independently readable identity record; it does not assume that every identity platform provides native expiring role assignments.

The objective is practical: let an operator reconstruct the action without trusting the agent’s account of its own behavior.

Define the Contract Before Choosing the Logging Backend

The Agent Action Evidence Contract, version 0.1, specifies the evidence obligations around a bounded action: required records, trusted producers, binding rules, verification criteria, retention, and behavior when evidence is missing or contradictory.

This builds on established audit practice. NIST SP 800-53 Revision 5, control AU-3, describes audit-record content covering the event, timing, location, source, outcome, and associated identities. The proposed contract extends that foundation into delegated AI execution. NIST does not define this contract or its field names.

Three artifacts should remain separate:

The action profile defines what evidence an action class requires. Its owner decides, for example, which observations are sufficient to verify a temporary role assignment.

The action record collects the applicable intent, authority, attempts, observations, and outstanding obligations for one action.

The disposition states what those records currently support: denied, pending, verified for the declared checks, violated, or unresolved.

Existing DTD guidance on how to execute, verify, and roll back agent actions addresses the runtime. This contract addresses the evidence that allows another party to examine that runtime’s decisions and effects.

A suitable implementation needs authenticated identities, an execution boundary outside the model, durable record acceptance, and an observation path appropriate to the target system. Where a required capability is absent, narrow the permitted operating mode rather than filling the gap with an agent-generated assertion.

Make the Action Smaller Than the Agent Run

One agent run can contain retrieval, planning, several mutations, delegated work, and recovery. A single run identifier cannot adequately distinguish all those effects.

Assign an action identifier to each independently authorizable change or disclosure. Assign a separate attempt identifier whenever the executor attempts that same action. Preserve parent-child relationships for batches and delegated work.

A batch may share approval when the approval explicitly binds its members and constraints. It still needs per-target results where partial execution is possible. “Nine of ten completed” must identify which nine and what happened to the tenth.

Bind the action to stable resource identity, tenant, environment, operation, and normalized parameters. Preserve the normalization version and an immutable representation or digest of the approved proposal. A resource name alone is insufficient when names can be reused.

A material change to scope, target, or expiry creates a revised proposal requiring reassessment. Do not overwrite the original action so that its history appears consistent with a later decision.

Specify Who Supplies Each Part of the Record

An evidence contract needs more than mandatory field names. It must identify who is allowed to establish each fact.

The following groups form the proposed baseline. An action profile determines the exact fields and conditional requirements for its workflow.

A denied proposal should have denial evidence, not invented execution fields. A policy-authorized action without human review should explicitly identify that authorization mode and its governing rule. It should not fabricate an approver or use an unexplained empty field.

Similarly, distinguish “not applicable,” “not exposed by the provider,” “not collected,” and “collection failed.” Those conditions have different consequences. The acting agent must not decide that an inconvenient mandatory field is optional.

Preserve Delegation, Not Merely the Last Credential

The identity used by the final tool may differ from the identity that initiated the work. Retain the authenticated relationship between them and the authority granted at each relevant delegation boundary.

A username copied into a prompt is not authenticated attribution. A broadly privileged executor credential does not establish that the initiating user authorized every operation the credential can perform.

Keep credentials themselves out of the evidence. Record validated identities and protected references to the authorization records instead.

Bind Approval to the Proposal That Actually Executes

OWASP’s AI Agent Security Cheat Sheet recommends action-specific approvals covering the actor, tool, target, normalized parameters, timing, and expiry. Preserve that binding in the evidence, including what the reviewer actually saw.

Approval to execute until 14:05 is different from permission for the resulting grant to remain active until 14:20. Record both conditions.

Revalidate the current authority and relevant preconditions before dispatch. A historical permit record explains an earlier decision; it is not permission to execute indefinitely after the request has waited in a queue.

Record the Available Behavior Baseline Honestly

Capture the model identifiers actually available from the deployment and response, alongside the local runtime, prompt, tools, and context configuration. Where an immutable provider revision is unavailable, document that limitation rather than treating a stable endpoint name as an exact model version.

Preserve which source versions and transformations formed the model’s input. A policy snapshot retrieved after the incident is not necessarily the policy text the model received before acting.

This supports reconstruction, not a promise of identical model output on replay. The contract requires decision-relevant artifacts and concise rationale, not access to hidden model reasoning.

Assemble Evidence from Multiple Producers

The action record should be a view assembled from protected events and artifacts, not a document the agent can edit until it looks complete.

In the following diagram, the arrows carry evidence. The executor changes the target through a separately controlled execution path; the observer reads the target through its own authorized path.

Authenticate producers at ingestion and restrict which event types each producer can assert. An agent may submit a proposal; it should not be able to submit an event that the evidence service accepts as an independent observation merely by setting producer: verifier.

Append corrections and later findings as new events linked to the records they revise. Preserve the original record. An assembled dashboard may update, but the underlying history should show why its interpretation changed.

Include event occurrence time and collection time, using a consistent time representation such as Coordinated Universal Time (UTC). Preserve causal links and source sequencing where available. Do not infer an exact cross-system order solely by sorting clocks that may differ.

Most importantly, an evidence-service receipt establishes acceptance at its declared durability boundary. It does not establish the truth of every statement in the accepted event.

Require Durable Intent Before a Consequential Mutation

For the high-impact operating mode proposed here, the executor should not dispatch until the required intent and authorization evidence have been durably accepted. Record an attempt as prepared before crossing the external execution boundary.

“Prepared” must not mean “executed.” The executor may crash between those two events.

A successful write to process memory, standard output, or an unverified queue is not sufficient evidence of durable acceptance. Define the failure domain the record must survive and validate that the chosen persistence mechanism meets it.

There remains a gap between updating the journal and changing an external system. Unless both participate in an appropriate transaction protocol, the design cannot assume they commit atomically. A crash can leave a prepared attempt without an action, or a completed action without its final local record.

The contract must preserve that uncertainty and make it recoverable.

Distinguish Pre-Execution Failure from Post-Execution Uncertainty

Before dispatch, failure to accept mandatory evidence should hold the high-impact action. After dispatch, loss of a response or evidence delivery cannot undo the mutation. Preserve the attempt, suspend dependent actions that require a confirmed result, and reconcile through the target system.

NIST AU-5 calls for alerts and organization-defined responses to audit-logging failures. OWASP’s agent-specific guidance recommends failing closed when required high-impact checks, including audit logging, fail. The proposed design applies that gate to consequential dispatch, not indiscriminately to every running service.

A separately authorized containment procedure must remain available. Stopping further agent changes should not prevent responders from revoking dangerous access through an approved emergency path.

Protected local buffering can support a degraded mode only when it satisfies the accepted durability and tamper-resistance requirements. Define capacity limits and what happens when they are reached. Do not turn an evidence outage into a hidden audit_required: false configuration change.

Separate Reported Results from Verified Outcomes

Keep execution status and assurance status distinct. The following are proposed meanings, not product-defined status codes.

Define the verification profile before execution. It should specify the authoritative observation path, required checks, acceptable freshness, completion deadline, and what constitutes a conflict.

Compare the received checks with the required set. An empty list must not pass because “all returned checks succeeded.” Missing checks remain missing.

A Matching State Does Not Necessarily Establish Causation

In the opening scenario, the observer sees the expected role, principal, project, and expiry. That supports a claim about the observed configuration.

It does not, without additional correlation, prove which request created the grant. The contract may require the target’s operation record, request identifier, or other trustworthy change history to associate the effect with this action.

Nor does observing configured expiry establish that every downstream session will lose effective access at that moment. Treat expiry enforcement as a separate continuing obligation where the service requires it.

For irreversible actions, observation after the event is even more limited. Evidence that a dataset was exported does not prevent disclosure. The necessary preventive conditions must be enforced before execution.

Preserve Intent Across Retries

Amazon’s Builders’ Library explains how caller-provided request identifiers support idempotent retry handling and why reusing an identifier with changed parameters should be treated as a mismatch. It also notes that retention of those identifiers is service-dependent.

Apply that distinction to the contract: preserve one logical action and its idempotency key across legitimate retries, while recording separate attempts. Do not change the expiry or regenerate the intended operation merely because the first response was lost.

An idempotency key is not an authorization token. Its protection depends on the target’s documented behavior and retention window. A journal alone does not provide exactly-once execution across arbitrary external systems.

Where the target cannot safely deduplicate, hold uncertain mutations for reconciliation or an explicitly approved alternative. Blind retry is not an evidence-repair strategy.

A Machine-Readable Example with an Unresolved Outcome

The following YAML illustrates an assembled view for the hypothetical role grant. It is not a vendor configuration, a complete validation schema, or a record of an actual production action.

Opaque references stand for protected, versioned artifacts containing the detailed inputs, behavior baseline, approval, and event history. The timeout and missing target operation identifier are intentional: the example shows why a matching observation can still leave attribution unresolved.

contract_version: "0.1"
profile_ref: scoped-role-grant/v1
record_kind: assembled_action_view
action_id: act-031
run_id: run-014
environment: production
tenant_ref: tenant-a

identity:
  initiating_principal_ref: user-042
  agent_principal_ref: access-agent-prod
  executor_principal_ref: access-executor-prod
  delegation_record_ref: delegation-017

intent_ref: request-208
inputs_manifest_ref: inputs-031
behavior_baseline_ref: behavior-release-12
proposal:
  immutable_record_ref: proposal-031
  operation: role_assignment.create
  principal_ref: deployment-service
  role_ref: project-deployer
  resource_ref: project-claims-prod
  expires_at: "2026-09-12T14:20:00Z"

authorization:
  decision: permit
  policy_version: role-grant-4
  decision_record_ref: decision-031
  approval_ref: approval-902
  bound_proposal_ref: proposal-031
  execution_deadline: "2026-09-12T14:05:00Z"

attempts:
  - attempt_id: attempt-031-1
    prepared_event_ref: event-744
    invocation_event_ref: event-745
    dispatched_at: "2026-09-12T14:02:00Z"
    idempotency_key: grant-031
    transport_result: timeout
    target_operation_id: null

verification:
  observer_ref: identity-verifier-prod
  observation_ref: observation-117
  observed_at: "2026-09-12T14:02:10Z"
  observed_state_matches: true
  attributable_to_action: unknown
  result: inconclusive

recovery:
  procedure_ref: revoke-grant-v3
  requires_separate_authorization: true

lifecycle_obligation_ref: expiry-check-031
evidence_manifest_ref: evidence-031
classification: confidential
retention_policy_ref: privileged-actions-v2

disposition:
  status: unresolved
  dependent_actions: hold

Change the action profile, operation, identities, resources, timing, and recovery procedure to match the real service. Resolve references through a governed artifact service rather than fetching arbitrary locations supplied by the agent.

For this profile, correct processing retains the action as unresolved and holds work that depends on confirmed completion. It does not convert observed_state_matches: true into a successful end-to-end verdict.

Syntax validation is only the first check. The implementation must authenticate producers, validate artifact integrity and reference resolution, confirm proposal binding, evaluate timing and policy, and enforce the required verification set. None of those properties is established by accepting well-formed YAML.

Use Traces for Diagnosis Without Sampling Away Accountability

OpenTelemetry for AI agents provides a useful instrumentation foundation. The official OpenTelemetry GenAI semantic-conventions project describes spans, metrics, and events for AI interactions. Reuse applicable conventions rather than inventing new names for every diagnostic attribute.

The evidence contract adds a different obligation: retaining the required records for every in-scope consequential action. OpenTelemetry’s sampling documentation distinguishes sampled traces that are exported from those not selected for export. A sampled diagnostic dataset therefore cannot be assumed to contain every required action record.

Keep mandatory evidence delivery independent of diagnostic sampling. The implementation may use the same backend where it supports the necessary controls; the delivery, retention, access, and completeness requirements still need separate validation.

Link evidence to traces for investigation, but make the action record usable when a diagnostic trace is absent. Conversely, complete tracing does not transform an agent-authored success claim into external verification.

Protect the Evidence Without Creating a Sensitive-Data Archive

NIST AU-9 covers protection of audit information and audit tools from unauthorized access, modification, and deletion. Apply that boundary to the collector configuration and ingestion path as well as the stored records.

A protected store is insufficient when the agent can stop collection, impersonate another producer, or redirect observations before they arrive. Preserve the administrative boundaries assessed in Article 3.

Cryptographic integrity also has limits. A valid signature can support origin and integrity checks; it does not prove that the signer observed the truth. A digest chain cannot, by itself, prove that every expected event was recorded. Use separately protected checkpoints and reconciliation with target-side records where the threat model requires them.

Retain Necessary Facts, Not Every Secret

OWASP’s Logging Cheat Sheet advises against directly recording access tokens, passwords, keys, and information beyond the logging system’s permitted classification. It also recommends validating and sanitizing event data to resist log injection.

Design the contract to keep secrets out of AI traces and logs. Put sensitive decision artifacts in appropriately restricted storage, expose redacted operational views, and record access to the evidence itself. Minimize content before it reaches lower-trust collectors or external analytics services.

A digest is an integrity reference, not a replacement for material that an investigator must later inspect. Conversely, a privacy requirement may prohibit retaining particular source content. Record the permitted retention basis and the resulting reconstruction limitation rather than promising unlimited replay.

Preserve References Through Their Required Lifetime

An evidence manifest should remain usable for its approved retention period. Preserve the schema, policy, tool-contract, and verification-profile versions needed to interpret historical records.

When content is legitimately removed under its lifecycle policy, retain an appropriate disposition record where permitted. Do not let a dead reference silently appear equivalent to an artifact that was never collected.

There is no universal retention duration in this proposed contract. The records owner must set it for the action class and applicable obligations, including exceptions or holds, with security and privacy review.

Treat Recovery as Another Accountable Action

A rollback reference describes an available procedure. It does not establish that recovery ran or that its result was acceptable.

When recovery is necessary, create a linked action with its own authority, attempts, target checks, and result. Preserve the original failure or uncertainty. A later successful revocation should not rewrite the grant attempt as though it never happened.

Use recovery preconditions to avoid overwriting legitimate concurrent changes. Document irreversible effects separately. Removing access cannot establish that no information was obtained while that access existed.

For the role example, grant creation, expiry enforcement, emergency revocation, and any session-containment procedure can require different observations. A single green status should not conceal outstanding obligations.

Validate the Contract with Deliberate Evidence Failures

Begin in an authorized test environment with synthetic identities and records. The objective is to test evidence handling, not merely generate a clean success report.

Also test permitted actions, recovery, and an evidence-service outage that exhausts the approved buffer. These are proposed tests, not results reported here.

Then give an independent reviewer the protected records without the agent’s completion summary. The reviewer should be able to determine who initiated the action, which authority applied, what was attempted, what the target evidence supports, and what remains unknown.

A design that passes field-presence checks but cannot support that reconstruction has not achieved the contract’s purpose.

Operate Evidence Quality as a Service Obligation

Assign responsibility before enabling unattended execution. The service owner defines acceptable outcomes and verification requirements. Policy owners define authority. Platform engineering maintains capture and reference resolution. Security and records owners protect the evidence. Operations owns unresolved actions and escalation.

Measure evidence coverage against independently observed activity, not solely against records already present in the journal. Otherwise, entirely missing actions disappear from the denominator. Target-side activity without a matching authorized action record deserves investigation, with source coverage limitations stated explicitly.

Track the age of unresolved actions, missing verification, integrity failures, and the time required to reconstruct a sampled action. Keep these measures separate from task throughput and model quality.

Start with one action class, validate the contract in a representative environment, and enable a bounded production rollout only after accepting its evidence and recovery limitations. Version profile changes and retain the rules that governed earlier actions. A new schema must not quietly reinterpret yesterday’s incomplete record as today’s success.

Conclusion

The Agent Action Evidence Contract turns a broad demand for auditability into explicit obligations around each consequential action. It identifies the sources needed to establish intent, authority, execution, observed effects, and recovery, while keeping claims and uncertainty distinguishable.

The useful outcome is not a larger log archive. It is an action record that remains meaningful when the agent is wrong, the response is lost, or the investigation no longer trusts the component that performed the work.

The next installment, The Architecture That Keeps AI From Authorizing Itself, places these obligations across runtime, enforcement, execution, evidence, and human authority boundaries.

The control plane must not grade itself.

Choose one privileged action and reconstruct it without reading the agent’s summary. Can you establish its authority and effects from records the agent cannot rewrite?

External References

• NIST: Security and Privacy Controls for Information Systems and Organizations
• OWASP: AI Agent Security Cheat Sheet
• OWASP: Logging Cheat Sheet
• Amazon Builders’ Library: Making retries safe with idempotent APIs
• OpenTelemetry: Sampling
• OpenTelemetry: OpenTelemetry GenAI Semantic Conventions

The post The Agent Action Evidence Contract: What Every AI Action Must Record appeared first on Digital Thought Disruption.