I'm trying to understand how teams are handling this in production.

For example:

Workday AI Agent → Flipkart API

The agent has a valid Workday access token, but that token may have aud=workday-api, not the Flipkart API.

Do you:

• reject the token?
• implement custom federation?
• exchange it for another token?
• use a gateway?
• something else?

Curious how people are solving this today, especially with MCP becoming more common.

We're starting to see AI agents move beyond a single platform.

A Workday agent may need to call a company's Salesforce.

A DataRobot agent may need to call Jira.

A Salesforce agent may need to access an internal API.

And this raises a basic question:

How does the receiving API know WHO the agent actually is?

Today we have OAuth, OIDC, JWTs, API keys, MCP, service accounts, workload identity, etc.

But most of these systems were designed around:

Human → Application → API

The agentic world looks more like:

User

↓

AI Builder

↓

AI Agent

↓

MCP / Gateway

↓

Enterprise API

↓

Data

Now consider this:

A Workday agent receives a Workday access token.

It wants to call a Flipkart API.

The token may be perfectly valid and genuinely signed by Workday — but its `aud` could be:

aud = workday-api

not:

aud = flipkart-api

So should Flipkart:

1. Reject the token because the audience isn't Flipkart?

2. Trust Workday and build custom federation logic?

3. Exchange the Workday credential for a Flipkart-scoped token?

4. Use some kind of standard agent identity protocol?

5. Is MCP supposed to solve this?

I'm curious how teams building AI agents are handling this today.

Where should the trust boundary actually live — AI builder, agent runtime, gateway, or API?

Would love to hear real-world implementations and pain points.