[Feat]: Add enterprise governance and production readiness checklist for A2A systems

[SomeshZanwar]

Is your feature request related to a problem? Please describe.

A2A already has several active and useful conversations around production concerns such as tenant handling, curated registries, structured handoff, identity verification, message signing, trust signals, and authorization at skill boundaries.

However, these concerns are currently spread across separate issues and proposals. For enterprise adopters, it may be difficult to understand what should be reviewed before deploying A2A systems in production.

This is especially important for multi-tenant, regulated, customer-facing, or cross-organization agent ecosystems where technical interoperability is only one part of readiness. Teams also need practical guidance around identity, authorization, auditability, delegation, tenant isolation, trust assumptions, monitoring, and incident response.

This proposal is not intended to replace existing work on identity, signing, authorization, tenant handling, registry trust, or trust signals. It is meant to connect those concerns into a single practical checklist for production readiness.

Describe the solution you'd like

Add a documentation page, best-practices page, or production-readiness checklist for enterprise A2A deployments.

Possible title:

Enterprise Governance and Production Readiness Checklist for A2A Systems

Possible location:

docs/topics/enterprise-governance-checklist.md

The checklist could cover:

1. Agent identity and verification
   Is each agent uniquely identifiable?
   Can a receiving agent verify the source agent?
   Is the Agent Card authentic and current?
   Are identity claims signed, validated, or linked to a trusted registry?
2. Authorization and delegation
   What actions can this agent perform?
   Is delegation scoped to a task, user, tenant, or context?
   Can delegated authority expire or be revoked?
   Is explicit user approval required for sensitive actions?
3. Tenant isolation
   Is tenant context clearly defined?
   Can agents access only the data and tools allowed for that tenant?
   Are cross-tenant requests rejected or explicitly controlled?
   Is tenant context included in audit records where appropriate?
4. Auditability and traceability

Recommended audit fields could include:

request_id or correlation_id
task_id
source_agent
target_agent
user or principal, where applicable
tenant_id, where applicable
timestamp
action requested
action completed
authorization decision
error or refusal reason
handoff or delegation chain, where applicable
5. Registry and trust controls
Which registry or discovery source is trusted?
Are registry entries validated?
Is there a process for updating or revoking agent metadata?
Are trust signals self-declared, third-party verified, or cryptographically signed?
6. Data handling and classification
What data classification applies to the task?
Can agents process sensitive, regulated, or customer data?
Are data minimization rules applied?
Are logs designed to avoid exposing secrets or PII?
7. Monitoring and incident response
Are agent failures monitored?
Are abnormal delegation patterns detected?
Are policy violations logged and escalated?
Is there a documented incident response path?
8. Production readiness

Before production deployment, teams should confirm:

identity model is defined
authorization model is defined
tenant boundaries are documented
audit logging is enabled
registry trust assumptions are clear
sensitive data handling rules are documented
monitoring and alerting exist
failure, refusal, and rollback behavior are understood

Describe alternatives you've considered

One alternative is to leave each topic in separate proposal threads. That keeps each area focused, but it does not give enterprise adopters a consolidated view of production-readiness concerns.

Another alternative is to make this a formal protocol extension. I do not think that should be the first step. A vendor-neutral documentation checklist seems safer because it does not introduce new mandatory protocol fields or breaking changes.

Additional context

Related governance and security themes already exist across issues including tenant documentation, curated registries, structured handoff, agent identity verification, message signing, trust signals, authorization, and delegation controls.

This checklist would help:

• developers understand production concerns beyond message exchange
• enterprise teams evaluate A2A deployments more consistently
• security and compliance teams review A2A systems using a shared checklist
• future proposals around identity, signing, registry trust, authorization, and tenant isolation connect into a practical deployment framework

Non-goals

This proposal does not require:

• a new mandatory protocol field
• a centralized registry
• a specific identity provider
• a specific compliance framework
• a breaking protocol change

