Authors:
- Subesh Bhandari - Software Engineering Team Lead - Plerion
- Kevin Low - Security Solutions Architect, AWS
- Benny Chun - Startup Solutions Architect - AWS
Cloud-security teams today face a simple math problem: alerts multiply while headcount stays flat. Dashboards overflow, but there aren’t enough engineers to clear the queue.
Customers grapple with this reality every day, and as a Cloud-Native Application Protection Platform (CNAPP) provider, Plerion sees it up close. That’s why they built Pleri: an AI teammate who continuously watches your AWS estate, decides what truly matters, and fixes (or drafts the fix for) issues before anyone’s pager lights up.
In “How to Build an AI Teammate, Not a Chatbot,” we explained the philosophy behind Pleri. This article moves from why to how, showing how an idea born from overstretched security teams became running code on AWS.
From Chatbots to Teammates — Lightning Recap
Generative AI tools come in multiple shapes and forms, such as chatbots, agents and teammates. How are they different?
- Chatbots wait for input. Helpful, but the user does all the steering.
- Agents can act once prompted, yet still rely on someone else’s priorities.
- Teammates absorb context—conversations, metrics, alerts—and decide when to jump in. They suggest, negotiate, follow through and learn.
Our bar is that last tier: a digital colleague who behaves like a seasoned cloud-security engineer.
Anatomy of an AI Teammate — Pleri’s Serverless Architecture
Figure 1. Pleri’s overall architecture
Pleri is built on a serverless AWS foundation using services like AWS Bedrock, AWS Lambda, Amazon Aurora, API gateway, CloudFront, and Event Bridge, ensuring scalability and resilience without the need to manage underlying infrastructure. The architecture can be broken down into two main parts: the plumbing that connects Pleri to your environment, and the agent brain that does the thinking.
The Plumbing: Core Infrastructure
Figure 2. The Plumbing: Core Infrastructure
This is the connective tissue of our system. It’s responsible for ingesting signals from various sources and routing them to the agent for processing.
- Interaction Components: We use dedicated AWS Lambda functions to handle incoming events from various communication channels.
- A Slack Event Listener processes mentions and commands from chat. Security teams can interact with Pleri using natural language in the same channels where they collaborate. There’s no need to switch to a different application to report an issue or trigger a task. This creates a seamless, low-friction experience that integrates directly into existing workflows.
- A Jira Webhook handler listens for ticket updates. Pleri becomes an active participant in your project management process. She can automatically create or update Jira tickets, ensuring that all work is tracked and visible within your team’s single source of truth. This reduces manual data entry and keeps project boards perfectly synchronized with real-world events.
- For real-time, interactive communication, a WebSocket API (via AWS API Gateway) provides a persistent, bidirectional channel. This allows users to send commands to Pleri and receive immediate updates or stream information back, bypassing the request/response cycle of typical webhooks. This component triggers a dedicated Lambda function to process incoming WebSocket messages.
- Alerts from the regular scans of the cloud environment that are performed by the Plerion platform. Pleri is automatically triggered by alerts from the broader Plerion platform, which continuously scans your cloud environment. When these scans identify a security risk, misconfiguration, or compliance issue, an event is sent directly to the system. This allows Pleri to begin its investigation and remediation workflows proactively, without waiting for a manual report
- Self-Scheduled Task and Follow-ups. To manage complex or long-running jobs, Pleri has the built-in capability to schedule future tasks and invoke itself. This autonomy is essential for multi-step workflows, allowing Pleri to perform an action and then create a follow-up to verify the outcome later. This self-invocation ensures that processes are completed reliably over time without requiring manual oversight.
- Event-Driven Backbone: At the heart of the plumbing is Amazon EventBridge, which acts as a central bus. Events from any source, whether it’s a security feed, a Slack message, a direct alert from your AWS account, or a message received over a WebSocket connection, are published to EventBridge. This decouples the event sources from the processing logic, allowing for a flexible and scalable system that can handle both asynchronous and real-time inputs.
- Processing: Pleri is invoked by the event-driven backbone to process and respond to events and requests.
The Brains: The Pleri Agent
Figure 3. Pleri’s agentic flow
This is where the magic happens. The Pleri Agent is a sophisticated workflow that combines large language models (LLMs), long-term memory, and a suite of tools to reason about and act on security events.
Here’s a breakdown of the core components and workflows:
- Event Arrival: An event from different sources, which we covered in the previous section, gets fired into AWS EventBridge’s Event Bus and immediately triggers the Central Orchestrator Lambda.
- Memory Retrieval: Before acting, the orchestrator queries Pleri’s long-term vector store (Amazon Aurora + pgVECTOR) to fetch similar past incidents, assets, and remediation notes.
- LLM Reasoning & Planning: It then sends a combined prompt, fresh alert plus retrieved context, to Claude Sonnet 4 via AWS Bedrock, asking for analysis (“what happened” and “why it matters”) and a clear, ordered plan.
- Plan Return: Claude returns a multi-step playbook, including any necessary tool-invocation instructions.
- Tool Invocation: The orchestrator dispatches those instructions to integrations (e.g., Slack messages, GitHub pull requests, PagerDuty incidents).
- Hand-off to Task Manager: Execution results (e.g., “PR opened,” “alert acknowledged”) flow into the Task Management Lambda, which records status and metadata.
Follow-ups & Scheduling: Any commitments (“check patch in 7 days,” “verify merge next week”) are stored in DynamoDB and queued in Pleri’s scheduler, ensuring automated reminders if tasks go stale.
Under the Hood: Building an Agent with LangGraph.js
To structure the agent’s logic, we use powerful open-source frameworks like LangChain and LangGraph. They provide a robust way to chain together LLMs, tools, and data sources. The ReAct (Reasoning and Acting) agent framework is particularly useful. Here’s a simplified TypeScript example of how to construct a Pleri-like agent. This code runs in AWS Lambda.
import { createReactAgent } from "langchain/agents";
import { ChatBedrock } from "@langchain/community/chat_models/bedrock";
import { createTool, Tool } from "langchain/tools";
// --- Define an arsenal of tools for the agent ---
// 1. A Plerion tool for cloud visibility
const plerionVisibilityTool = createTool({
name: "plerion-cnapp-visibility",
description: "Queries the Plerion CNAPP to find cloud assets or vulnerabilities.",
func: async (input: string) => `Found 3 EC2 instances with the NGINX vulnerability.`
});
// 2. A Slack tool for team communication
const slackTool = createTool({
name: "slack-poster",
description: "Posts a message to a specified Slack channel.",
func: async (input: string) => `Message successfully posted.`
});
// 3. A GitHub tool to create Pull Requests
const githubPRTool = createTool({
name: "github-pr-creator",
description: "Creates a pull request in a GitHub repository.",
func: async (input: string) => {
// In a real app, you'd parse input like { repo, title, head, base }
console.log(`[GitHub Tool] Creating PR with details: ${input}`);
return `Successfully created PR.`;
}
});
// --- Configure and create the agent ---
const llm = new ChatBedrock({
model: "us.anthropic.claude-sonnet-4-20250514-v1:0",
region: "us-east-1",
});
// Add all tools the agent can use
const tools: Tool[] = [plerionVisibilityTool, slackTool, githubPRTool];
const agent = await createReactAgent({
llm,
tools,
prompt: `You are Pleri, a proactive AI security teammate. Use your tools to investigate and fix security issues, then report the status. Think step-by-step.`,
});
// --- Invoke the agent and process its output stream ---
async function runAgent(input: string) {
const agentResponse = await agent.invoke({ input });
console.log("--- Final Response ---");
console.log(agentResponse.output);
}
runAgent("Find vulnerable NGINX servers, open a PR to patch the 'nginx-service' repo using the 'plerion/patch-123' branch, and then notify the #security-alerts channel.");
High-Level Walkthrough: From Signal to Solution
Figure 4. High-level walkthrough of the sequence
Here’s a high-level look at how these components work together to solve a problem:
- Ingestion: A scheduled task (e.g., a cron-driven Lambda or a continuous monitoring service) detects an alert. For instance, it identifies that an existing Lambda function is running on an outdated runtime, such as Python 3.9, which is approaching end-of-life or has known vulnerabilities. This event is then published onto Amazon EventBridge.
- Reasoning: The Agent Lambda receives this event from EventBridge. It then uses AWS Bedrock to formulate a plan. For example: “Since critical production Lambda functions are on an outdated Python 3.9 runtime, I will identify all affected functions, draft code changes to upgrade them to Python 3.12, open pull requests for the respective development teams, and notify the #devops and relevant team channels in Slack.”
- Execution: The agent executes its plan by calling its registered tools. The GitHub tool is used to branch the code (if needed) and open PRs with the proposed runtime and code changes (Bedrock can assist in generating these code snippets). The Slack tool then posts a detailed, human-friendly message to the #devops and affected team channels, including links to the PRs and a summary of the issue.
Example: Pleri Proactively Patches a New CVE with a Web Search Tool
As part of the Plerion CNAPP solution, Pleri doesn’t just wait for alerts—it actively hunts for threats.
- Source: A scheduled task.
- Trigger: Every hour, a “vulnerability-watch” task fires within the Pleri agent.
- Tool Execution: The agent invokes its Web Search Tool. It is configured to query trusted sources like the National Vulnerability Database (NVD) and cybersecurity news sites for recently disclosed vulnerabilities related to key technologies in your stack (e.g., “new NGINX vulnerability” or “critical Jenkins plugin RCE”).
- Reasoning: The search results are fed into the Agent Lambda. The LLM at its core parses the articles to understand the nature of the vulnerability and the affected versions. It then queries Pleri’s internal asset inventory (stored in its vector memory) to determine if any running services are vulnerable.
- Plan & Execution: Upon finding a match, the LLM generates a plan:
- File a “Critical” Jira ticket detailing the CVE and listing the affected services.
- Post a high-priority message to the #security-alerts Slack channel with a link to the CVE and the Jira ticket.
- For services where a patched version is available, open a draft Pull Request to update the dependency and tag the relevant team for review.
- Outcome: Your team is alerted to a potential zero-day threat within hours of its public disclosure, with a clear impact analysis and remediation steps already prepared. Pleri acts as a force multiplier, giving your security team a crucial head start.
Picking a model that makes sense
After extensive experimentation with a range of powerful models—including Anthropic’s Claude 4 Sonnet, Claude 3.5 Haiku, Amazon Nova Pro, and Nova Lite—we landed on a strategic, hybrid approach for Pleri.
For the majority of our complex reasoning and agentic workflows, we chose Claude 4 Sonnet. Its superior ability to understand nuanced instructions, execute multi-step plans, and interact with tools reliably makes it the clear winner for powering Pleri’s core brain. When we need our AI teammate to think like a seasoned security engineer, Claude 4 delivers.
However, intelligence isn’t the only factor. We strategically employ a mix of Amazon Nova models for two key reasons:
- Unmatched Speed: For high-volume tasks like the initial triage of thousands of alerts, the low latency of the Nova models is essential. They allow us to process information at a scale and speed that would be cost-prohibitive with larger models.
- AWS-Native Remediation: We found Amazon’s own models to be exceptionally effective at generating AWS-specific remediation steps. When Pleri needs to draft an IAM policy, generate a CLI command, or create a CloudFormation snippet, the Nova models provide accurate, ready-to-use solutions that feel native to the AWS ecosystem.
By combining the premier reasoning of Claude 4 with the specialized speed and AWS fluency of the Nova family, we get the best of all worlds—creating an AI teammate that is not only smart but also fast and deeply integrated into the environment it protects.
This is the toolkit that works for our workflow, but yours will be unique. You have to experiment. Remember the fundamental trade-off: some models are fast, some are smart, and some are cheap—but you don’t get all three. The best approach is to test them against your specific use cases and find the combination that gives your team the right balance of performance and cost.
Your Turn to Build
The principles behind Pleri aren’t magic; they’re a blueprint. The tools to build your own AI agent are more accessible than ever. Think about your own workflow—what repetitive task could an AI teammate take off your plate?
Frameworks like LangGraph and services like AWS Bedrock provide the foundation. By starting small, you can build an agent that handles the noise, freeing your team to focus on what matters. The goal is to create a true collaborator that augments your expertise. Build your own or take Pleri for a spin today and see how an AI teammate can accelerate your security productivity.
