In the brave new agentic world, it is no longer just about choosing an LLM; we must navigate a fragile ecosystem of third party integrations, questionable external MCP servers, tools and somehow securely put these all together. One weak link in the supply chain or poorly secured agent can cause havoc and compromise the entire architecture.

Introduction

In the second part of our Agentic Security series, we will dive into Agentic Frameworks. What is their purpose? How do they do what they do? And what security features do they provide? And finally, we will discuss how to securely design and orchestrate your own agentic systems.

We will focus on four of the most popular frameworks (LangChain, CrewAI, Autogen and n8n) and we will draw conclusions and provide security recommendations that are broadly applicable to any and all agentic framework. So that no matter which framework you're working with, there are some helpful insights to aid you in securing your agentic systems.


LangChain, LangGraph, Deep Agents, LangSmith

Overview


LangChain is an opensource project that was created by Harrison Chase in October 2022. It's purpose is to provide a "highly customisable harness" for creating agents. Since creating LangChain, they have gone on to create Deep Agents, LangSmith and LangGraph which are all designed to work with each other and extend functionality. For the sake of brevity and due to how interconnected and interdependent these frameworks are, we will talk about "LangChain" as an all encompassing term even though some features are actually Deep Agents or LangSmith for example.

LangChain is now built on top of LangGraph. LangChain provides a standardised model interface so that models can be easily switched out with minimal code changes. They define an Agent as "Model + Harness" where Model is the backend LLM and the Harness is the prompts, tools (for those less AI savvy, a "tool" is a generic term in AI/ML for code that can be executed by agents and models to perform some action), middleware etc and is responsible for providing the correct context for a given task. Returned output can be validated against a defined structure for the output. Agents may be invoked using JSON Messages for a single response or Streaming to get an update or latest response for ongoing tasks. Both of which are defined as part of the agent creation. Persistent conversation history can be enabled when the Agent is created. They provide lots of built in features and documented examples to help build out the Harness. Agents can also have sub-Agents that they can use to offload predefined workloads to in their own isolated context. This allows Agents to farm out complex tasks into sub tasks that can be completed in parallel and without taking up any of the Agent's own context. Agents may have an execution environment defined as part of their middleware that allows them to access the file systems or execute code.

LangChain Security Features

Guardrails allow users to use builtin PII Detection and to define filters to apply both before model input and after model output which can be used to help prevent prompt injection and help prevent leaking of sensitive data when correctly configured. Human-in-the-loop provides interrupts for human approval of predefined sensitive tasks and actions and can be applied to Tools, Model calls, Agent calls and pretty much all layers of the framework. Steering expands on Human-in-the-loop and allows a human to steer the process at key defined points that require human judgement. Fault tolerance provides a mechanism to handle rate limits, model timeouts and transient API errors. Sandboxes can be used to provide isolation between the agent and the host system when running code or accessing the file system however they should be used with careful planning and caution as they are not a panacea and come with their own security risks that are well documented in the official documentation.


CrewAI

Overview

CrewAI is an open source, Python based framework for building AI Agents and multi-Agent systems created by João Moura in 2023. CrewAI is split into two fundamental concepts. CrewAI Crews are the teams of multi-agents that perform delegated tasks and CrewAI Flows are the defined structured, event-driven workflows that orchestrate the system and control the agents. (As teaser for the next part in our series, CrewAI also has coding agent skills for integration Agentic Coding Platforms and can therefor also be used to orchestrate CI/CD).

Flows provide State Management which allows data to persist across steps and executions, Event-Driven Execution for triggering actions via event or external inputs and Control Flow presents conditional logic, loops and branching. Crews provide Role-Playing Agents that are specialised for specific goals and tools, Autonomous Collaboration allows agents to work together on a given task and Task Delegation allows tasks to be delegated based on agent capabilities.

Agents are defined via the Agent Builder GUI, a dedicated JSONC configuration or directly in Python code. CrewAI provides a number of granular features that can be used to define an agent. Agents may also have pre-defined access to Agent Tools. Agent Tools are defined either with the CrewAI Toolkit or via LangChain Tools. Agent output can be structured using Pydantic to create predefined structured output classes to apply to output returned from agents. Agents may connect to MCP servers and the enterprise version also extends A2A capabilities(see our previous post). They can have pre-defined Skills that tell them how to think and provide domain expertise. Additional documentation can be provided through RAG (Retrieval Augmented Generation - more on this later in our Agentic Security Series) via CrewAI's Agent Knowledge capability. CrewAI also has the concept of "Apps" which provides direct integration with SaaS apps like Jira, Salesforce, Slack etc and requires an integration API token. As mentioned above, Agents are then grouped into a Crew that carry out designated Flows.

