Community proposal: Agent Action Boundary Evidence model

[dinpd]

Opportunity

Agentic systems increasingly emit distributed traces, but a trace alone does not establish what crossed a trusted action boundary. The community lacks a small, vendor-neutral evidence model that distinguishes:

1. an action proposed by an agent;
2. the authorization decision made at an enforcement boundary;
3. any approval or challenge used to grant authority;
4. whether the action actually executed or was replayed;
5. independently observed outcomes; and
6. later assessments of goal attainment or constraint compliance.

Without this separation, implementations commonly conflate model output with execution, treat trace context as authority, or infer successful outcomes from transport success.

AgentPass already exercises several of these concepts, but this proposal should extract the interoperable boundary contract rather than standardize AgentPass-specific product schemas.

Proposed scope

Publish a community-draft proposal for an Agent Action Boundary Evidence model covering:

• vendor-neutral terminology and trust boundaries;
• stable identifiers and joins across proposal, authorization, execution, observation, and assessment records;
• normative invariants, including that trace context never grants authority;
• request/result digests, replay and idempotency semantics;
• provenance and optional signing/verifiability;
• privacy, content minimization, and artifact references;
• correlation with W3C Trace Context and OpenTelemetry GenAI spans/events;
• synchronous, asynchronous, gateway, provider-side, and multi-agent flows;
• a minimal JSON example and an AgentPass mapping as non-normative reference material; and
• explicit open questions on event envelopes, canonicalization, signing, and standards venues.

The initial draft should separate a minimal core action-evidence model from an optional intent-assurance extension for expected outcomes, trusted observations, and assessments.

Non-goals

• Replace OpenTelemetry, W3C Trace Context, OAuth/OIDC, MCP, policy languages, or provider audit systems.
• Define an agent reasoning or chain-of-thought format.
• Standardize prompts, tool schemas, evaluation rubrics, or storage backends.
• Claim that the first draft is an adopted standard.
• Require AgentPass-specific field names or infrastructure.

Acceptance criteria

• A versioned Markdown community draft exists under docs/proposals/.
• The draft clearly labels itself experimental and invites independent implementation feedback.
• It defines the trust model, terminology, core record types, identifiers, lifecycle, invariants, privacy requirements, and failure/replay semantics.
• It explains how W3C trace context and OpenTelemetry correlation complement—but do not establish—authorization authority.
• It separates the minimal core from the optional intent-assurance extension.
• It contains at least one end-to-end JSON example that does not expose raw tool arguments or secrets.
• It maps existing AgentPass artifacts to the proposal as a non-normative reference implementation.
• It includes concrete questions for reviewers and identifies possible upstream venues such as OpenTelemetry GenAI and MCP community proposals.
• The repository README links to the proposal and this discussion issue.

Acceptance-test plan

Automated

• Run the repository manifest/schema checks and relevant test suites to ensure documentation changes do not break the project.
• Verify new repository-relative Markdown links resolve.
• Search the proposal for accidental credentials, local paths, private identifiers, and language that incorrectly presents the draft as an adopted standard.

Human review

A reviewer should confirm that:

1. the proposal can be understood without prior AgentPass knowledge;
2. AgentPass is presented as a reference implementation rather than the normative standard;
3. the boundary between telemetry correlation and authority is unambiguous; and
4. the open questions are specific enough to solicit actionable community feedback.

Risks and security considerations

• Trace IDs and other caller-supplied correlation fields can be forged; they must never grant authority.
• Raw tool arguments, credentials, PII, and provider responses should not be required in portable evidence records.
• Signing without a defined trust policy can create false confidence; provenance and verification semantics must remain explicit.
• Overly broad scope could duplicate OpenTelemetry, MCP, or authorization standards; the proposal should remain focused on evidence at the action boundary.
• A product-shaped schema may discourage adoption; normative fields must remain implementation-neutral.

Feedback requested

• Is the action-boundary scope useful and sufficiently narrow?
• Which records belong in the minimal interoperable core?
• Should the portable envelope align with CloudEvents, OTLP log/events, another envelope, or remain transport-neutral?
• What canonicalization and signature formats are already deployed successfully?
• How should asynchronous delegation and provider-side execution link traces without trusting caller-controlled context?
• Is this best advanced through OpenTelemetry GenAI semantic conventions, an MCP SEP, a standalone specification, or coordinated profiles across them?

[dinpd]

Draft 0.1 is now published on main:

• Agent Action Boundary Evidence community draft 0.1
• Merged via docs: propose Agent Action Boundary Evidence model #44

This issue will remain open as the community feedback thread. The highest-value early feedback is independent implementation experience and disagreement about the minimal record set, identifier model, event/signature profiles, OpenTelemetry and MCP alignment, and the right standards venue.