Agent API security when one AI agent calls another

An innovative product manager has spotted an opportunity. An AI assistant could drastically ease the manual process involved in preparing credit-review packs. The prototype works. Before moving from pilot to production, the security team asks an important question: can the bank verify to a regulator who authorised that access? Which agents carried it out? Was the data access within the permitted scope?

Complex banking organisations often have multiple layers of agents, services and resources, which makes this harder. The assistant delegates some tasks to a sub-agent, which calls tools and APIs governed by a different team. If each team builds its own security and access pattern, the architect inherits several approaches and IAM has to establish how they fit together. Good agent-security practice requires agents to be authenticated, their access to be constrained, and delegated authority to be preserved as work passes between services. Following one request through five steps shows where that information can be lost and what a consistent access pattern needs to preserve.

How agent API security changes across a workflow

APIs already support applications acting on behalf of people and other services. Agent workflows add decisions about which tools to use and which tasks to delegate, sometimes in response to information the agent has just retrieved. The access granted at each step still needs to stay within the authority originally granted for the task.

Validating the token presented to an API is one part of that decision. The API may also need information about the initiating person or organisation, the acting agent and the limits of the delegation. Where those systems are controlled by different teams or organisations, they need an agreed way to establish that the identity and delegation information can be trusted.

Following a credit review through five steps

Consider an illustrative design. The assistant asks a specialist agent to retrieve eighteen months of transaction history for one corporate client, across multiple accounts held in the bank's multi-national holding structure. That agent uses a tool server to reach an API in the bank's Polish subsidiary. In this design, the final integration uses a broadly scoped service credential, with no verified link to the employee's task approval.

The request crosses an identity and access boundary before reaching the transaction API. The same pattern could extend to a partner or supplier. The diagram above shows the request path; token issuance is handled by the relevant authorisation servers.

1. The employee approves the task

The relationship manager signs in through the bank's identity provider. The assistant records the requested client, the reporting period and the task approval. Those records serve a different purpose from authentication: signing in establishes who the employee is; it does not approve every action an agent might later choose.

When the assistant needs a protected service, it obtains an access token intended for that service. The token's audience identifies where it can be used. Its scope describes the access granted, which may still need to be constrained by client-specific entitlements and local policy. OAuth resource indicators provide a standard mechanism for identifying the target resource.

2. The assistant delegates to a specialist agent

The assistant asks a data agent to retrieve the transactions. It may use Agent2Agent, or A2A, to exchange the task. A2A uses established HTTP authentication mechanisms; the identity presented can represent a user, an application or both.

In our example, the request identifies only the assistant. The employee's name appears in the task text, with no verifiable statement of delegated authority. That is an implementation gap. The A2A guidance leaves credential acquisition to the surrounding identity infrastructure, so the bank must decide how the receiving agent verifies whose authority it is being asked to use.

3. The agent calls a tool through MCP

The data agent uses the Model Context Protocol, or MCP, to call a transaction-retrieval tool. Here, the tool runs on a protected HTTP-based MCP server.

The MCP authorisation rules require that server to validate that an incoming access token was issued for it. When calling the transaction API in the Polish subsidiary, it must use a separate token intended for that API. It must not pass through the token received from its MCP client.

The separate token protects the resource boundary. Delegation context can still be preserved when it is obtained. In this example, however, the tool server uses a service credential without carrying forward the employee's authority. The API receives less information than the assistant had at the start.

4. The request crosses into another trust domain

The transaction service belongs to another trust domain in the Polish subsidiary: a set of systems governed by its own identity and access policies. A domain can sit within the same bank or belong to an external organisation.

Its authorisation server recognises the tool integration and issues an API token with the integration's broad access rights. Because this design supplies no verified delegation context, the destination has no reliable basis for tying that grant to the named employee and this credit-review task.

The destination must be able to verify the issuer and apply its own access policy. Making signed metadata discoverable helps systems find and validate it. Whether the issuer and the requested access are acceptable remains a governance and policy decision.

5. The API evaluates the request

The API validates its access token and applies its configured policy. In our example, that policy permits the integration to retrieve the requested transactions. The request succeeds.

The remaining question is whether the bank can connect that access to the employee's entitlement and recorded approval. A successful response establishes that the request passed the configured checks. The token alone may say little about why the wider workflow was authorised.

What the final API can establish

The distinction is between the evidence available in this example and the evidence required to explain the access. A better-integrated design can give the API, its policy service and audit systems more of that context.

A correlation identifier helps join records, but does not prove that a delegation was legitimate. Equally, a valid bearer token proves possession of that token rather than, by itself, the identity of the running process. Certificate-bound tokens can require proof of the associated private key; evidence about the workload itself is a further consideration.

