Building Agents at Scale: Enterprise Lessons from LinkedIn, Salesforce, and Microsoft

The enterprise AI agent moment has arrived. Not as a distant projection from an analyst deck, but as an observable reality in production infrastructure at companies like LinkedIn, Salesforce, Microsoft, and thousands of organizations below them in the market.

The numbers are instructive. According to recent enterprise surveys, 57% of large organizations have AI agents running in production today. Gartner projects that 40% of enterprise software will incorporate some form of autonomous agent capability by the end of 2026. Global AI infrastructure capital expenditure is tracking toward $690 billion this year—a figure that reflects not just LLM inference costs, but the orchestration layers, tool integrations, and monitoring systems that agents require.

This is not a future state. It is the current state, and it is accelerating.

What follows is an analysis of how the most sophisticated enterprise deployments are architectured, what lessons they surface, and what security implications emerge from the patterns they share.

#LinkedIn: Messaging Infrastructure as Agent Substrate

LinkedIn's approach to multi-agent systems is one of the more technically interesting architectures to emerge from 2025. Rather than building a dedicated agent communication layer from scratch, LinkedIn's engineering teams made a pragmatic architectural decision: repurpose the existing messaging infrastructure.

Their member-to-member messaging system already handled high-throughput, low-latency bidirectional communication at scale. The protocol was proven, the infrastructure was battle-tested, and the team understood its failure modes. When the need arose to enable agent-to-agent communication for their AI features—talent recommendations, recruiter assistants, job matching agents—the messaging substrate was the logical foundation.

Layered on top is a gRPC-based skill registry. Each agent registers its capabilities—what it can do, what inputs it accepts, what outputs it produces—in a central directory. A routing layer uses this registry to resolve which agents can handle which requests, enabling dynamic composition of agent pipelines without hardcoded dependencies between individual agents.

The lifecycle management piece is deliberately stateless. Agent instances are ephemeral: spun up to handle a request, terminated when the work completes. State is externalized to persistent stores. This makes the system horizontally scalable and reduces the blast radius of individual agent failures.

From an engineering perspective, this architecture is elegant. It leverages existing investments, achieves the composability required for multi-agent workflows, and avoids the overhead of maintaining long-lived agent processes.

From a security perspective, however, the architecture surfaces an important observation: every agent-to-agent communication channel is a potential lateral movement path.

When agents communicate over a messaging substrate, the trust model of that substrate determines what an attacker can accomplish if they compromise a single agent. In a messaging system designed for human users, the trust assumptions are different—humans authenticate explicitly, have relatively bounded permissions, and don't autonomously chain operations. Agents do chain operations, and if the communication channel between them carries implicit trust, a compromised agent can potentially instruct other agents to act on its behalf.

The skill registry introduces a discovery surface. An attacker who gains read access to the registry learns the full capability map of the agent ecosystem—what each agent can do and what interfaces it exposes. That is operationally useful information for planning an attack.

None of this is unique to LinkedIn's approach. It is inherent to any multi-agent architecture built on existing communication infrastructure. The lesson is that architectural reuse brings security assumptions along for the ride, and those assumptions need to be explicitly re-examined in the agent context.

#Salesforce AgentForce: When Scale Forces Maturity

Salesforce has reported over 12,000 AgentForce implementations deployed within the first year of general availability. That number tells an interesting story about enterprise adoption velocity, but the more instructive story is the iteration count behind it.

AgentForce as a product has gone through three major architectural revisions since its initial release. Each revision was driven not by competitive pressure but by operational reality: the things that work for a hundred implementations do not necessarily work for twelve thousand.

The first iteration prioritized configurability and time-to-deploy. Customers could stand up agents quickly, and the default permission model was broad—agents inherited the permissions of the user who configured them, which was often an administrator. The rationale was that early adopters wanted to move fast and demonstrate value before worrying about operational details.

The problem with this model became apparent as implementations scaled. When agents inherit administrator-level permissions and operate autonomously, the blast radius of a misconfiguration or a compromised workflow is enormous. Security teams started pushing back. In some regulated industries, the audit requirements for agent actions became difficult to satisfy when permissions were not scoped to actual operational needs.

The second and third iterations introduced more granular permission controls, explicit topic scoping (defining which subjects an agent is allowed to discuss and act on), and the Einstein Trust Layer as a formalized security boundary. The trust layer handles grounding, data masking, and audit logging as platform-level capabilities rather than implementation-specific configurations.

The 12,000 implementation figure is significant not just because it represents scale, but because it represents the point at which ad-hoc security approaches stop being defensible. When an organization has one or two agents, a thoughtful engineer can keep the security model in their head. When there are hundreds or thousands, you need systematic governance.

