Key Components Of Agentic Architectures: Tool Integration Frameworks

Securing Agents when the ecosystem is the stack, plus how developer expertise impacts security from supply chain down–and how to build the right team | Edition 21

The OWASP GenAI Security Project released their Securing Agentic Applications Guide v1.0, and it’s full of valuable guidance on Agentic systems. There’s a ton of information–so I’m breaking it down here.

In this series, I’ll be laying out some of the ways that Key Components (KCs) of Agentic AI deployments expose Agentic systems to threats–and how we can think about and model these threats effectively.

There are six (6) KCs defined in the Guide, and together, they form a bedrock understanding of how Agentic architectural components function–from a security point of view. You can find the previous edition, on Agentic Key Component Group 4 (KC4), here.

—

A question that is asked endlessly in industry right now: What makes a system Agentic?

This is a question that we’ve examined from several perspectives in this newsletter. Because in my experience, there is no single, component-level definition of Agentic deployments.

Most arguments end up resorting to function. And while it’s not wrong to define a tool by what it does, when we move from simple tooling to complex, multi-component machinery, we need to evaluate whether our definitions still hold up.

What Does Your AI Factory Build?

AI deployments are complex; Agentic AI is no different. Analogizing a functioning MLOps-first platform with a factory–in terms of moving parts and complexity–is an apt comparison to make.

To say a factory is a place that makes things is technically true, but the lack of specificity begs for more information: What kind of things, and how are they made, and what components contribute to their production, and in what ways?

What does our Agentic AI factory make?

We can say that AI makes inference. We can also say that Agentic AI uses these inference capabilities to accomplish tasks.

The bridge to how these tasks are accomplished–the needed specificity in defining our AI factory–is in the integration frameworks that give Agents the power to move from inference to action.

Key Component 5 (KC5): Tool Integration Frameworks

Think about AI Agents without APIs or the internet. What exactly would they do?

Without such access, the infamously ubiquitous travel agent use case becomes useless even in theory.

If your Agents can’t use external systems to accomplish tasks, what are you even deploying?

AI isn’t Agentic until it can act irl. Without this ability, Agents are nothing more than chatbots.

Agents also can’t interact directly with real world tools unless system developers empower them to–and that requires a technical bridge.

Tool integration frameworks are a bridge to the tools themselves, managing the selection and use of tools to meet system requirements.

AI Agents without the tool integration frameworks that enable them to act are effectively powerless.

And this should immediately trigger breakers to realize: this is an attack vector.

Integral Components, Endless Attack Surface

Tool Integration Frameworks represent group five (KC5) of Agentic AI’s Key Components, because without these integrations, Agentic AI remains solely in the world of text–not real-world actions. KC5’s components extend Agents capabilities from the world of text, to actions taken on or using external tools.

Without the key components in KC5, Agents would quite literally be all talk and no action.

Which tools, and how these are connected, depends on the task at hand and the engineering constraints faced.

One technology stands out for enabling Agents to take a leap forward: the Application Programming Interface (API). API access allows Agents to theoretically get up-to-date information, potentially in real- or near-real time.

Without API access, it would be difficult for many Agentic use cases to even exist.

Go ahead and name your top 5-10 Agentic application ideas from top-of-mind; it’s likely that at least one (if not most) would functionally rely on an API for access to data like search results, stock market values, etc.

Many Agents won’t just interact with APIs–they could also touch data stores, functions, or other systems within the organization. These each come with their own supply chain issues and vulnerabilities.

Mapping these interactions is a difficult–and unsolved–problem.

The first important point to remember is that Agents can act–and for Agentic use cases, the possibilities are nearly endless.

The second point is that in a sea of potential use cases, each with its own mix of tools and interconnections, Agentic security relies heavily on understanding the risks of these tools/frameworks, and securing their interactions.

Levels Of Control

There are three subcomponent areas under the KC5 group: KC5.1 Flexible Libraries / SDK Features; KC5.2 Managed Platforms / Services; and KC5.3 Managed APIs.

KC5 Subcomponent Areas

• KC5.1 Flexible Libraries / SDK Features

• KC5.2 Managed Platforms / Services

• KC5.3 Managed APIs

Let’s break these down.

KC5.1 Flexible Libraries / SDK Features: For developers, you can’t get more powerful than this class of components. These provide building blocks that devs can use to integrate tooling capabilities into their Agentic deployments.

Examples:

• LangChain

• AG2

