Brace for autonomous trust chains, delegated privilege sprawl, and cross-agent compliance gaps…

Agents (the likes of GitHub Copilot, ServiceNow, Splunk SOAR, GitLab CI/CD, or OpenClaw) are long past being the fictional musings of Neal Stephenson and Stanisław Lem. They’re booking meetings, buying birthday presents for our offspring, triaging tickets, writing code, provisioning cloud resources, engaging on social channels in our company's name, executing queries, and silently acquiring permissions faster than we can say “least privilege.” They might use AI internally. They might not. The problem isn’t that agents are out there doing things on our behalf. The problem is, up until now, they didn’t speak the same language and they’re terrifyingly over-permissioned.

Google’s Agent-to-Agent protocol (A2A) aims to change that first problem. It’s an attempt to standardize how autonomous systems (AI and otherwise) discover each other, communicate, delegate tasks, and exchange context across platforms. A2A is an interoperability layer for agents. Different systems working together smoothly, effortlessly, without the need for special fixes or manual effort.

• The A2A Agent Interoperability Protocol was formally released as an open standard last November, with its specification documents and code available to the community. Microsoft has stepped up and publicly stated its support for the standard, and this is happening as I write. Tutorials, SDKs, and integration examples exist, including support in Google Vertex AI Agent Builder for creating A2A-compliant agents.

An agent may use an LLM. It may expose APIs. It may run scripts. But the defining feature is autonomous orchestration. And if we’re a CISO, cloud architect, or SOC team colleague, we need to pay attention, because this matters a whole lot more than we might think.

Agents Traditionally Didn’t Interoperate

Before A2A, agents were siloed:

• One agent operates inside a SaaS tool.
• Another runs inside a cloud provider.
• Another sits in our internal tooling.
• Yet another is embedded in a customer workflow.

They each maintained their own memory, used their own schemas, authenticated in a myriad of different ways, represented identity differently, and generally handled task delegation inconsistently. Before A2A, there was no shared protocol for discovering other agents, negotiating capabilities, passing structured tasks, handling stateful collaboration, or verifying authority.

We were building distributed autonomous systems without distributed standards.

Historically, this phase never lasts long. The web needed HTTPS. APIs needed REST. Identity needed OAuth. Now agents have something similar.

What A2A Actually Is

A2A (Agent-to-Agent) is a protocol framework designed to allow agents to:

1. Discover each other
2. Advertise capabilities
3. Delegate tasks
4. Share structured messages
5. Maintain conversational or operational state

In other words, it’s a communication standard. SMTP lets email servers talk. OAuth lets services trust each other. A2A aims to let agents collaborate, or that’s the goal anyway.

Why This Is Happening Now

Three things have changed.

1. Agents Are Persistent

We’ve moved from prompt-response systems to long-running agents that monitor systems, execute multi-step workflows, act on behalf of users, and maintain memory.

Once agents persist, they need structured interaction.

2. Enterprise Workflows Are Multi-System

A real-world enterprise workflow might span Google Workspace, AWS, Azure, Jira, Slack, Salesforce, custom internal systems, etc.

If agents are automating these workflows, they need to coordinate across boundaries.

3. AI Has Moved From Tool to Actor

We’ve crossed a threshold where AI is not just assisting humans. It is making decisions, initiating actions, requesting access, and modifying infrastructure.

AI has become an actor, and we need protocols that define how actors interact.

How A2A Works at a High Level

At a conceptual level, A2A introduces:

Capability Advertisement

An agent can declare what it can do, what inputs it expects, what outputs it returns, and what permissions it requires.

This allows other agents to determine: “Can you handle this task?”

Structured Task Exchange

Rather than passing vague prompts, agents exchange structured task definitions, machine-readable schemas, context bundles, and status updates.

This reduces ambiguity and improves reliability.

Stateful Collaboration

Agents can track ongoing workflows, pass partial progress, retry or escalate, and coordinate across steps.

It’s closer to distributed systems design than chatbot interaction.

The Security Implications (this is where it gets interesting)

If we’re responsible for cloud identity, access governance, or SOC operations, A2A changes our threat model. Now that agents can talk to each other, they can chain capabilities, amplify privileges, propagate tasks, and escalate actions indirectly. We’re no longer just managing human users, we’re managing autonomous service actors that delegate to other autonomous actors. A tangled and intricate web of invisible interactions, hidden permissions, unseen authorization flows, and silent connections. This is accidental power and trust by assumption, not by policy.

“Complexity is the worst enemy of security.”
- Bruce Schneier, “A Plea for Simplicity” [1999]

The moment we allow autonomous systems to call each other across trust boundaries, we increase systemic complexity, and therefore risk. Interoperability without visibility becomes an attack surface.

Agents as Non-Human Identities

