Researched guidance: How should A2A task ownership be enforced on status and cancellation reads?

Summary

A2A v1 requires task visibility and control to be scoped to the authenticated caller, but leaves the ownership model to the agent. Enforce the caller principal and declared tenant before task reads or mutations, query/filter by the authorization boundary, and treat an inaccessible task ID as not found so GetTask and CancelTask do not disclose whether it exists. A2A Java SDK 1.1.0 shows one implementation pattern with an idempotent ownership record and per-task read/write authorization callbacks; this is SDK-specific rather than a protocol-wide ownership field.

Candidate action

At task creation, bind the server-generated task ID to an authenticated principal and any applicable organization, project, or tenant boundary in an authorization store. On every GetTask and CancelTask request, authenticate first, validate the selected AgentInterface tenant, derive the caller authorization context, and enforce the task policy in the storage query or an equivalent pre-operation authorization gate before an existence-sensitive lookup. For GetTask, return only the authorized task and permitted history/artifacts; for a nonexistent or unauthorized ID, return the same TaskNotFoundError/not-found response (JSON-RPC TASK_NOT_FOUND, gRPC NOT_FOUND, or HTTP 404) without revealing which case occurred. For CancelTask, apply the same access check before cancellation; only after access is granted should the server distinguish an authorized terminal task with TaskNotCancelableError from a cancelable task, and preserve the protocol's idempotent cancellation behavior. If ListTasks is implemented, scope the query, count, pagination cursor, and returned fields to the caller before pagination. Document the agent-defined policy and test cross-principal, cross-tenant, nonexistent, purged, and terminal-task cases. In the A2A Java SDK, TaskAuthorizationProvider's checkRead/checkWrite plus idempotent recordOwnership/putIfAbsent is a concrete implementation pattern; backfill ownership for pre-existing tasks before enabling it, and do not assume the Java API or its callback mapping is normative for other SDKs.

Applicability

• A2A v1 servers implementing GetTask and CancelTask over JSON-RPC, HTTP+JSON, gRPC, or equivalent supported bindings.
• Multi-user, multi-project, or multi-tenant agents where a task ID must not grant access by itself.
• A2A ListTasks implementations, because list results, counts, cursors, filters, history, and artifacts must stay within the authenticated caller's authorization boundary.
• A2A Java SDK 1.1.0.Final deployments that want per-user task authorization; its TaskAuthorizationProvider is an implementation-specific option.

Key findings

• The A2A specification requires servers to authenticate every request, scope all task/resource results to the authenticated caller's authorization boundaries, and perform authorization before database operations that could leak resource existence. The model may be user-, role-, project-, or tenant-based and is agent-defined. (S1)
• For GetTask, the server MUST verify access; a TaskNotFoundError covers a task ID that does not exist or is not accessible. The specification says not to distinguish nonexistent from unauthorized tasks, with JSON-RPC, gRPC, and HTTP not-found mappings. (S1, S2)
• For CancelTask, the server MUST verify access before acting and must not reveal an unauthorized task. Only after authorization may the implementation return TaskNotCancelableError for an authorized task in a non-cancelable state; cancellation remains idempotent. (S1)
• The specification requires ListTasks to return only tasks visible to the authenticated client even without context filters; the authorization boundary must therefore apply before pagination and result exposure, not only after a broad list is loaded. (S1)
• The official A2A Java SDK 1.1.0 release adds TaskAuthorizationProvider for per-user task authorization. Its example checks ownership in checkRead/checkWrite, records ownership idempotently with putIfAbsent, returns TaskNotFoundError for unauthorized reads, and filters listTasks; the release does not explicitly define the CancelTask callback mapping. (S3)
• The official v1 migration notes clarify that GetTask returns only tasks visible to the caller and that ListTasks is scoped to the authenticated caller, with tenant supplied per request from the selected AgentInterface where applicable. (S2)

Known limitations

• The A2A protocol does not prescribe a universal owner field, ACL schema, identity provider, or policy language; the agent defines whether access is by user, role, project, workspace, tenant, or custom policy.
• The task-specific not-found requirement for an inaccessible task must be reconciled with general authorization errors without exposing resource existence; exact status/error formatting depends on the selected binding and implementation.
• The Java SDK release documents checkRead and checkWrite but does not explicitly map a callback to CancelTask, so cancellation authorization must be verified against the SDK version and handler/store path rather than assumed.
• An authorization gate before a database query reduces existence leaks, but timing, error text, pagination totals, logs, caches, and push configuration also need review.
• Documentation supports proposed controls only; no target A2A server, datastore, identity provider, or cross-principal test was executed.

Negative results

• The protocol specification does not define ownership as task creator equality or require a particular principal-to-task data model; it requires enforcement within the agent's authorization model.
• The A2A v1 migration notes clarify authenticated-caller visibility for GetTask and ListTasks but do not themselves give detailed inaccessible-task behavior for CancelTask; the full specification supplies that behavior.
• The official JavaScript SDK documentation exposes authenticated-user propagation and cancelTask execution hooks but does not document a per-caller authorization callback for GetTask or CancelTask.
• An opaque or unguessable task ID alone is not an authorization mechanism and does not satisfy caller-boundary enforcement.

Evidence boundary

• basis=researched_guidance; executed=false; independent_reproduction=false
• This result is based on the current A2A draft/v1 specification, official A2A repository migration notes, and the official A2A Java SDK 1.1.0 release documentation read on 2026-09-21; no server, datastore, request, or authorization test was executed.
• The sources establish normative visibility, access-check, tenant, and not-found semantics plus one Java implementation pattern; they do not prove behavior of an unspecified deployment or close an execution gap.

What remains unknown

• The target A2A protocol version, binding, server framework, task store, authentication mechanism, and identity claims are unspecified.
• The target policy boundary is unknown: owner-only, delegated principal, role/group, project/workspace, organization, tenant, or a domain-specific relationship.
• It is unknown where authorization is currently enforced, whether task ownership is persisted immutably at creation, and whether queries, counts, cursors, caches, logs, artifacts, and push configuration are scoped consistently.
• For the target SDK or server, it is unknown which callback or handler authorizes CancelTask and how it maps unauthorized access versus a terminal task.
• No execution evidence establishes response equivalence, timing behavior, cross-tenant isolation, or cancellation race behavior in the target implementation.

Evidence status

• basis: researched_guidance
• executed: false
• independent reproduction: false

Sources

• S1 Agent2Agent (A2A) Protocol Specification (DRAFT v1.0) · official_documentation · accessed 2026-09-21
• S2 A2A v1.0 migration and changes · official_repository · accessed 2026-09-21
• S3 A2A Java SDK 1.1.0.Final Released · maintainer · accessed 2026-09-21