Flows are built up from a series of defined methods with a given Flow class. Each Flow begins with a @start() decorator denoting the starting method to kick off the Flow. Successive methods in the Flow then use the @listen() decorator to denote which method they should follow on from e.g. @listen(start_method). Multiple methods may listen to the same method to enable parallel execution. The @router() decorator allows conditional execution and successive methods then listen for the appropriate output from the router. I.e. one method could have @listen("success") and another could have @listen("error") and then depending on whether the router method resulted in returning "success" or "error" (or any other pre-defined output; we're just using "success" and "error" as simple examples) the relevant method will trigger. Flows get much more advanced but this is the basic outline of how they function.

CrewAI Security Features

CrewAI has integrations for a multitude of platforms for observability, including their own - CrewAI Tracing. Human-In-The-Loop functionality exists and can be enabled in workflows to call to pre-defined webhooks; the enterprise version of CrewAI has additional Human-In-The-Loop functionality that is email first based and allows for more complex configurations. As mentioned above, CrewAI best practices suggest using Pydantic to define and enforce output types. Prompt templating exists and can be used to help secure agent prompts. The enterprise version also offers Hallucination guardrails, PII Redactions, SSO, RBAC and Secrets manager.


AutoGen

Overview

AutoGen is Microsoft's open source, Python based (with of course, a .NET flavour too), agentic framework. There is Core which is the core of the framework, AgentChat which is built on Core for building single or multi-agent conversational agent system and Studio which is a web-based UI, no code app for prototyping agents. Autogen also has built-in and community built extensions for adding additional functionality (such as MCP integration).

The framework provides a runtime environment to facilitate communication between agents. This can either be a standalone single process on a single host or a distributed system across multiple hosts with a central runtime host Servicer. In the single process format, the agents communicate via messages with the runtime and the runtime manages the lifecycle of the agents all within a single host. For the distributed architecture, the distributed agents run on agent runtime workers. The workers manage the agent's lifecycle and advertise to the host Servicer via the gateway what agents they run. The host Servicer provides communication between agents and maintains the states of connections.

Agentic messages may be sent directly using an Agent ID to message a defined agent or may be broadcast. For broadcast messages there is the concept of Topic and subscription. The @type_subscription(topic_type="some_Topic") decorator may be used to subscribe a class to a given Topic. An agent can then broadcast messages to the predefined Topic by setting up a publish_message() method within its class and set the associated TopicId to publish to a given Topic. Messages are serialised objects and may be defined using the @dataclass decorator or a subclass or pydantic.basemodel.

AutoGen also supports Tools natively and also has an adapter to enable the use of LangChain Tools.

AutoGen Security Features

AutoGen uses Python's built in logging module and offers Trace Logging for human readable debugging in development and Structured Logging that creates structured events to be consumed by other systems. AutoGen also natively supports Open Telemetry for tracing and observability. The framework uses Pydantic SecretStr to help keep sensitive data secret (though this is a suggestion and not strictly enforced).


n8n

Overview

n8n stands out from the other frameworks by being a visual, node based editor for agentic orchestration and workflow automation that provides the option of customising nodes with JavaScript or Python; whereas all the other frameworks we have looked at have a visual editor built on top of the coding framework. It was founded by Jan Oberhauser and launched in November 2019. n8n is built on Node.js and TypeScript. n8n can be self-hosted or run on n8n Cloud. For the full version, end users must use the Business or Enterprise plan.

Workflows are made up of nodes. Nodes are either a Trigger that responds to a specified event (i.e. a schedule trigger to time a workflow's start) or an Action that performs some specific task (i.e. an external integration with some external API). The output of one node is then fed into the input of one or more nodes and the flow of data from one node to the next, together with triggers, forms the execution flow of the workflow (for the engineers and scientists out there, this is very like a simplified version of LabView). Node behaviours can be customised some of which include: Always Output Data, Execute Once, Retry on Fail, On Error Attributes and Custom Span Attributes. Related nodes may be grouped into a Canvas Group to help organise your code (this can also help with developing re-usable code that can be used with other projects). Canvas Groups can be collapsed from view to help make the code more readable. Documentation and comments are added via Sticky Notes placed on the canvas (canvas is the term used for the visible workspace that you code on).

n8n also supports Agents (of course!) which consist of:

  • Model - the LLM powering the Agent
  • Instructions - the agent's system prompt
  • Tools - actions the Agent can take (including MCP integrations)
  • Skills - these are reusable behaviours that package instructions for use with Tools for specific tasks
  • Channels - communication methods for interacting with an Agent (Slack, Telegram or Linear)
  • Schedules - Tasks an Agent runs on a reoccurring basis while running
  • Sub-agents - Agents that this Agent can delegate tasks to
  • Knowledge base - files the Agent can read and search for context
  • Memory - Session Memory keeps the current conversation and Episodic Memory recalls previous context from earlier sessions.

There is an Agent Builder to enable users to build agents. Once created, Agents must be Published to make it available. Once Published an Agent may be used in a workflow (either directly as part of the data flow or indirectly called from a workflow) and the may also be set to run on a schedule outside of any workflow.

n8n Security Features

Logging to file is available in all versions of n8n and has the standard silent, error, warn, info, debug levels. Workflow and node traces can be exported to an OpenTelemetry Collector using OTLP. Execution data redaction allows for redaction of sensitive input and output data (i.e. PII, enforcing least privilege principle etc). Agent Tools may be set to Sensitive to require approval before an Agent may run them. Business and Enterprise n8n also include: External secrets, Environments, Log Streaming, SSO (SAML and LDAP). The n8n user interface may also be configured with a number of security related settings including MFA, blocking user access to environment variables, whether users can publish and share from their personal spaces and a few other features.


Conclusions

We've chosen the most popular frameworks to examine but many exist and many more will exist in the very near future. The conclusions and security recommendations made here are however broadly applicable to all agentic frameworks. So hopefully this will be useful regardless of the framework you choose to implement.

Each of the frameworks we've covered here take slightly different approaches but with some broad similarities and trends. Each framework has some security features but it is noticeable that no one framework is complete in its security offerings and they all offer slightly different things. It's important to make use of these features where they exist but no one framework is secure by design. All of the frameworks covered have the potential to build some very powerful agentic systems and each one can be secure if done right.

It is also important to note that these framework have had multiple high severity security issues identified within the frameworks themselves. In fairness, this happens to all software and it's unfair to expect agentic frameworks to magically be immune to this. However, it is a good reminder to keep a close eye on security announcements and updates for any framework that you are using.

This brings us on to another important point that we touched on during our protocol discussion and is worth repeating. Supply chain. All of these frameworks allow third party extensibility via third party MCP servers and platform specific integrations. This is in fact where these platforms become really useful for agentic automation which further increases the likelihood of supply chain exposure. So all third party MCP servers/integrations/software should be carefully vetted and monitored.

Again we come back to a similar set of security recommendations and yet again it is up to the end user to architect and implement a secure design. No one framework offers a complete set of security tools and security is a conscious design choice rather than the default.

Security Recommendations


If you are building an agentic system using any framework (listed here or not) then the following security recommendations will help you keep your system secure.

- Principle of least privilege access
- RBAC that follow the above point, are specific to the agent using it and are closely monitored
- Input and output filtering of all data any time it crosses a trust boundary e.g. user -> agent, file -> api, agent -> MCP server etc.
- Prompt injection protections against all data sent to agents and LLMs
- Clear and specific roles for each agent that are well specified and well segregated (Note that an agent may reasonably requite multiple RBAC roles but there should be a good reason for it hence making this a separate recommendation)
- Where ever possible, isolate users and make agents use the user's access to access data (as opposed to giving agents DBA for example)
- Human-in-the-loop for any remotely sensitive action
- Secure and specific prompts for agents and LLMs
- Behavioural monitoring of agents with alerting configured to produce warning when agents are going off script
- Logging of agent actions and decisions
- Sandboxing of agents and environments; especially when performing sensitive actions such as code execution
- Rate limiting to prevent DoS and denial of wallet attacks (setting hard limits for token usage can also help but may inadverntly result in a DoS if an attacker or rogue agent exhausts the token supply)
- Third party security assurance of the design and implementation (Threat Modelling and AI Red Teaming)

// Tags