This is the inflection point that most enterprises are approaching now, not just in Salesforce's ecosystem but across every agent platform. The experimentation phase—where teams deploy agents to explore what's possible—is giving way to a production phase where operational discipline is required.

For a detailed breakdown of AgentForce's security model and how to configure it correctly, see our Salesforce AgentForce Security Guide.

#Microsoft Copilot: From Helpers to Workers

Microsoft's trajectory with Copilot illustrates a shift that is happening across the industry, but Microsoft's scale makes it the clearest case study.

The original Copilot framing was explicitly about assistance. Copilot would help you draft an email, summarize a document, or suggest the next action. The human remained in the loop for every meaningful decision. The agent was a sophisticated autocomplete.

That framing has largely been retired. The current Copilot Studio platform supports autonomous agents—workflows that execute without human approval at each step, that can call external APIs, trigger Power Automate flows, read from SharePoint, query Dynamics 365, and take actions across the Microsoft 365 ecosystem without a human reviewing each operation.

Copilot Studio now supports multi-agent orchestration, where one agent can invoke another, pass context between them, and compose complex workflows from simpler agent building blocks. Microsoft added Model Context Protocol (MCP) support in late 2025, allowing Copilot agents to connect to any MCP-compatible server—extending their reach well beyond the native Microsoft connector ecosystem.

The shift from helpers to workers is not merely semantic. It represents a fundamental change in the threat model.

A Copilot assistant that helps draft emails operates within a narrow scope: it reads context, generates text, waits for human approval. If it behaves unexpectedly, a human catches the error before it propagates. An autonomous Copilot agent that processes incoming contract requests, updates Dynamics 365 records, triggers approval workflows, and sends external communications operates within a much broader scope—and can propagate errors or malicious instructions across multiple systems before any human reviews the output.

The security implications of this shift are significant. Traditional controls assume humans as the actors. Access controls govern what a user can do. Audit logs record what a user did. Approval workflows require a human decision. When agents become the actors, those controls either need to be extended to cover agent identities explicitly, or they become gaps.

For detailed guidance on securing Copilot Studio deployments, see our Copilot Studio Security Guide.

#OpenAI's Platform Play: Standardizing Agent Infrastructure

OpenAI's entry into the agent infrastructure market represents a different kind of player: one whose platform is already the underlying model for a significant fraction of enterprise AI deployments.

The Agents SDK, released in early 2025, provides a structured framework for building multi-agent systems on top of OpenAI models. It introduces the concept of handoffs—the mechanism by which one agent transfers control to another—and guardrails, which are programmable checks that run before and after agent actions. The SDK also formalizes the concept of a thread, the persistent context that carries state across an agent session.

The Frontier platform concept, still evolving as of this writing, is positioned as an operator-level environment for deploying and managing agents at enterprise scale. The key distinction from the standard API is the operational layer: logging, tracing, usage controls, and the ability to apply policy at the platform level rather than re-implementing it in each agent.

OpenAI is also participating in the AI Agent Infrastructure Foundation (AAIF) under the Linux Foundation, which was established in part to provide neutral governance for shared infrastructure standards—most notably, MCP.

The implications of OpenAI's platform moves are still developing, but the direction is clear: they are moving from being a model provider to being an agent infrastructure provider. That changes both the competitive dynamics of the market and the security considerations for enterprises that build on their platform.

#MCP: The TCP/IP of the Agent Ecosystem

Model Context Protocol has achieved something rare in infrastructure: rapid, cross-vendor adoption driven by genuine utility rather than vendor mandate.

MCP's npm package is tracking at 97 million monthly downloads as of early 2026. Anthropic donated the protocol to the AAIF under the Linux Foundation, removing it from single-vendor control and positioning it as a neutral standard. Microsoft, OpenAI, Google, and dozens of tool providers have added MCP support to their platforms.

The analogy to TCP/IP is apt in a specific way. TCP/IP didn't define what applications would be built on top of it; it defined the communication contract that allowed them to interoperate. MCP similarly defines how agents communicate with tools and data sources, without dictating what those tools do or how the agents are built. This neutrality is what drives adoption: any agent that speaks MCP can connect to any MCP server, regardless of vendor.

The practical consequence for enterprises is that MCP is becoming the default integration layer. When a new tool or data source supports MCP, it becomes accessible to every agent that supports MCP, automatically. The agent ecosystem benefits from network effects.

The security consequence follows from the same logic. If MCP is the universal connection layer, then MCP security is the universal attack surface. A misconfigured MCP server does not just expose one agent—it potentially exposes every agent connected to that server, across any platform.