In traditional IAM, we think in terms of human users, service accounts, applications, and APIs.

Agents blur these lines, and here’s where we get to that second problem (terrifyingly over-permissioned). They are software actors, capable of decision-making, acting on delegated authority, potentially long-lived, and potentially self-directing. In identity terms, they behave like dynamic service principals. They behave like people, and as we all know people (no matter how well meaning) are not to be trusted with unfettered access.

With A2A, those principals will now coordinate laterally. This means that privilege boundaries must be explicit and delegation must be traceable. Authority must be scoped and audit trails must be preserved. Otherwise, we’ve just created autonomous lateral movement.

Delegation is the Real Risk Surface

A2A enables task delegation between agents.

Delegation means one agent instructs another, authority may be inherited, context may include identity, and actions may be executed downstream.

If poorly controlled, this creates implicit trust chains, authority/access sprawl, hidden escalation paths, and hard-to-audit automation. From a governance standpoint, this is classic privilege creep, but worryingly machine-accelerated.

Where A2A is Going to be Powerful

Let’s be fair, there’s a solid upside that we’re all going to want to be a part of.

Cross-Vendor Workflows

Imagine a monitoring agent detects anomalous IAM behavior in AWS. It delegates investigation to a logging analysis agent, that agent triggers a ticketing agent, the ticketing agent escalates to a remediation agent, then a compliance agent logs the entire chain. All automatically.

Up until now, this required brittle integrations where changing a field name, updating an API version, adding an MFA, or reordering a JSON response can make a workflow fail for no obvious reason. A2A aims to standardize the interaction model.

Reduced Integration Overhead

Instead of building custom glue between every system, agents conform to a shared interaction pattern and new capabilities become plug-and-play, meaning ecosystems become composable.

This mirrors how APIs matured 15 years ago, when they moved from developer plumbing to business infrastructure.

What This Means for Security

If A2A succeeds, and it certainly looks like it’s going to, enterprises will see more autonomous orchestration, faster workflow automation, and agent-driven cross-system decision loops.

This means we must treat agents as identities and enforce least privilege on a "need-to-know" basis. We need to monitor agent-to-agent delegation, audit cross-agent workflows, and enforce policy boundaries on task execution.

If we don’t, we’re going to inherit invisible trust chains, distributed privilege amplification, and compliance blind spots. A potential quagmire.

Policy is the Missing Layer

A2A handles communication, but it doesn’t automatically solve authorization, entitlement governance, least privilege enforcement/privileged access management, just-in-time access elevation, or privilege revocation. That’s our job. Or more precisely, that’s the identity layer’s job.

In a future, where agents coordinate, we’ll need zero standing privileges (ZSP) for agents, explicit delegation scopes, time-bound authority, policy-driven approvals, and evidence trails in line with international cybersecurity standards. Otherwise, we’re effectively running distributed wildcard superusers.

A2A and Zero Trust

A2A aligns with zero trust principles, but only if it’s implemented correctly. Zero Trust says never trust implicitly, verify continuously, assume breach, and enforce least privilege.

If agent collaboration becomes implicit trust, it violates Zero Trust. If delegation requires explicit policy evaluation, it reinforces Zero Trust.

The protocol is neutral. Our implementations can’t afford to be.

A Bigger Pattern

Every technology shift follows the same arc:

1. Capability explosion
2. Integration chaos
3. Standardization
4. Governance realization
5. Security catch-up

A2A is phase three. Security teams are now in phase four (and rapidly careening towards five).

What We Need to do Right Now

We don’t need to implement A2A in-house right now, but we should make a start by inventorying agents in our environment and classifying them as non-human identities. Right now we should be reviewing their permissions, transitioning to zero standing privileges (ZSP), and monitoring unchecked delegation paths. We need to ensure that audit logging includes agents and AI actors.

We need to start treating agents like “cloud workloads with intent,” because essentially that’s what they are.

Planning Accordingly

A2A isn’t just a convenience. It’s a signal. It signals that agents and AI systems are moving from isolated tools to collaborative actors. Enterprise automation is now multi-agent, and identity governance must expand beyond humans. Interoperability will accelerate agent adoption.

It will also accelerate risk if left unmanaged.

The protocol itself is a milestone, and one that will undoubtedly benefit our portfolio of Trustle integrations. The governance around it will determine whether it becomes infrastructure, or incident response fallout. And as sure as logs fill up on a Friday afternoon, security will eventually inherit whatever their architecture omits in design.

We’re going to have to plan accordingly, and we need to start now. 

If agents are now part of our estate (and if not they soon will be) the time to wrap them in governance and conduct an AI audit is today. Start with our free, full-feature trial. In about 30 minutes you’ll see every entitlement across your cloud and SaaS stack, including non-human identities and agent accounts.