Aws Bedrock | Techlist.io

figmaJul 29, 20262 min readCurated summary

How We Secure Figma’s Internal Systems With Agents | Figma Blog

Figma built an AI-powered security agent to reduce the manual work involved in investigating SIEM alerts. What began as a retrieval system for finding similar past incidents evolved into an agent that investigates alerts, queries security data, writes fixes, opens pull requests, and retains useful knowledge. The system reportedly reduced alert time-to-resolution by 71% and changed how security engineers handle on-call work. ## The Challenge of Internal Security Operations - Figma’s infrastructure, SaaS tools, identity systems, and employee devices change constantly. - Panther, Figma’s SIEM, monitors these systems and sends alerts to Slack while creating Asana tickets. - On-call engineers previously spent significant time gathering context: - Comparing alerts with incidents from the previous week - Checking whether an existing pull request addressed the issue - Searching Slack discussions for related investigations - Determining whether an alert was new, recurring, or already understood - Existing agent work focused on securing Figma’s codebase, but the team needed a broader system for the many issues detected by its SIEM. ## The RAG Layer: Giving Alerts Historical Context - Figma first created a retrieval-augmented generation system using: - AWS Bedrock Knowledge Bases - Amazon Kendra - Lambda handlers connected to Panther - Each Panther alert is converted into a standardized searchable document. - The system extracts structured information such as: - IP addresses - Usernames and actors - AWS account IDs from ARNs - Alert type, severity, tags, status, and timestamps - Similar alerts are retrieved semantically using the alert title, typically containing the detection name and actor username. - Searches prioritize: - Recent alerts, since investigation procedures evolve - Alerts containing actual investigation context - Comments from engineers rather than merely closed alerts ## Turning Engineer Comments into Institutional Memory - When an on-call engineer comments in a Slack alert thread, Figma captures that text and attaches it to the original alert. - Asana tickets follow a similar process. - The updated alert document is reindexed with: - The accumulated investigation comments - A `has_investigation_context` flag - Future alerts can retrieve these previous explanations and recommendations. - Engineers do not need to adopt a separate annotation workflow; their normal Slack and Asana comments become reusable knowledge. - Each useful investigation effectively makes subsequent similar alerts faster and less expensive to triage. Figma’s approach demonstrates how security agents can build on existing workflows rather than requiring entirely new ones. Starting with searchable historical context allowed the team to progressively develop a broader agentic system while turning everyday investigative work into persistent operational knowledge.

Read original

Aws Bedrock AI Agents TypeScript RAG+4

slackMay 28, 20263 min readCurated summary

Slack AI: The Path to Multi-Cloud