MCP was designed for functionality, not for security. The protocol does not include built-in authentication mechanisms, authorization controls, or audit logging. Those are implementation concerns, left to the operators of individual MCP servers. In an ecosystem moving as fast as this one, that gap creates real risk.

Our MCP Security Guide covers the specific attack vectors and mitigation approaches in detail.

#The Common Security Gap Across Enterprise Architectures

LinkedIn's gRPC skill registry, Salesforce's AgentForce topic framework, Microsoft's multi-agent orchestration, OpenAI's handoff mechanism, and MCP's universal tool integration layer are different implementations, built by different teams, with different design priorities. But they share a common set of security challenges.

No standardized agent identity framework. Agents act on behalf of organizations, systems, and users—but in most current deployments, they don't have formal identities that satisfy enterprise security requirements. They inherit the credentials of the users or service accounts that configured them. They are not enrolled in identity governance workflows. They are not subject to periodic access review. When a security team asks "who is this agent, what can it access, and who authorized it," the answer is often unclear.

This is not a criticism of any individual platform—it reflects the pace of the market. Identity standards for non-human actors are still being developed. But the absence of a standardized framework means each organization must solve the identity problem independently, or leave it unsolved. See our analysis of AI Agent Identity for a deeper treatment.

Tool permissions are structurally too broad. Every agent platform we have assessed grants agents permissions that exceed what their operational function requires. The reasons are practical: narrowly scoped permissions require careful upfront configuration, and most teams are prioritizing time-to-deployment. The result is agents with read/write access to data they never need to read or write, and with the ability to call APIs whose outputs they never process.

Broad permissions are not just a compliance concern. They are the mechanism by which a compromised or misbehaving agent can escalate the impact of an incident.

Multi-agent communication lacks built-in authentication. When Agent A invokes Agent B, passing instructions and context, most current implementations do not cryptographically verify that the invocation is authorized. The receiving agent trusts the message because it arrived on the expected channel. This creates the conditions for agent impersonation attacks—where an attacker who can inject a message into the communication channel can instruct agents to take actions they were never authorized to perform.

This is not hypothetical. Our research team has demonstrated successful agent impersonation attacks against multi-agent deployments using all three major enterprise platforms.

Shadow agents proliferate in parallel with official deployments. For every sanctioned agent deployment, there are typically several unsanctioned experiments running in the same environment. Teams standing up agents to test an idea, individual contributors building integrations with personal API keys, pilot programs that were never officially shut down. These shadow agents are not subject to the security controls applied to official deployments, often run with elevated permissions, and are invisible to monitoring systems.

As the official agent estate scales, the shadow estate scales proportionally—often faster, because the friction of unofficial deployment is lower. See our coverage of Shadow Agents for discovery strategies.

#What This Means for Enterprise Security Teams

The analysis above is not an argument against building agents at scale. The organizations doing it are seeing real productivity gains, and the capabilities are genuinely transformative. The argument, rather, is that agent security must evolve at the same pace as agent capability—which it currently does not.

There is a useful frame for thinking about where enterprise agent programs typically are:

Most enterprises reading this are somewhere between expansion and production scale. The experimentation phase is over; the hard operational work is beginning.

Three capabilities define what systematic agent security looks like at this stage:

Discover: You cannot govern what you cannot see. The first priority is continuous discovery of every agent running in your environment—not just the ones in the official registry, but the experiments, the shadow deployments, the integrations built by individual teams. This requires monitoring at the infrastructure level, not just the application level.

Govern: Once you know what is running, you need a governance framework that covers identity (what is this agent, who is responsible for it), permissions (what is it allowed to access and act on), and policy (what constraints apply to its behavior). This framework needs to be systematic, not bespoke—applied consistently across platforms, not re-implemented for each one.

Monitor: Agents in production change. Permissions drift. New integrations are added. Behavior shifts as the underlying models are updated. Continuous monitoring of agent activity—what tools are being called, what data is being accessed, what actions are being taken—is the mechanism that detects when something has changed and surfaces it for review.

This is Guard0's thesis: that enterprise agent security requires the same systematic, continuous approach that enterprise network security and endpoint security required when those attack surfaces scaled. The tools are different. The principle is the same.

#Next Steps

If your organization is in the expansion or production-scale phase of agent deployment, two resources are directly relevant:

Take the Agent Security Assessment — a structured evaluation of your current agent security posture, covering discovery maturity, governance gaps, and monitoring coverage. Start the assessment.

Talk to the Guard0 team — if you are working through a specific architectural challenge or preparing for a board-level conversation about agent risk, we can help. Book a demo.