• CrewAI

• MCP

The key to remember for this group is that these are tools for developers. They offer a high degree of control for tasks like orchestration, down to granular control of Agentic behavior itself.

The trade off here is that these tools require developer-level expertise to deploy.

KC5.2 Managed Platforms / Services: These are solutions provided by specific vendors, with the intent of making Agentic development friendlier to a wider variety of expertise levels. They might simplify setup by handling infrastructure or orchestration or both, or even managing the build itself.

Examples include the infamously insecure Microsoft Copilot Platform, as well as Amazon Bedrock Agents.

The ease of integration comes with a tradeoff of its own: the platform locks the Agentic system into a specific ecosystem–and also removes some of the flexibility associated with deploying Agents from scratch.

This is the exchange: Lower code requirements, ease of development, and faster time to deployment come with less choice over the deployment specifics.

KC5.3 Managed APIs: While managed platforms might offer a cohesive ecosystem for Agentic development & deployment, managed APIs provide higher-level abstractions with the focus on the API. OpenAI’s Assistants API is one such example.

In principle, these take care of the complexities of deploying AI Agents, including state management and overall orchestration, but still require some advanced developer know-how to manage and deploy.

Teams may see a benefit in using these systems from striking a balance between ease of implementation and granular control. Ultimately, an experienced team with a goal of building stateful Agents having a high degree of in-task flexibility might be well served by using managed APIs.

Agentic Due Diligence Becomes More Important–And Even Harder

Some vendors have taken advantage of what might look like a fine line between true Agentic deployments and sparkling chatbot-chained-workflows, leading to a mini crisis around exactly who can be trusted when it comes to Agentic AI.

The documented security incidents we’ve already seen have not helped matters.

From my place in the industry, the erosion of trust is palpable. I’ve had multiple investors tell me the difficulty in doing due diligence on allegedly Agentic ventures is unsustainable without a sea change in expectations and capabilities.

While startups are pitching, the expertise gap is only growing.

Meanwhile, the systems that support Agentic deployments are seeing increased demand–while also introducing their own vulnerabilities of both the in-house and supply chain variety.

That’s a lot.

Now, more than ever, smart money seeks out understanding of the components that hold Agentic deployments together–and make them possible to break.

Secure Development Requires Securing Components

To act in the real world, Agents need tools. To interact with tools, Agents still need help.

That’s where KC5’s integration frameworks come into play, bringing their attack surfaces–architectural, supply chain or otherwise–along with them.

KC5 components might be the glue that holds Agentic capabilities together. Or they might constitute the Agentic ecosystem itself.

To say that KC5 components are integrated into many layers of the Agentic stack doesn’t really do them justice: In many cases, they are the Agentic stack.

Secure accordingly.

The Threat Model

• Proposed use cases for Agentic systems cover a wide swath of applications and tools; while in theory the engineering possibilities are nearly endless, in practice, so are the attack vectors.

• Tools enable Agents to act in the real world, and their connection and enablement points either help or harm security for Agents–so Agentic security relies heavily on due diligence and proper evaluation of these components and their integration, at every design phase.

• As Agentic offerings explode onto the market, and as their supply chain attack surface expands alongside, who gets contracts and funding should be directly tied to securing the components that drive Agentic possibilities–but the talent gap makes evaluating this harder than ever.

Resources To Go Deeper

• Sapkota, Ranjan, Konstantinos I. Roumeliotis and Manoj Karkee. “AI Agents vs. Agentic AI: A Conceptual Taxonomy, Applications and Challenges.” Inf. Fusion 126 (2025): 103599.

• Krishnan, Naveen. “Advancing Multi-Agent Systems Through Model Context Protocol: Architecture, Implementation, and Applications.” ArXiv abs/2504.21030 (2025): n. Pag.

• Deng, Zehang, Yongjian Guo, Changzhou Han, Wanlun Ma, Junwu Xiong, Sheng Wen and Yang Xiang. “AI Agents Under Threat: A Survey of Key Security Challenges and Future Pathways.” ACM Computing Surveys 57 (2024): 1 - 36.

Executive Analysis, Research & Talking Points

3 Stress Areas, 3 Ways To Attack

The three subcomponents of KC5 are directly tied to the expertise of the developers deploying them, which means that your ability to both choose–and secure–these frameworks depends heavily on available talent. But that’s not all.

When it comes to attacking and defending KC5’s tool integrations, three things immediately catch my eye: