Buy, Build, or Inherit — It Reaches Everything Either Way

Ask a security leader how agents enter their environment and you'll get a two-part answer: some we buy, some we build. It's a tidy answer, but it's incomplete in a way that hides most of the risk.

You inherit them. This is the largest and fastest-growing source, and the one nobody owns by default. Agents arrive inside the third-party software you already run — a Slack that now ships coding agents, a Salesforce or a Zoom where agents run on top of the platform, a productivity suite with Copilot switched on. You didn't adopt these. They came with an update.

You configure them. When your teams do build agents, they mostly configure agents on third-party ground: Claude, Gemini, and Copilot surfaces, or platforms like Amazon Bedrock and Copilot Studio. Your logic and prompts with their model, their runtime, their connectors, and their inheritance rules.

You build them. A smaller group of teams assembles their agents from open frameworks on infrastructure they own and operate end to end. This is the classic "we built it" case: your repo, your servers, your review process.

Here's why this matters in terms of allocating security budget: the vast majority of agent adoption comes through the first two launch vectors — inherited and built-on-platform — and both are growing exponentially as every major application becomes an agent platform in its own right. The third vector, DIY-on-your-own-infrastructure, is the smallest and slowest-growing. It is also the only one with a formal decision point: a repo to scan, a gateway to deploy, a build to gate.

This is why most AI security tooling secures the third vector. The first-party toolkit (i.e., model scanning, prompt inspection, gateway enforcement) naturally extends to the case where you own the whole stack. It was built for the world where you build it yourself. That world is now the exception.

The agents you inherit fail through the application

We’ll start with the biggest launch vector, because it's the one the industry's mental model handles worst. The biggest vendors just spent the last year demonstrating why it’s the bucket that matters most.

As discussed in Chapter 1, enterprise applications have spent the past year releasing integrations that turn your live data into the fuel an agent runs on, refreshed the moment the data changes. Here's what that looks like when it goes wrong, documented in August 2026 by Reco's research team in Salesforce Agentforce, one of the most widely deployed agent platforms in the enterprise.

In Agentforce, the recommended way to make an agent respond to events is through Flows. A record is created, a case is updated, and the flow passes data to the agent as part of its prompt. This is standard, as-designed usage. Now add one more standard, as-designed feature: Email-to-Case or Web-to-Case: the intake mechanism that airlines and hotels use to turn inbound customer emails into support tickets. Chain them and you get:

An unauthenticated outsider now has a path into an internal agent's prompt. Whatever they write in the email arrives as input the agent may treat as instruction. The agent's reply exits through the same door. Nobody misconfigured anything. Every hop is a feature, working as documented, in the configuration thousands of enterprises actually run.

This is what inherited agents look like as a security problem. The risk isn't in the agent's model or its system prompt — it's in the application around it: which intake features are enabled, which triggers fire, which objects are exposed to guest users, which automation passes untrusted data where, and which model version or unsanctioned tool the agent is quietly calling underneath it. A vendor risk review, performed once at procurement, sees none of it. A prompt filter, watching the agent's inputs, doesn't know that this particular input originated from an unauthenticated stranger — unless it understands Email-to-Case, and prompt filters don't.

To secure an inherited agent, you have to understand the application it lives in — its features, its triggers, its permission model — at the depth its own admins understand it. That depth is the whole game, and it is the one thing a vendor questionnaire and a prompt scanner both lack. Reco's research team has spent the year proving it: the City-Forum campaign — an active, worldwide data-theft operation against Salesforce and ServiceNow instances, running since March 2025 — was found in exactly this territory, in the gap between platform features and the configurations enterprises actually run.

The agents you build inherit everything underneath them

The launch vector looks more controllable — your teams, your logic — but "build" exaggerates what's actually happening. You're assembling third-party parts on third-party ground, and the failure modes live in the parts.

Start at the bottom of the stack. The model is a third-party component, and not a neutral one: Reco’s red teaming of 39 model backbones found that agents with identical scaffolding, tools, and guardrails behave differently under attack depending on which model sits underneath — some resist manipulation that others comply with. Model choice is a security decision, and most teams make it on latency and price.

Above the model sit the connectors. As explained in the previous chapter, half of public MCP servers can execute shell commands on their host, 62% can read a user's data and transmit it externally in a single package. These are the building blocks, pulled in the way engineers pull in any dependency: quickly, transitively, and without a security review per component.