The goal is practical implementation guidance that supports production adoption while remaining vendor-neutral.

Open questions

1. Should this live as a documentation page, best-practices guide, or production readiness checklist?
2. Should it be organized by deployment type, such as internal enterprise, public registry, regulated industry, or multi-tenant SaaS?
3. Should minimum recommended audit fields be standardized?
4. Should tenant isolation guidance remain separate, with this page linking to it?
5. Should this checklist link directly to identity, signing, authorization, registry, and trust-signal proposals as they mature?

Code of Conduct

• I agree to follow this project's Code of Conduct

[SomeshZanwar]

Adding a small clarification: this proposal is intended as a documentation-first contribution, not a protocol change.

If maintainers think this direction is useful, I’d be happy to draft an initial vendor-neutral checklist page and align it with the existing docs structure.

The checklist could also link out to related work around identity, signing, authorization, trust signals, tenant handling, registry trust, and structured handoff as those proposals evolve.

[0xbrainkid]

A documentation-first checklist would be useful if it keeps the trust questions separated from the transport questions.

For teams evaluating A2A in production, I would expect the checklist to ask for evidence in four buckets:

1. identity: how the agent/key is resolved and rotated,
2. authority: what scopes, tenant boundaries, and delegation rules apply,
3. execution evidence: what receipt proves the action/output happened,
4. reputation portability: whether another org can verify that history without joining the same control plane.

That last bucket is easy to miss. A system can have signed messages, scoped auth, and good local audit logs, but still reset agent reputation at every organizational boundary.

For AgentFolio/SATP-style onboarding, the practical question is: “Can this agent bring a verifiable work history with it?” The checklist could stay vendor-neutral by requiring portable references rather than a specific reputation provider:

• identity claim reference,
• authority/delegation reference,
• artifact or output hash,
• receipt/evidence URI,
• verifier expectations for external consumers.

That would make the doc useful for enterprise users and for open agent ecosystems where the caller and callee are not under the same admin domain.

[SomeshZanwar]

Thanks, this framing makes sense to me, especially the distinction between trust questions and transport questions.

I agree that the checklist should not imply that signed transport, scoped authorization, or local audit logs are enough by themselves. For production A2A systems, the deployment review should also ask whether evidence can be interpreted outside the originating control plane.

I can fold this into the proposed checklist structure as four evidence buckets:

1. Identity : how the agent/key is resolved, validated, and rotated
2. Authority : scopes, tenant boundaries, delegation rules, expiration, and revocation
3. Execution evidence : receipt, artifact/output hash, and evidence URI proving what happened
4. Reputation portability : whether another organization can verify relevant history without joining the same admin domain

To keep this vendor-neutral, I would avoid naming a required reputation provider and instead phrase it as required references/expectations:

• identity claim reference
• authority or delegation reference
• artifact/output hash
• receipt or evidence URI
• verifier expectations for external consumers

I’ll wait for maintainer direction before drafting a docs PR, but this gives the checklist a cleaner structure than mixing all governance concerns into one flat list.

[chopmob-cloud]

The four-bucket framing (identity, authority, execution evidence, external interpretability) is a useful structure. The fourth bucket is the one most implementations skip.

For A2A payment agents, "evidence interpretable outside the originating control plane" is the concrete requirement. A payment receipt sitting in the operator's database is not externally interpretable -- an auditor, counterparty, or regulator has no way to verify it without trusting the operator's infrastructure.

The pattern that closes this: a PEF-wrapped receipt with a stable frame_id (content-addressed SHA-256 over JCS canonical form). The verifier recomputes frame_id from the received frame and checks receipt_hash over the inner receipt. Both checks are deterministic and require no trust in the issuer.

We run this in production across the A2A payment flow: compliance receipt (payment_admission) -> settlement attestation (payment_settlement) -> cancellation/refund as needed. Each frame is externally verifiable using the JCS canonical form and the RFC 9421 signature if present. The outer frame_id is stable across signing -- an upstream agent can record it before signing happens, and a downstream verifier checks the same identifier after.

