Securing your multi-agent workflows with Agent-to-Agent Connections

The identity blind spot in multi-agent workflows

Right now, inside your enterprise, an AI agent could be invoking another agent autonomously. A sales agent pulls a customer's payment history from a finance agent. A monitoring agent triggers a diagnostic agent to investigate a failed service. Work that once took dozens of human handoffs now completes in seconds.

Here's the problem: Every one of those handoffs is an access event you need to govern. And most security teams have no visibility into them. Meanwhile, AI teams building these multi-agent workflows are custom-coding authorization between every agent pair, stitching together point solutions with no central place to see or control what's happening.

Multi-agent architectures, whether initiated by humans, by machines, or increasingly by agents themselves, are already in production. But the identity layer underneath them is missing. Without an identity layer purpose-built for agent-to-agent interactions, these connections become blind spots: Ungoverned, unattributable, and impossible to audit.

What’s new: Secure agent-to-agent connections

To secure and govern multi-agent workflows, Okta for AI Agents leverages Okta's blueprint for the secure agentic enterprise, a strategic framework for discovering, authorizing, and governing autonomous AI agents. The second pillar of this blueprint asks: “What can they connect to?”, focusing on securing agent-to-resource connections, giving agents scoped, audited access to the enterprise data and systems they need.

Now, we’re extending that same secure connectivity model to encompass multi-agent workflows. The same primitives that secure humans and applications today, such as agent identities, scoped credentials, and audit attribution, now extend to the connections between agents.

At the center of this is Agent-to-Agent Connections, a new capability of Okta for AI Agents that lets you define: 

• Per-agent connection policies 
• Which upstream services and agents can invoke an agent 
• Agent scope (what it can access)
• Session duration (how long that access lasts)

Identity is preserved at every handoff, so every connection remains verifiable across the workflow.

For security teams, that means every agent-to-agent call is governed, scoped, and fully auditable. For builders, it means building multi-agent workflows without having to code authorization for every agent. All you need to do is define authorization and access policies once in Okta, and every agent in the delegation chain will automatically work with those defined policies.

How do Agent-to-Agent Connections work?

Every time one agent calls another, Okta verifies the connection is authorized, scopes the data to only what the task requires, and records who acted on whose behalf, so the multi-agent workflow is governed end to end.

Step-by-step multi-agent flow

To see how this works, let’s follow a single request through the multi-agent workflow. Picture a routine report-generation task handled by two agents:

• User assistant agent: Acts on behalf of the employee
• Data analyst agent: Pulls from sensitive databases

Here's the flow:

1. The user asks the user assistant agent to "build me a Q4 report."
2. The user assistant agent needs data, so it calls the data analyst agent "on behalf of [user]."
3. Okta checks the policy: Is the user assistant agent allowed to call the data analyst agent? Can the data analyst agent share this data with the user?
4. If yes, Okta issues a temporary token that says: "Data analyst agent, this request is from [user] via [user assistant agent]. You can share X, Y, Z."
5. The data analyst agent validates the token, shares only what's allowed, and logs the request.
6. The user assistant agent uses the data to build the report and returns it to the user.
7. Everything is auditable. The log shows: User → user assistant agent → data analyst agent.

Three principles make this possible:

•  Explicit allowlists: Define which agents can call which other agents.
•  Scoped permissions: Give each downstream agent only what it needs for its task.
•  Verifiable delegation chains: Travels with every token, so the audit log captures who authorized what.

The result: Security teams get complete visibility into every agent action. Builders stop writing authorization code between agents and start shipping multi-agent workflows faster.

Why the multi-agent delegation chain remains trustworthy

Two things keep the delegation chain trustworthy: 

1. Every agent can act as both client and resource. 
2. Every token carries a complete, verifiable record of who authorized what. Authorization happens at runtime, and the action is stored in the audit log.

Agents acting both as clients and resources

Every agent in Okta is both a client and a resource. This matters because in a real multi-agent workflow, agents don't just sit at one end of a call; they sit in the middle. Every agent can initiate requests to other agents or services, and can receive requests from them. That dual role is what makes orchestration possible.

