Problem Statement
Current TBAC (Tool-Based Access Control) primarily defines what an agent is allowed to do and which agents can invoke other agents.
However, in multi-agent, cross-organization scenarios, we observe a gap in enforcing fine-grained, caller-aware authorization at the receiving agent level.
Example scenario:
A Manufacturing Agent exposes:
- Order-related capabilities (e.g., place order)
- Finance-related capabilities (e.g., query order status)
From another organization:
- A Purchase Agent should be allowed to place orders
- A Finance Agent should only be allowed to query order details
While TBAC can restrict which agents can invoke the Manufacturing Agent, once access is granted:
What prevents a Finance Agent from invoking order-related actions?
There is currently no standardized mechanism for:
Propagating and verifying the caller’s identity
Enforcing conditional tool access based on the caller
This becomes especially important in multi-hop agent chains, where simple inheritance or agent-level permissions are insufficient.
Proposed Solution
Introduce support for caller-aware authorization, where the receiving agent can:
- Access verified caller identity
- Standard mechanism to propagate caller identity across agent interactions
- Cryptographically verifiable (aligned with existing identity components if applicable)
- Enforce conditional tool access
Policies that combine:
- Receiving agent identity
- Caller identity
- (Optionally) task/context
Example policy:
IF agent == ManufacturingAgent AND caller == PurchaseAgent
THEN allow tools = {place_order}
IF agent == ManufacturingAgent AND caller == FinanceAgent
THEN allow tools = {query_order}
Integrate with existing TBAC / context-sharing efforts
Extend current model rather than replace it
Aligns well with ongoing work in delegation and context-sharing WG discussions
Alternatives Considered
- Task-based access control (TBAC only)
- Can restrict tools based on task type
- Limitation: does not prevent misuse when different callers can trigger the same task
- Restricting agent-to-agent invocation entirely
- Prevent Finance Agent from calling Manufacturing Agent
Limitation: not viable when the same agent needs access to different subsets of capabilities
- Custom logic outside AGNTCY
- Implement caller checks and filtering within application logic
Limitation:
Duplicates responsibility outside the framework
Reduces interoperability and standardization
Additional Context
This use case emerged from a real customer scenario involving cross-organization procurement workflows.
Discussed with Identity WG member, where this was identified as aligning with:
- delegation
- context-sharing
and future evolution of authorization models
Particularly relevant for:
- Multi-agent enterprise workflows
- Cross-org agent interactions
- Scenarios requiring least-privilege enforcement across agent boundaries
Checklist
Problem Statement
Current TBAC (Tool-Based Access Control) primarily defines what an agent is allowed to do and which agents can invoke other agents.
However, in multi-agent, cross-organization scenarios, we observe a gap in enforcing fine-grained, caller-aware authorization at the receiving agent level.
Example scenario:
A Manufacturing Agent exposes:
From another organization:
While TBAC can restrict which agents can invoke the Manufacturing Agent, once access is granted:
What prevents a Finance Agent from invoking order-related actions?
There is currently no standardized mechanism for:
Propagating and verifying the caller’s identity
Enforcing conditional tool access based on the caller
This becomes especially important in multi-hop agent chains, where simple inheritance or agent-level permissions are insufficient.
Proposed Solution
Introduce support for caller-aware authorization, where the receiving agent can:
Policies that combine:
Example policy:
IF agent == ManufacturingAgent AND caller == PurchaseAgent
THEN allow tools = {place_order}
IF agent == ManufacturingAgent AND caller == FinanceAgent
THEN allow tools = {query_order}
Integrate with existing TBAC / context-sharing efforts
Extend current model rather than replace it
Aligns well with ongoing work in delegation and context-sharing WG discussions
Alternatives Considered
Limitation: not viable when the same agent needs access to different subsets of capabilities
Limitation:
Duplicates responsibility outside the framework
Reduces interoperability and standardization
Additional Context
This use case emerged from a real customer scenario involving cross-organization procurement workflows.
Discussed with Identity WG member, where this was identified as aligning with:
and future evolution of authorization models
Particularly relevant for:
Checklist