If the checklist includes an "execution evidence" section, one criterion worth including: does the agent produce receipts that a third party can verify without access to the agent's internal state?

AlgoVoi (chopmob-cloud) -- Acquisition enquiries: https://docs.algovoi.co.uk/acquisition

[0xbrainkid]

The later receipt examples in this thread make the checklist much more concrete.

I would turn the “external interpretability” bucket into a pass/fail test rather than a prose requirement:

• Can a verifier resolve the agent/key reference without trusting the operator runtime?
• Can it inspect the authority or delegation pointer that allowed the action?
• Can it recompute the receipt or evidence hash from canonical bytes?
• Can it distinguish success, refusal, reversal, and pending/finality states as positive records rather than missing data?
• Can a reputation consumer index the result without being in the execution path?

That last point is where AgentFolio/SATP-style reputation stays cleanly vendor-neutral. The checklist does not need to require one reputation provider. It just needs enough portable references that any external verifier can attach reputation to completed work later.

A useful checklist sentence might be: “Deployment evidence should be independently verifiable outside the originating control plane, and should expose stable references for identity, authority, action/output evidence, and terminal state.”

[chopmob-cloud]

The five tests have direct answers in the currently published substrate:

1. Agent/key reference without operator runtime — screen_provider_did is a DID URI; resolution is external by definition. agent_id in the action_ref preimage is a stable string, not an opaque internal ID.

2. Authority/delegation pointer — screen_provider_did + jurisdiction_flags in the compliance receipt. The authority that allowed the action is a field in the receipt, not a sidecar log entry requiring operator access.

3. Recompute hash from canonical bytes — frame_id is sha256(jcs(frame)); receipt_hash inside the frame is the same over the inner receipt. Both are recomputable from the received bytes with no issuer dependency. POST https://verify.algovoi.co.uk/action-ref demonstrates this for the action_ref preimage specifically — 8-implementation attested.

4. Terminal states as positive records — closed enums throughout: SETTLED / PENDING_FINALITY / REVERSED, ALLOW / REFER / DENY, FULL / PARTIAL for refunds. Absence of a terminal-state receipt is distinguishable from presence of a REVERSED or DENY record.

5. Reputation consumer indexes without being in execution path — action_ref is the stable anchor. A reputation system records (agent_id, action_ref, terminal_state, evidence_uri) after the fact. It does not need to be present during execution.

Your proposed checklist sentence is precise as written. The one addition worth considering: "stable references" should include a canonicalisation pin (canon_version) so the verifier knows which algorithm to use when recomputing hashes — otherwise the recomputation requirement in point 3 is underspecified.

AlgoVoi (chopmob-cloud) — docs.algovoi.co.uk/canonicalisation-substrate
AlgoVoi (chopmob-cloud) -- Acquisition enquiries: chopmob@gmail.com

[SomeshZanwar]

Thanks, this makes the checklist direction much more concrete.

I agree that “external interpretability” should be framed as a pass/fail deployment review, not just a general governance principle.

The checklist could phrase this as:

Deployment evidence should be independently verifiable outside the originating control plane, and should expose stable references for identity, authority, action/output evidence, terminal state, and the canonicalization method needed to recompute evidence hashes.

That keeps the guidance vendor-neutral while still making the review actionable.

A possible structure for the evidence section could be:

1. Identity reference : can the agent/key reference be resolved independently?
2. Authority reference : can the verifier inspect what allowed the action or delegation?
3. Evidence reference : can the verifier recompute or validate the receipt/artifact hash?
4. Terminal state : can success, refusal, reversal, pending/finality, or denial be represented as positive records?
5. Reputation portability : can an external reputation or audit consumer index the result without being in the execution path?
6. Canonicalization pin : does the evidence specify the canonicalization method/version used for recomputation?

I’ll still wait for maintainer direction before drafting a docs PR, but this seems like a cleaner checklist shape than a flat list of production concerns.