Then there's the supply chain those dependencies ride in on. In March 2026, attackers compromised LiteLLM — the open-source gateway that routes agent traffic to model providers — and published two malicious versions to PyPI.1 The way in wasn't LiteLLM's own pipeline: a poisoned build of Trivy, the security scanner LiteLLM's CI pulled in automatically, leaked the credentials that let attackers push straight to PyPI, bypassing the normal release process.2 The packages were live for roughly forty minutes. A later analysis by CloudSEK put the exposure at some 434,000 CI/CD pipelines across more than 2,500 organizations: credentials, cloud keys, tokens, AI-provider keys.3 LiteLLM is exactly the kind of infrastructure a security-conscious team adds on purpose. The inspection point was the attack vector.

“Build” agents fail through inheritance: the model you didn't train, the connectors you didn't audit, the packages you didn't pin. The logic your team actually wrote is the smallest part of the attack surface — which is the quiet joke in calling this the "build" bucket at all.

The agents you DIY are the ones the market already secures

The third launch vector is the one everyone pictures when they say "We built it": open frameworks, your infrastructure, your repo, your review. It is a real category, but a shrinking one.

It's also the best-served. If you stand up an agent framework on your own servers behind your own gateway, the first-party toolkit works roughly as advertised — scan the model, inspect the prompts at the gateway, gate the build in CI. The problem is arithmetic: this bucket accounts for the smallest share of agents in the enterprise and the slowest growth, while the tooling aimed at it gets marketed as the answer to the whole problem.

And even here the ground shifts. Employees stand up open-source agents with shell access and connect them to work systems over a weekend — OpenClaw and Clawdbot each accumulated tens of thousands of deployments this year before most security teams knew the names. "DIY" becomes "shadow" the moment it happens without the repo and the review, and then it fails like the other two vectors: through what it can reach, not through the code.

The builders are multiplying — and some of them aren't human

There's a shift happening across all three launch vectors that deserves its own callout, because it breaks the last assumption hiding in the mental model: that building agents is something engineers do.

It isn't anymore. The platforms are making agent creation as accessible as making a slide deck — describe what you want in plain language, click through the connections, done. Marketing operations builds an agent. Finance builds an agent. Every one of those agents rides its creator's permissions: it can see what they see and touch what they touch, because that's the point — that's what makes it useful. Personal AI adoption and agent growth aren't two trends. They're one trend: every employee delegating their own access, one assistant at a time, to software that works while they sleep. Shadow AI was an employee pasting data into a chatbot. Shadow agents are that employee's access, running unattended, multiplied across everything they were ever granted.

And increasingly, agents build agents. A coding agent tagged into Slack can scaffold and deploy another agent as easily as it opens a pull request. An orchestration platform can spin up sub-agents to divide a task, each with its own connections, none with its own review. When creation itself is automated, the population grows at machine speed and every governance model that assumes a human requested each agent is quietly obsolete.

This is why the growth is exponential rather than linear, and why any security approach that has to be configured per-agent, per-human, and per-decision fails at the design level: it cannot scale to the challenge.

The universe they all launch into

Wherever an agent is born — inherited, built, or DIY'd — it doesn't stay where it was born. It launches into the same expanse: the enterprise application layer, hundreds of interconnected products, thousands of identities, and no fixed edges. It reads files. It queries data. It triggers actions. It touches decisions. An agent that starts life inside your CRM ends up reading from your data warehouse and writing to your ticketing system; an agent built on Bedrock ends up with tokens into Salesforce, Slack, and Drive. This layer isn't a perimeter you can walk; it's closer to open space — vast, expanding, and rarely fully mapped, because it changes too fast. The moment an agent can act across it, where the agent came from matters far less than what it can now touch.

The overwhelming majority of enterprise AI — by some estimates north of 95% — runs not as a standalone model answering questions from memory, but as a model reasoning over live, permissioned, governed access to the systems of record the business already runs on. The economics point the same direction: Workday reported AI driving more than a quarter of its new annual contract value, with 5,500+ customers running its agents — agents inside the platform, sold as the platform, growing the platform.4 The agent's tools are the application. Its knowledge is the application's data. The applications aren't being replaced by agents; they're becoming the runtime agents execute on.

That's why this is a third-party problem regardless of origin. Even the agent you DIY'd on your own infrastructure becomes a third-party problem the instant it holds an OAuth token into someone else's platform — which is to say, immediately.

Run the series' four questions (Identity, Permissions, Connectivity, and Activity) over all three agent types and the distinction dissolves:

Three ways to launch. Same four gaps. The risk is not in the agent. It's in what the agent is born into and what it can reach. Securing any of them means seeing the ecosystem as one living map of a moving universe, continuously updated, because that's the level where the chains form and the only level where you can catch them.

Which raises three more questions: whose job is owning that map, what does governing agents actually involve day to day, and why do most agent governance programs produce a policy document instead of an answer? That's Chapter 3.