Quick answerWhat if the visiting agent refuses to go through identity verification? Decline to proceed past what an unauthenticated human visitor could access on your normal channel; an agent unwilling to verify its principal's identity should not receive account-specific information or actions regardless of how it phrases the request. Does this change if the visiting agent is from a well-known, reputable AI product? No. The provider's reputation is not a substitute for verifying the specific customer relationship in that specific conversation; treat every visiting agent, regardless of provider, the same way on this point.
Quick answer
Verify the human principal behind the visiting agent before granting it anything beyond the access level a human customer would get through the same channel; do not extend elevated trust or bulk access just because the requester happens to be another AI agent rather than a person typing. Require the visiting agent to identify itself as an agent acting on a specific customer's behalf, confirm that customer's identity through your normal authentication path, and then treat the resulting conversation exactly like any other authenticated customer conversation, logged and rate limited the same way.
This is a different scenario than agents your own company controls
Designing the handoff when your AI agent passes a conversation to another company's AI agent and the real-time protocol for when one customer request needs multiple AI agents to collaborate both assume every agent in the exchange is one your company built, deployed, or has a direct integration contract with. A customer showing up with their own personal AI agent, one you have never seen before, did not build, and have no contract with, is a fundamentally different trust situation: you have no prior relationship with that agent's provider, no visibility into what it will do with information your agent shares back, and no assurance it is accurately representing the customer's actual intent.
Why identity verification matters more here, not less
A visiting agent claiming to act on a specific customer's behalf is a claim, not a fact, until verified through your own authentication channel, the same channel a human customer would use. Do not accept the visiting agent's own assertion of who it represents as sufficient; require the same login, one-time code, or account verification step you would require of a human customer, routed through the visiting agent as a pass-through rather than trusted at face value. An agent that skips this step because verifying feels redundant when "an AI is clearly asking on behalf of a real person" has created an impersonation vector that did not exist when only humans initiated contact directly.
Match the access level to the channel, not to the fact that a bot is asking
A customer's own agent should get exactly the same account access a logged-in human customer would get through your normal customer-facing surface, no more. Do not build a separate, higher-trust or bulk-access path specifically for agent-initiated requests, since that creates an incentive for a customer, or a malicious actor claiming to be a customer, to prefer routing through an agent specifically to get elevated access a direct human request would not receive.
This is distinct from an AI-to-human warm handoff, in the other direction
What context a human should see the instant an AI agent escalates to them is about your own agent handing a conversation up to your own human team. A customer-owned agent contacting your agent runs in the opposite direction and involves an external party your company has no employment or contract relationship with at all, which is why the verification and access controls here have to be stricter, not reused from the internal handoff pattern.
Log these interactions distinctly from ordinary human-initiated conversations
Flag agent-initiated conversations in your logs as their own category, separate from ordinary human chat sessions, so that unusual patterns (a spike in agent-initiated requests, a specific external agent provider generating disproportionate volume or unusual request shapes) are visible and reviewable rather than blending invisibly into normal customer-traffic metrics.