Is this only for AWS A2A gateways?

No. AWS's gateway is useful source context because it names registry, permission, routing, rate-limit, and streaming layers. The worksheet is vendor-neutral and can be used before AWS, another A2A gateway, an orchestrator, or a custom control layer enforces the graph.

How many workflows should we map first?

Start with one workflow where two or more agents already hand off work or where a third agent is about to join the path.

What is the most important field?

Allowed callers. If the row cannot name which agents or workflows may call this agent, the access design is not ready for production.

Multi-agent access field packet

Agent Access Matrix: a worksheet for multi-agent permissions

Before one agent discovers, calls, streams from, or authenticates with another, give the path a row: owner, caller list, scopes, operations, streaming rule, rate limit, credential source, log destination, disable owner, and review trigger.

Copy the access matrix Review one agent access graph

Agent access matrix worksheet showing agent IDs, allowed callers, scopes, streaming rules, rate limits, log destinations, and disable owners alongside a permission graph with approved and denied agent paths. — The matrix is the worksheet that names which agent-to-agent paths are allowed before a gateway enforces them.

Two or more agents discover, call, stream to, write to, authenticate with, or escalate to one another.

A new agent registry, A2A gateway, shared tool shelf, or orchestration layer is about to make agents easier to find.

A workflow crosses business boundaries such as support to billing, procurement to compliance, or sales to finance.

Streaming responses, delegated credentials, or automated escalation could expose context before review.

The owner cannot answer which agent may call which other agent, under which scope, and who can turn it off.

The current caller list still says any authenticated agent instead of naming allowed paths.

How to use it

Start with one row, one owner, and one review trigger

Discovery is not permission

A caller may be allowed to know an agent exists without being allowed to invoke it, stream from it, or ask it to change a record.

Name the caller path

Allowed callers is the row that turns a broad agent graph into specific production access. Wildcards should block approval until owners narrow them.

Split operations from access

Reading policy, opening an exception, streaming partial context, and administering rules are different permissions even when they target the same agent.

Logs need disable owners

The access path should produce denials and audit records, but it also needs a person who can close the path immediately during an incident.

Copyable worksheet

The register fields

Copy the table into a planning document or spreadsheet. Keep the first pass narrow: one production workload or five recurring questions before creating a broad catalog.

Copyable register worksheet fields and why each field matters
Field	What to write	Why it matters
Workflow name and owner	The workflow this access matrix governs, plus the person accountable for the outcome.	Agent permissions should be reviewed in the context of real work, not as disconnected infrastructure.
Agent ID	The stable name that appears in routing, policies, logs, and incident review.	A nickname cannot anchor access control or audits.
Business owner	The person or team accountable for this agent's behavior.	Every callable agent needs an owner before it becomes a dependency.
Runtime / endpoint	Where the agent runs and what path a client calls.	Routing should be visible before it becomes hidden infrastructure.
Capability / agent-card summary	What the agent claims it can do and what callers may discover.	Discovery metadata should not silently become permission.
Allowed callers	The agents, clients, workflows, or human consoles allowed to reach this agent.	This is where a wild-card graph becomes a governed graph.
Required scopes / claims	The JWT scopes, policy claims, or role grants required for access.	Authentication says who the caller is. Authorization says what path exists.
Allowed operations	Read, write, search, summarize, escalate, stream, administer, or a narrower verb list.	Calling an agent and asking it to change something are separate risks.
Streaming rule	Whether partial responses may stream back, to whom, and which content is excluded.	A live stream can leak reasoning or sensitive context before final review.
Rate limit	The ceiling per caller, per user, per workflow, or per minute.	Retry storms and runaway loops should fail closed before they become incidents.
Credential source	Where backend credentials, OAuth clients, or tokens are stored and rotated.	Point-to-point secrets are where invisible coupling starts.
Log / audit destination	Where calls, denials, streams, admin changes, and disables are recorded.	The path should be reconstructable after the fact.
Emergency disable owner	Who can close the path immediately and through what mechanism.	Incident response starts with knowing who can shut the gate.
Review date / trigger	When this row must be re-approved, retired, or changed.	Agent permissions age like production access.
Open question	The decision that still blocks approval.	A visible open question is safer than a quiet assumption.

Copy block

Paste this plain-text version into your next working doc

The register is intentionally portable. It should survive a meeting, a pull request, a wiki page, or a spreadsheet before it becomes a polished internal tool.

Agent Access Matrix

Workflow name:
Workflow owner:
Review date:
Reviewer:

| Agent ID | Business owner | Runtime / endpoint | Capability summary | Allowed callers | Required scopes / claims | Allowed operations | Streaming rule | Rate limit | Credential source | Log / audit destination | Emergency disable owner | Review trigger | Open question |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
|  |  |  |  |  |  |  |  |  |  |  |  |  |  |

If a caller is not listed, the call should:
If streaming is disallowed, the fallback response mode is:
If rate limit is exceeded, the workflow should:
If the path must be disabled, the owner and mechanism are:
What must be reviewed before the next agent is added:

Example row

A sample row, clearly marked as sample data

Agent ID: refund-policy-agent
Business owner: Support operations lead
Runtime / endpoint: Internal runtime, /agents/refund-policy-agent
Capability / agent-card summary: Reads current refund policy and returns exception guidance
Allowed callers: support-triage-agent, reviewer console
Required scopes / claims: refund-policy:read
Allowed operations: Read policy and summarize exception criteria; no write or admin operations
Streaming rule: No customer-facing stream; reviewer console may receive the final answer only
Rate limit: 40 requests per minute per caller; fail closed after retry storm
Credential source: OAuth client credentials in approved secrets store, rotated every 90 days
Log / audit destination: Support audit log with denials and disables retained for one year
Emergency disable owner: Support operations lead
Review date / trigger: Quarterly, and before adding any caller that can issue refunds
Open question: Should compliance cases route here or to a separate compliance agent?

Comparison card showing agent discovery metadata on one side and an access matrix row on the other, with named callers, scoped operations, a denied any-authenticated-agent path, and streaming disabled. — Discovery can tell an agent what exists. The access matrix decides which caller paths are allowed to run.

Next step

Bring one agent-to-agent workflow to an access review

BaristaLabs can help turn one live or proposed multi-agent workflow into caller lists, scopes, streaming rules, rate limits, credential sources, log destinations, disable owners, and review triggers before the access graph grows by exception.

Review one agent access graph

Source notes

Claims checked before publication

AWS's A2A gateway article still frames the gateway around centralized agent registry, discovery, routing, JWT-scope access control, backend OAuth authentication, rate limiting, and Server-Sent Events streaming support.
AWS's sample A2A gateway README still distinguishes hosting agents from operating management, control, and data layers for multiple A2A agents behind one domain.
The Agent2Agent protocol README still describes discovery of capabilities and collaboration between opaque agentic applications without exposing internal state, memory, or tools.
The source article's operating claim remains the resource frame: gateway infrastructure can enforce decisions only after a team has named the access graph.

Related resources

Agent Access Matrix: a worksheet for multi-agent permissions

Start with one row, one owner, and one review trigger

Discovery is not permission

Name the caller path

Split operations from access

Logs need disable owners

The register fields

Paste this plain-text version into your next working doc

A sample row, clearly marked as sample data

Bring one agent-to-agent workflow to an access review

Claims checked before publication

Keep the register connected to controls, receipts, and services

Source article

AI workflow controls

AI workflow security review worksheet

Agent receipt template

Tool-call governance comparison

Process automation