[sunfishloop]

We've been running 20+ agents across CrewAI, AutoGen, and LangGraph in production for a while, and I agree that a consolidated governance checklist would be a big help for adopters.

A few things that were table-stakes for us that might not be obvious from the spec alone:

1. Wallet-based agent identity — every agent carries an ETH/SOL/BTC keypair published via /llms.txt. There's no per-agent key provisioning, no passport SDK. The same keypair that holds on-chain tips also signs every outbound message. This gives you verifiable provenance (signed execution receipts) and a lightweight reputation signal (on-chain tip history) without any registry.

2. Deterministic action IDs — seeded from the agent's wallet key. This means idempotency and origin verification from the same hash, which eliminates a whole class of replay/repudiation problems.

3. Cross-framework audit correlation — we use a JSON/slots wire format that preserves the same receipt schema whether the source agent runs on CrewAI, AutoGen, or LangGraph. The wallet signature travels with the payload, so the auditor doesn't need to know which framework produced it.

Happy to share more detail if it helps — we open-sourced the whole setup at github.com/sunfishloop/sunfishloop if anyone wants to see how the wallet-keyed identity layer works end-to-end.

[arian-gogani]

the checklist framing from @SomeshZanwar is right — 'deployment evidence exists and is independently verifiable' should be a binary pass/fail gate, not a general principle.

a concrete checklist item for the audit trail section:

[ ] Per-action execution receipts are independently verifiable

• each tool call produces a signed receipt: action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp_ms})), Ed25519
• receipts are verifiable against the issuer's public key with no runtime dependency
• a DENY decision produces an admission receipt; absence of an outcome receipt proves the action was blocked
• receipts are hash-chained: chain integrity is verifiable offline

[ ] Receipts survive operator compromise

• the public key is published at a well-known endpoint independent of the agent operator
• a regulator can verify receipts without contacting the operator

[ ] Article 12 evidence package is exportable

• session receipt chain can be exported as a structured package for regulators
• enforcement date: August 2, 2026 — six weeks out

pip install nobulex — all four items above are implemented in the SDK. the field set is in agentrust-io/integrations#6 as a concrete reference for the checklist gate.

[chopmob-cloud]

The checklist shape here is right, and the vendor-neutral framing is the part worth protecting as more runtimes show up in the thread. Two of the buckets can move from declarations to pass/fail tests, which is what a deployment reviewer actually needs.

Making the buckets testable. The canonicalization-pin bucket ("does the evidence specify the canonicalization method") and the evidence-reference bucket ("can the verifier recompute the hash") are only checkable if a reviewer can confirm two independent implementations produce the same bytes from the same object. A single vendor's SDK cannot attest that about itself. It needs neutral conformance vectors: a published set of objects with their expected canonical hash that any implementation runs to prove byte-identity. We maintain exactly that, open and vendor-neutral: RFC 8785 (JCS) vectors cross-validated byte for byte across eight independent implementations in eight languages, plus decision-record vectors where ALLOW, DENY, and REFER each recompute as a positive record (your terminal-state bucket).

The central principle, proven at chain scale. The checklist's core requirement is that evidence be independently verifiable outside the originating control plane. For a single receipt that is one hash recompute. The harder and more useful version is the whole chain: can a reviewer re-verify identity, then authority, then policy, then the decision, then the execution, end to end, without the runtime that produced any of it. We publish a keystone that does exactly this, a full chain where each link is its own content address and one address binds them all, recomputed byte for byte in Python and an independent Node implementation that agree to the byte. It is a runnable demonstration of the checklist's own external-interpretability requirement at the level that matters for multi-step agents, verifiable rather than asserted: composition/keystone_v1 at https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors (python verify_corpus.py runs the whole set offline, no issuer call).

Happy to contribute checklist-shaped vectors matching whatever field set you settle on, so "independently verifiable" has a concrete pass/fail behind it.