Add downstream agent attribution and provenance labels

[dinpd]

Opportunity

AgentPass already preserves durable evidence of who proposed, authorized, and executed an agent action. Humans viewing the resulting downstream object - a GitHub comment, ticket update, CRM note, email, document change, or other write - may still see only the responsible user's identity and have no immediate indication that an agent produced the content.

Add a destination-aware attribution capability that makes agent-created content visibly attributable while retaining AgentPass's stronger machine-verifiable evidence and action-bound authorization model.

Product boundary

Downstream attribution is not authorization and is not a substitute for signed receipts, decision evidence, provider verification, or audit records. It is a human-visible projection of trusted AgentPass context onto the resulting downstream object.

The desired linkage is:

responsible principal -> agent/application -> runtime/session -> job/action
-> authorization decision -> provider execution -> downstream attribution

Scope

• Define a versioned downstream-attribution object containing safe references to:
  • responsible principal;
  • agent/application identity;
  • runtime or session identity when available;
  • tenant and job/action references;
  • authorization decision and execution-receipt references;
  • attribution policy/template version.
• Add destination-specific policy for required, optional, and prohibited attribution.
• Prefer native structured metadata or actor fields when a provider supports them.
• Provide human-readable fallback labels for text surfaces such as comments, ticket notes, CRM notes, and email bodies.
• Define provider adapters that insert attribution only after an action is authorized and bind the inserted attribution to the exact action/execution record.
• Record whether attribution was inserted, rejected, stripped, altered, or unsupported, plus the resulting downstream object reference.
• Make label text configurable by destination while keeping the underlying structured evidence stable.
• Add redaction and minimization rules so labels never expose credentials, raw receipts, reusable grants, sensitive payloads, unrestricted identifiers, or unnecessary PII.
• Add an initial end-to-end demo using at least one provider-native metadata surface and one visible text fallback.

Example user-visible labels

These are illustrative, not fixed protocol text:

• Created by Support Agent on behalf of Dima
• Agent-assisted update - agent: support-agent, job: case-1042
• Generated by an authorized AI agent; verification reference: apx_...

The default should be concise. Full provenance remains available through the AgentPass audit/evidence surface rather than being embedded in the downstream content.

Acceptance criteria

• A versioned downstream-attribution schema distinguishes responsible principal, agent/application, runtime/session, job/action, decision, execution, and downstream-object references.
• Policy can require, allow, or prohibit attribution per tool, action, provider, destination type, or risk tier.
• At least one provider-native metadata adapter and one visible text-label adapter are implemented and tested.
• Attribution is emitted only for an applicable authorized execution and cannot independently grant authority.
• The downstream attribution references the same normalized action and execution evidence as the audit trail.
• Changed action scope, mismatched decision/execution references, or caller-supplied spoofed attribution fails closed.
• Audit events distinguish inserted, rejected, stripped, altered, unsupported, and not-required outcomes.
• Labels and metadata exclude credentials, reusable authorization material, raw tool payloads, unrestricted provider responses, and unnecessary personal data.
• Destination-specific templates are versioned and deterministic.
• An end-to-end demo shows a human-visible downstream label linked to inspectable AgentPass evidence.
• Documentation explains that visible attribution complements - but does not replace - authorization, provider verification, and durable evidence.

Validation

• Native provider metadata insertion.
• Comment or ticket-note text fallback.
• Provider rejects the attribution field.
• Middleware strips or alters the label.
• Caller attempts to spoof another agent or responsible principal.
• Exact retry returns the existing downstream object/result without duplicating the label or mutation.
• Changed retry scope is rejected.
• PII and credential leak assertions over all label and metadata outputs.

Non-goals

• A universal watermarking or AI-content-detection standard.
• Claiming a visible label is cryptographic proof.
• Replacing provider actor identity, business authorization, IAM, OAuth, or AgentPass authorization receipts.
• Embedding full receipts, signatures, prompts, chain of thought, or sensitive action payloads into downstream content.
• Requiring every destination to display identical wording.

Roadmap placement

Track as P7: Downstream Agent Attribution, following the stable action-authorization, provider-trust, and framework-distribution foundations. The feature may be implemented incrementally alongside provider adapters, but its completion gate is the end-to-end human-visible attribution plus durable evidence linkage described above.

Target milestone: Agent Attribution & Provenance.