Skip to content
Back to Projects

SecOps AI Agent

Autonomous agent connected to Slack, GitHub, Jira, and internal APIs. Handles access requests, validates user groups, generates Terraform, and opens PRs.

AWS_BEDROCK AGENTCORE TERRAFORM PYTHON STRANDS_SDK
SecOps AI Agent architecture diagram
Click to expand

Overview

An autonomous SecOps agent that lives in Slack and handles security operations end-to-end. Engineers interact with it through DMs and app mentions. The agent understands context from conversation history, executes multi-step workflows, and reports back with results.

Architecture

Core Engine

The system is built on the Strands Agents SDK, using AWS Bedrock as the LLM backbone. An Orchestrator Agent coordinates domain-specific sub-agents, each loaded with skills relevant to its area. Conversation context and tool execution state are persisted through AgentCore Memory, with an in-memory cache layer for fast retrieval of recent interactions.

Sub-Agent Orchestration

The Orchestrator delegates to specialized sub-agents based on the task:

  • github_agent - PR creation, repo permissions, automated status checks
  • aws_agent - IAM policies, resource provisioning
  • gcp_agent - BigQuery, API keys, project configuration

Each sub-agent loads a set of skills (tool definitions) scoped to its domain. The Orchestrator also maintains direct Jira tools for ticket operations that need real-time bidirectional sync, without routing through a dedicated Jira sub-agent.

Input Layer

The agent connects to Slack via Socket Mode, with no public endpoints exposed. It handles both direct messages and app mentions, maintaining separate conversation threads per user and channel.

Integration Layer

A single Backend API serves as the unified integration layer, fanning out to GitHub, Jira, AWS, and GCP. The Orchestrator’s direct Jira tools bypass this layer for lower-latency ticket operations.

Runtime & Security

Runs as an EKS pod with strict security hardening:

  • Non-root container execution
  • Read-only root filesystem
  • Least privilege IAM roles scoped to exact API actions needed
  • No host PID/network sharing

Workflow Example

  1. Engineer messages the agent in Slack: “I need read access to the payments-service repo”
  2. Orchestrator delegates to github_agent to verify the repo exists and identify the engineer’s team
  3. github_agent returns the details. Orchestrator confirms with the engineer: “Found payments-service. You’re in the backend-platform team, correct?”
  4. Engineer confirms. Orchestrator asks: “What do you need this access for?”
  5. Engineer provides the reason. Orchestrator opens a Jira ticket capturing the full request context
  6. Orchestrator delegates to github_agent to open a PR in the infrastructure repo, adding read access for backend-platform to payments-service via Terraform
  7. github_agent updates the Jira ticket with the PR link and a summary of its actions
  8. Orchestrator posts a formatted notification to the SecOps team’s private Slack channel, with the request summary and embedded buttons (with icons) linking to the Jira ticket and GitHub PR
  9. Orchestrator confirms back to the engineer: “Done. A PR is open for SecOps review. You’ll get access once it’s approved and merged.”