These distinctions also matter when an agent encounters prompt injection. It can act on malicious content while holding valid permissions. Verifiable identity supports accountability, but the bank still needs appropriate tool restrictions, oversight and application records.

What is identity chained authorisation

Identity chained authorisation describes preserving verifiable information about who authorised a task and the authority delegated as work passes between agents and services. Receiving systems use that information alongside their own access policies.

Existing standards already provide useful building blocks. OAuth 2.0 Token Exchange allows a service to request another token for a downstream resource. A token can identify both the subject on whose behalf access is requested and the current actor. Its scope still has to be constrained by issuance policy; exchanging one token for another does not, by itself, reduce the permissions being granted.

RFC 8693 also supports nested actor claims, but previous actors are informational for access-control purposes. They do not, on their own, prove each earlier permission reduction or reconstruct the original approval.

For separate domains, the OAuth identity and authorisation chaining specification combines token exchange with signed authorisation grants. It assumes a trust relationship between domains and compatible support for the relevant flows. At the time of publication, it is in the RFC Editor queue. The deployment still needs explicit trust and access policies.

The identity information each domain needs

The bank needs a consistent way to establish identity and authority across its chosen platforms. That information should cover:

• The agent and its accountable operator. Give agents distinct identities and establish which organisation or team is responsible for them.
• The delegated authority. Represent whose authority the agent carries, the permitted access and the conditions under which it may be used.
• The running instance. Where supported, bind the governed identity to evidence about the workload actually making the request. Registering a software version alone does not prove this.
• The current status of trust. Give receiving systems a way to check credential expiry, revocation and changes in authority.

The joint Five Eyes guidance on agentic AI supports distinct cryptographic agent identities, a trusted registry, role binding and least privilege. Those identity controls sit alongside broader measures for secure agent operation.

Across domains, federation can reduce the need for bespoke integrations with each counterparty. Each domain still needs to accept the relevant trust framework and apply its own policies. This gives teams a common approach they can reuse while retaining local governance.

How Raidiam Connect supports this pattern

Raidiam Connect provides infrastructure for establishing trust in agent identity and delegated authority across domains. It helps domains publish and resolve verifiable identity, authority, credential and lifecycle information, and can bind an agent's governed identity to evidence about a specific running instance.

Built on OAuth, OpenID Federation, public key infrastructure and verifiable credentials, it sits alongside the bank's existing identity providers, authorisation servers, gateways and policy engines. Those systems use the trust information when making and enforcing access decisions.

This builds on Raidiam's experience operating trust infrastructure in regulated financial services. For banks developing agent workflows, the aim is a consistent pattern that architecture and IAM teams can assess and delivery teams can reuse. Identity and delegated authority are one part of the work required to bring a use case into production.

Start with one production workflow

Take a use case waiting for access approval and map it together with architecture, IAM and the programme owner.

• Trace the request. Identify each agent, tool, API and authorisation server. Record the credential presented at each stage and the access it permits.
• Check the authority behind it. Establish who approved the task, how delegation is represented and how client-specific entitlements are enforced. Define how the relevant records will be correlated.
• Constrain and test the access. Where token exchange is appropriate, require resource-specific tokens with policy-constrained scope. Test what happens when the task exceeds its mandate, a credential expires or authority is withdrawn.

That gives the bank a concrete pattern to assess before another team builds a different one. It also gives the programme owner a clearer account of what must be resolved for this use case to proceed.

Explore how Raidiam Connect supports AI agent identity and delegated authority across systems.

Frequently asked questions

How is AI agent security different from API security

AI agent security builds on API security and also addresses autonomous tool use, delegation and untrusted input. When agents work across services, the bank needs to preserve relevant authority and constrain each request. The underlying authentication and authorisation controls remain essential.

How do AI agents handle authentication

Agents use credentials such as access tokens or certificates through the identity infrastructure around them. Authentication establishes an identity or validates a credential; authorisation determines permitted access. The exact mechanism depends on the protocol and deployment, including whether access is delegated by a person or another principal.

Can an MCP server forward the access token it receives

Under MCP's protected HTTP OAuth flow, a server must not pass through its incoming client token to a downstream API. It uses a separate API token. The implementation can preserve relevant delegation context while obtaining that token.

Does identity chaining prevent prompt injection

No. An authenticated agent can still act on malicious instructions within its permissions. Identity and delegated-authority evidence support access decisions and investigation. Tool restrictions, oversight and other controls remain necessary to limit unsafe actions.