• As a client: The agent can call other agents or services
• As a resource: Other agents can call this agent (if policy allows it)

A single agent can be both specialized and orchestrating, without breaking the chain of trust.

Preserving context via token-based delegation records

When Okta issues a token for an agent-to-agent call, it includes a record of the entire path:

• "This is for User A"
• "User A delegated to the assistant agent"
• "The assistant agent delegated to the data analyst agent"
• "The data analyst agent is allowed to do X, Y, Z"

Okta includes the full delegation chain in the token so the receiving agent can verify authorization before acting. Okta's audit log captures the delegation chain for every call, preserving it long after the token itself expires. 

If something goes wrong, such as a security incident, an audit question, or a compliance review, you can pull the audit record and see exactly what happened, who authorized it, and whether it complied with policy. No manual log digging. No correlation work.

Analyzing human-led vs. machine-led flow patterns

Whether a workflow starts with a human or machine, one identity anchors the entire chain. Every downstream agent acts under that authority, and every step is attributable to it. Agent-to-Agent Connections handles both patterns today.

Pattern 1: A human starts the chain

A user logs in and asks an agent to perform an action. That agent might call other agents to complete the work, but the human's identity is the anchor.

Example: Employee asks, "Give me a summary of Q4 metrics."

1. The summary agent calls the dashboard agent (on behalf of the employee)
2. The dashboard agent calls the database agent (on behalf of the employee)

The employee's identity flows through the entire chain, and every step is logged under their name.

What Okta records in the audit log: "The Employee authorized the Summary Agent to call the Dashboard Agent. The Dashboard Agent retrieved metrics from the Database Agent within the Employee's access scope."

Pattern 2: A service starts the chain 

Enterprises have decades of service apps, ETL pipelines, scheduled jobs, and microservices running deterministic workloads. These systems are now incorporating AI.

Example: A monitoring service detects a CPU spike.

1. The monitoring service calls the diagnostics agent
2. The diagnostics agent calls the log analysis agent

No user initiated the request. The monitoring service is the client and the diagnostics agent is its resource, and the service's authority flows through the entire chain.

What Okta records in the audit log: "The monitoring service authorized the diagnostics agent to call the log analysis agent. The log analysis agent can analyze production logs for the monitoring service.“

Key differences between the two patterns

The result: One governance model, regardless of where the delegation chain starts. Security teams get full traceability across human- and machine-initiated workflows with every handoff recorded. AI teams get authorization that works the same way whether a user or a service is at the root, so there's no separate logic to build and maintain for each pattern.

Pattern 3: An autonomous agent starts the chain (coming soon)

A third pattern is coming soon: On-behalf-of-self, where an autonomous agent can act entirely on its own authority, without any delegation, under policy pre-approved by an admin. Using this pattern, you’ll be able to run autonomous agents within a pre-defined policy, fully audited and governed. 

Bringing multi-agent workflows under centralized governance

Agents are already calling other agents in your environment, but nothing governs those calls. The question was never if agents would call other agents; it's whether you can answer for what happens when they do.

That's what Okta for AI Agents makes possible. By extending the same identity primitives that secure your people, apps, and agents to the connections between agents, you bring the multi-agent workflow out of the blind spot and under governance. Agent-to-Agent Connections gives you the allowlists, scoped permissions, and verifiable chain that make autonomous workflows safe to scale.

As multi-agent architectures grow more complex, the enterprises that win won't just move fast; they'll be able to demonstrate, at any moment, who did what, on whose behalf, and within what policy.

Ready to govern your multi-agent workflows?

Early access to Agent-to-Agent Connections is now available for Okta customers. Reach out to your Okta account team to enroll.

See how these AI agent controls work in practice. Join our Okta streamcast to learn more about what agent governance looks like when identity is the control point. 

These materials are intended for general informational purposes only and are not intended to be legal, privacy, security, compliance, or business advice. You are responsible for obtaining security, privacy, compliance, or business advice from your own professional advisors. Any mention of future products, features, functionalities, or certifications in this blog is for informational purposes only. These items are not commitments to deliver and should not be relied upon to make purchasing decisions. © Okta, Inc. and its affiliates. 2026.