A2A Task composition — how do you structure agent collaboration and permission boundaries?

[zkeviny]

Our team does cross-department agent collaboration. Previously we sealed Python workflows and passed them manually. Now we want to automate this through A2A. Two questions:

1. How is the "task package" structured inside an A2A Task? The spec only defines TextPart / DataPart / FilePart — are people using FilePart for executable content, or other patterns?
2. When passing sensitive workflow code across agents, how do you design permission boundaries? Multiple separate capsules per agent, or one capsule with internal access control?

We're extending a tool we've been building to handle this. Would love to hear how the community approaches it.

[Ultroncn]

The TextPart / DataPart / FilePart names in your question describe A2A 0.3. In that version, inputs go in a Message.parts array; a Task tracks the work and its state, and generated outputs belong in Task.artifacts. There is no standard executable “task package” format or capsule layout.

For your first question, one option is a versioned DataPart describing an already-approved workflow and its inputs, for example this part fragment:

{
  "kind": "data",
  "data": {
    "schemaVersion": 1,
    "workflowId": "quarterly-report",
    "revision": "approved-revision-id",
    "inputs": { "period": "2026-Q3" }
  }
}

The fields inside data are your application contract. The receiver resolves that workflow identifier to its own approved implementation. A FilePart can carry a file or reference, including code as content, but it does not establish permission to execute it or define dependencies, entrypoints, or a runtime. Those would need a separate agreed contract.

For the permission boundary, A2A 0.3 §4.6 explicitly leaves authorization to the receiving server, based on the authenticated identity and server policy. An Agent Card advertises capabilities; it is not itself an execution grant. Check the requested workflow, input resources, and output access against that caller's permissions. A caller-supplied field claiming a scope cannot grant it.

A2A therefore doesn't choose separate capsules versus one capsule with internal ACLs. If separate departments are different trust domains and arbitrary code can run, I'd use separate execution identities and enforced isolation for those domains; sharing one runtime needs an independently reliable boundary around files, credentials, and tools. You can also avoid transferring sensitive implementation code by exposing the workflow as an agent skill and exchanging only inputs/results.

I checked the 0.3 type definitions and type-checked the fragment as a DataPart inside a Message. That verifies the protocol shape, not an executable-workflow implementation. If you target A2A 1.0, use its unified Part representation rather than copying this 0.3 wire shape.

[zkeviny]

Thanks so much for the detailed reply — this is really helpful context for our implementation.

The scenario we're trying to solve: even within the same organization, cross-department agent collaboration hits IP walls. For example, Finance agent wants Marketing agent to run a proprietary customer-scoring model locally (customer data can't leave Marketing's environment), but the scoring algorithm itself is Finance's internal knowledge — Marketing should execute but never see source. Neither the DataPart workflowId pattern (Marketing doesn't have the code pre-deployed) nor the skill exposure pattern (can't expose the scoring logic externally) solves this.

That's why we're building MGC — a sealed capsule format that lives purely inside A2A's Part payload. We don't touch the A2A protocol itself; the capsule carries metadata identifying the execution identity (node_pub). Receiving agents decrypt only if their identity matches, then execute in an isolated subprocess where source never lands on disk as plaintext.

This aligns with what your reply pointed to — A2A leaves authorization entirely to the receiving server based on authenticated identity and policy (§13.1 in 1.0, §4.6 in 0.3). Good to know we're on the right track.

[Ultroncn]

That clarifies the requirement. One distinction matters for “Marketing should execute but never see source”: encrypting to node_pub and avoiding plaintext files do not, by themselves, protect the code from the administrator of the receiving machine.

In an ordinary subprocess, the receiving OS ultimately supplies the plaintext to the interpreter/runtime. An administrator controlling that OS can generally inspect its process memory or instrument execution. Process isolation can help separate ordinary users and workloads; it does not establish confidentiality against the host that runs them. A recipient key identifies who can decrypt, not whether their runtime will keep the decrypted code secret.

If your threat model includes that host administrator, confidential execution needs a separate design—for example an appropriately scoped hardware-backed TEE, with attestation of the intended runtime before key release, plus controls on what results can leave it. The Confidential Computing Consortium definition, quoted here, specifically concerns computation in a hardware-based, attested execution environment. That is a different property from keeping plaintext off disk.

A2A can transport your agreed capsule metadata, but it does not supply those guarantees. I have not reviewed MGC's implementation; this is a boundary to make explicit in its security claims, rather than a conclusion about whether your implementation satisfies it.

[zkeviny]

Thanks for calling this out — you're exactly right, and this is a boundary we should be explicit about.

Our threat model is narrower than host-administrator protection. We target small teams / cross-department scenarios where you trust the node operator (the person running MGC), but want to prevent casual leakage: scripts landing on disk, being backed up by routine ops tools, read by non-admin team members, or captured during debugging. subprocess isolation + encrypted storage protects against those.

If the model expands to "don't even trust the host admin" — that's a different problem needing TEE + attestation, and we'd be the first to admit MGC doesn't solve it. Good flag to raise; we'll make sure this boundary is written clearly in our docs rather than implied.

Appreciate you taking the time to spell this out.