Slack’s AI infrastructure evolved from self-managed SageMaker deployments to managed Amazon Bedrock as Slack sought enterprise-grade security, reliability, lower operational overhead, and faster access to new models. SageMaker provided strong isolation and compliance but required extensive capacity and regional management, while Bedrock simplified operations through managed throughput and on-demand options. Slack’s carefully staged migration achieved zero customer-facing incidents and established a practice of measuring parity, shifting traffic gradually, and monitoring continuously. ## Phase 1: The SageMaker Era - SageMaker offered: - Security and FedRAMP compliance - Control over model availability - An escrow VPC strategy that kept Slack data private while preventing access to providers’ model weights - Slack deployed model containers across multiple AWS regions to support global availability. - Engineering teams had to manage: - Cross-region IAM roles - Routing across model endpoints - Capacity planning - Auto-scaling - The main operational challenges were: - **Scaling latency:** New instances could not start instantly. - **GPU scarcity:** A100 and H100 capacity was often unavailable. - **Over-provisioning:** Idle resources had to be maintained for peak demand. - On-Demand Capacity Reservations and scheduled scaling reduced some problems, but required substantial manual coordination. - SageMaker also created model feature lag because AWS prioritized releasing newer Anthropic models and optimizations through Bedrock. ## Phase 2: Migrating to Amazon Bedrock By mid-2024, Bedrock had matured enough to meet Slack’s security and FedRAMP requirements. - The migration provided: - Managed infrastructure instead of individual GPU instances - Faster access to newly released LLMs - Flexible capacity options for different workload patterns - Slack used: - **Provisioned Throughput (PT)** for predictable, latency-sensitive features such as channel summaries - **On Demand (OD)** for bursty scheduled workloads such as Recap - Bedrock measured capacity in **Model Units (MUs)**, letting Slack plan around token throughput rather than hardware details. ## Executing a Zero-Incident Migration Slack used a gradual, validation-heavy process: - Obtained Legal, Security, and FedRAMP approval before moving production traffic. - Performed load testing to determine the number of MUs needed to match SageMaker capacity. - Compared model quality and latency through A/B tests and evaluation frameworks. - Used feature flags for incremental traffic shifting and immediate rollback. - Ran shadow requests and extensive tests to verify behavioral and performance parity. This approach allowed Slack to move live production traffic without customer-facing incidents. ## Operational Improvements and Remaining Gaps - Bedrock reduced infrastructure maintenance, allowing engineers to focus more on model quality and product features. - Slack could adopt new models weeks or months earlier, improving features such as AI Search with higher-reasoning models. - Capacity planning shifted from reactive scaling to forecasting demand several weeks ahead. - Provisioned Throughput still required maintaining a high baseline of MUs to handle large regional workday surges, creating an over-provisioning challenge for traffic that varies significantly throughout the day. Slack’s migration demonstrates that managed AI infrastructure can improve agility and reliability, but success depends on careful capacity modeling, comprehensive parity testing, gradual rollout, and continuous monitoring.

Read original

Aws Bedrock Large Language Models Model Serving Gpu+3

daangnDec 23, 2025Original article

Karrot Pay's (opens in new tab)

Daangn Pay has evolved its Fraud Detection System (FDS) from a traditional rule-based architecture to a sophisticated AI-powered framework to better protect user assets and combat evolving financial scams. By implementing a modular rule engine and integrating Large Language Models (LLMs), the platform has significantly reduced manual review times and improved its response to emerging fraud trends. This transition allows for consistent, context-aware risk assessment while maintaining compliance with strict financial regulations. ### Modular Rule Engine Architecture * The system is built on a "Lego-like" structure consisting of three components: Conditions (basic units like account age or transfer frequency), Rules (logical combinations of conditions), and Policies (groups of rules with specific sanction levels). * This modularity allows non-developers to adjust thresholds—such as changing a "30-day membership" requirement to "70 days"—in real-time to respond to sudden shifts in fraud patterns. * Data flows through two distinct paths: a Synchronous API for immediate blocking decisions (e.g., during a live transfer) and an Asynchronous Stream for high-volume, real-time monitoring where slight latency is acceptable. ### Risk Evaluation and Post-Processing * Events undergo a structured pipeline beginning with ingestion, followed by multi-layered evaluation through the rule engine to determine the final risk score. * The post-processing phase incorporates LLM analysis to evaluate behavioral context, which is then used to trigger alerts for human operators or apply automated user sanctions. * Implementation of this engine led to a measurable decrease in information requests from financial and investigative authorities, indicating a higher rate of internal prevention. ### LLM Integration for Contextual Analysis * To solve the inconsistency and time lag of manual reviews—which previously took between 5 and 20 minutes per case—Daangn Pay integrated Claude 3.5 Sonnet via AWS Bedrock. * The system overcomes strict financial "network isolation" regulations by utilizing an "Innovative Financial Service" designation, allowing the use of cloud-based generative AI within a regulated environment. * The technical implementation uses a specialized data collector that pulls fraud history from BigQuery into a Redis cache to build structured, multi-step prompts for the LLM. * The AI provides evaluations in a structured JSON format, assessing whether a transaction is fraudulent based on specific criteria and providing the reasoning behind the decision. The combination of a flexible, rule-based foundation and context-aware LLM analysis demonstrates how fintech companies can scale security operations. For organizations facing high-volume fraud, the modular approach ensures immediate technical agility, while AI integration provides the nuanced judgment necessary to handle complex social engineering tactics.

Aws Bedrock AI Large Language Models Redis+5