The DevSecOps Talks Podcast

Andrey and Mattias share a fast re:Invent roundup focused on AWS security. What do VPC Encryption Controls, post-quantum TLS, and org-level S3 block public access change for you? Which features should you switch on now, like ECR image signing, JWT checks at ALB, and air-gapped AWS Backup? Want simple wins you can use today?

 

We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

DevSecOps Talks podcast LinkedIn page

DevSecOps Talks podcast website

DevSecOps Talks podcast YouTube channel

---

Summary

In this episode, Andrey and Mattias deliver a security-heavy recap of AWS re:Invent 2025 announcements, while noting that Paulina is absent and wishing her a speedy recovery. Out of the 500+ releases surrounding re:Invent, they narrow the list down to roughly 20 features that security-conscious teams can act on today — covering encryption, access control, detection, backups, container security, and organization-wide guardrails. Along the way, Andrey reveals a new AI-powered product called Boris that watches the AWS release firehose so you don't have to.

Key Topics

AWS re:Invent Through a Security Lens

The hosts frame the episode as the DevSecOps Talks version of a re:Invent recap, complementing a FivexL webinar held the previous month. Despite the podcast's name covering development, security, and operations, the selected announcements lean heavily toward security. Andrey is upfront about it: if security is your thing, stay tuned; otherwise, manage your expectations.

At the FivexL webinar, attendees were asked to prioritize areas of interest across compute, security, and networking. AI dominated the conversation, and people were also curious about Amazon S3 Vectors — a new S3 storage class purpose-built for vector embeddings used in RAG (Retrieval-Augmented Generation) architectures that power LLM applications. It is cost-efficient but lacks hybrid search at this stage.

VPC Encryption and Post-Quantum Readiness

One of the first and most praised announcements is VPC Encryption Control for Amazon VPC, a pre-re:Invent release that lets teams audit and enforce encryption in transit within and across VPCs. The hosts highlight how painful it used to be to verify internal traffic encryption — typically requiring traffic mirroring, spinning up instances, and inspecting packets with tools like Wireshark. This feature offers two modes: monitor mode to audit encryption status via VPC flow logs, and enforce mode to block unencrypted resources from attaching to the VPC.

Mattias adds that compliance expectations are expanding. It used to be enough to encrypt traffic over public endpoints, but the bar is moving toward encryption everywhere, including inside the VPC. The hosts also call out a common pattern: offloading SSL at the load balancer and leaving traffic to targets unencrypted. VPC encryption control helps catch exactly this kind of blind spot.

The discussion then shifts to post-quantum cryptography (PQC) support rolling out across AWS services including S3, ALB, NLB, AWS Private CA, KMS, ACM, and Secrets Manager. AWS now supports ML-KEM (Module Lattice-Based Key Encapsulation Mechanism), a NIST-standardized post-quantum algorithm, along with ML-DSA (Module Lattice-Based Digital Signature Algorithm) for Private CA certificates.

The rationale: state-level actors are already recording encrypted traffic today in a "harvest now, decrypt later" strategy, betting that future quantum computers will crack current encryption. Andrey notes that operational quantum computing feels closer than ever, making it worthwhile to enable post-quantum protections now — especially for sensitive data traversing public networks.

S3 Security Controls and Access Management

Several S3-related updates stand out. Attribute-Based Access Control (ABAC) for S3 allows access decisions based on resource tags rather than only enumerating specific actions in policies. This is a powerful way to scope permissions — for example, granting access to all buckets tagged with a specific project — though it must be enabled on a per-bucket basis, which the hosts note is a drawback even if necessary to avoid breaking existing security models.

The bigger crowd-pleaser is S3 Block Public Access at the organization level. Previously available at the bucket and account level, this control can now be applied across an entire AWS Organization. The hosts call it well overdue and present it as the ultimate "turn it on and forget it" control: in 2026, there is no good reason to have a public S3 bucket.

Container Image Signing

Amazon ECR Managed Image Signing is a welcome addition. ECR now provides a managed service for signing container images, leveraging AWS Signer for key management and certificate lifecycle. Once configured with a signing rule, ECR automatically signs images as they are pushed. This eliminates the operational overhead of setting up and maintaining container image signing infrastructure — previously a significant barrier for teams wanting to verify image provenance in their supply chains.

Backups, Air-Gapping, and Ransomware Resilience

AWS Backup gets significant attention. The hosts discuss air-gapped AWS Backup Vault support as a primary backup target, positioning it as especially relevant for teams where ransomware is on the threat list. These logically air-gapped vaults live in an Amazon-owned account and are locked by default with a compliance vault lock to ensure immutability.

The strong recommendation: enable AWS Backup for any important data, and keep backups isolated in a separate account from your workloads. If an attacker compromises your production account, they should not be able to reach your recovery copies. Related updates include KMS customer-managed key support for air-gapped vaults for better encryption flexibility, and GuardDuty Malware Protection for AWS Backup, which can scan backup artifacts for malware before restoration.

Data Protection in Databases

Dynamic data masking in Aurora PostgreSQL draws praise from both hosts. Using the new pg_columnmask extension, teams can configure column-level masking policies so that queries return masked data instead of actual values — for example, replacing credit card numbers with wildcards. The data in the database remains unmodified; masking happens at query time based on user roles.

Mattias compares it to capabilities already present in databases like Snowflake and highlights how useful it is when sharing data with external partners or other teams. When the idea of using masked production data for testing comes up, the hosts gently push back — don't do that — but both agree that masking at the database layer is a strong control because it reduces the risk of accidental data exposure through APIs or front-end applications.

Identity, IAM, and Federation Improvements

The episode covers several IAM-related features. AWS IAM Outbound Identity Federation allows federating AWS identities to external services via JWT, effectively letting you use AWS identity as a platform for authenticating to third-party services — similar to how you connect GitHub or other services to AWS today, but in the other direction.

The AWS Login CLI command provides short-lived credentials for IAM users who don't have AWS IAM Identity Center (SSO) configured. The hosts see it as a better alternative than storing static IAM credentials locally, but also question whether teams should still be relying on IAM users at all — their recommendation is to set up IAM Identity Center and move on.

The AWS Source VPC ARN condition key gets particular enthusiasm. It allows IAM policies to check which VPC a request originated from, enabling conditions like "allow this action only if the request comes from this VPC." For teams doing attribute-based access control in IAM, this is a significant addition.

AWS Secrets Manager Managed External Secrets is another useful feature that removes a common operational burden. Previously, rotating third-party SaaS credentials required writing and maintaining custom Lambda functions. Managed external secrets provides built-in rotation for partner integrations — Salesforce, BigID, and Snowflake at launch — with no Lambda functions needed.

Better Security at the Network and Service Layer

JWT verification in AWS Application Load Balancer simplifies machine-to-machine and service-to-service authentication. Teams previously had to roll their own Lambda-based JWT verification; now it is supported out of the box. The recommendation is straightforward: drop the Lambda and use the built-in capability.

AWS Network Firewall Proxy is in public preview. While the hosts have not explored it deeply, their read is that it could help with more advanced network inspection scenarios — not just outgoing internet traffic through NAT gateways, but potentially also traffic heading toward internal corporate data centers.

Developer-Oriented: REST API Streaming

Although the episode is mainly security-focused, the hosts include REST API streaming in Amazon API Gateway as a nod to developers. This enables progressive response payload streaming, which is especially relevant for LLM use cases where streaming tokens to clients is the expected interaction pattern. Mattias notes that applications are moving beyond small JSON payloads — streaming is becoming table stakes as data volumes grow.

Centralized Observability and Detection

CloudWatch unified management for operational, security, and compliance data promises cross-account visibility from a single pane of glass, without requiring custom log aggregation pipelines built from Lambdas and glue code. The hosts are optimistic but immediately flag the cost: CloudWatch data ingest pricing can escalate quickly when dealing with high-volume sources like access logs. Deep pockets may be required.

Detection is a recurring theme throughout the episode. The hosts discuss CloudTrail Insights for data events (useful if you are already logging data-plane events — another deep-pockets feature), extended threat detection for EC2 and ECS in GuardDuty using AI-powered analysis to correlate security signals across network activity, runtime behavior, and API calls, and the public preview of AWS Security Agent for automated security investigation.

On GuardDuty specifically, the recommendation is clear: if you don't have it enabled, go enable it — it gives you a good baseline that works out of the box across your services with minimal setup. You can always graduate to more sophisticated tooling later, but GuardDuty is the gap-stopper you start with.

Mattias drives the broader point home: incidents are inevitable, and what you can control is how fast you detect and respond. AWS is clearly investing heavily in the detection side, and teams should enable these capabilities as fast as possible.

Control Tower, Organizations, and Guardrails at Scale

Several updates make governance easier to adopt at scale: - Dedicated controls for AWS Control Tower without requiring a full Control Tower deployment — you can now use Control Tower guardrails à la carte. - Automatic enrollment in Control Tower — a feature the hosts feel should have existed already. - Required tags in Organizations stack policies — enforcing tagging standards at the organization level. - Amazon Inspector organization-wide management — centralized vulnerability scanning across all accounts. - Billing transfer for AWS Organizations — useful for AWS resellers managing multiple organizations. - Delete protection for CloudWatch Log Groups — a small but important safeguard.

Mattias says plainly: everyone should use Control Tower.

MCP Servers and AWS's Evolving AI Approach

The conversation shifts to the public preview of AWS MCP (Model Context Protocol) servers. Unlike traditional locally-hosted MCP servers that proxy LLM requests to API calls, AWS is taking a different approach with remote, fully managed MCP servers hosted on AWS infrastructure. These allow AI agents and AI-native IDEs to interact with AWS services over HTTPS without running anything locally.

AWS launched four managed MCP servers — AWS, EKS, ECS, and SageMaker — that consolidate capabilities like AWS documentation access, API execution across 15,000+ AWS APIs, and pre-built agent workflows. However, the IAM model is still being worked out: you currently need separate permissions to call the MCP server and to perform the underlying AWS actions it invokes. The hosts treat this as interesting but still evolving.

Boris: AI for AWS Change Awareness

Toward the end of the episode, Andrey reveals a personal project: Boris (getboris.ai), an AI-powered DevOps teammate he has been building. Boris connects to the systems an engineering team already uses and provides evidence-based answers and operational automation.

The specific feature Andrey has been working on takes the AWS RSS feed — where new announcements land daily — and cross-references it against what a customer actually has running in their AWS Organization. Instead of manually sifting through hundreds of releases, Boris sends a digest highlighting only the announcements relevant to your environment and explaining how you would benefit.

Mattias immediately connects this to the same problem in security: teams are overwhelmed by the constant flow of feature updates and vulnerability news. Having an AI that filters and contextualizes that information is, in his words, "brilliant."

Andrey also announces that Boris has been accepted into the Tehnopol AI Accelerator in Tallinn, Estonia — a program run by the Tehnopol Science and Business Park that supports early-stage AI startups — selected from more than 100 companies.

Highlights

• Setting expectations: "The selection of announcements smells more like security only. If security is your thing, stay tuned in. If it's not really, well, it's still interesting, but I'm just trying to manage your possible disappointment."
• On VPC encryption control: The hosts describe how proving internal encryption used to require traffic mirroring, Wireshark, and significant pain — this feature makes it a configuration toggle.
• On public S3 buckets: "In 2026 there is no good reason to have a public S3 bucket. Just turn it on and forget about it."
• On production data for testing: When someone floats using masked production data for testing — "Maybe don't do that."
• On detection over prevention: "You cannot really prevent something from happening in your environment. What you can control is how you react when it's going to happen. Detection is really where I put effort."
• On Boris: When Andrey describes how Boris watches the AWS release feed and tells you which announcements actually matter for your environment, Mattias's reaction: "This is brilliant."
• On getting started with AWS security: "If you are a startup building on AWS and compliance is important, it's quite easy to get it working. All the building blocks and tools are available for you to do the right things."

Resources

• Introducing VPC Encryption Controls — AWS blog post explaining monitor and enforce modes for VPC encryption in transit.
• AWS Post-Quantum Cryptography — AWS overview of post-quantum cryptography migration, including ML-KEM support across S3, ALB, NLB, KMS, and Private CA.
• S3 Block Public Access Organization-Level Enforcement — Announcement for enforcing S3 public access blocks across an entire AWS Organization.
• Amazon ECR Managed Container Image Signing — Guide to setting up managed image signing with ECR and AWS Signer.
• GuardDuty Extended Threat Detection for EC2 and ECS — How GuardDuty uses AI/ML to correlate security signals and detect multi-stage attacks on compute workloads.
• Dynamic Data Masking for Aurora PostgreSQL — How to configure column-level data masking with the pg_columnmask extension.
• Understanding IAM for Managed AWS MCP Servers — AWS Security Blog post explaining the IAM permission model for remote MCP servers.
• B.O.R.I.S — Your AI DevOps Teammate — The AI-powered product discussed in the episode that tracks AWS announcements and matches them to your environment.

What can you automate with SWAMP today, from AWS to a Proxmox home lab? How do skills, scripts, and reusable workflows plug into your stack? Could this be your agent’s missing guardrails?

 

We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

DevSecOps Talks podcast LinkedIn page

DevSecOps Talks podcast website

DevSecOps Talks podcast YouTube channel

---

Summary

System Initiative has undergone a dramatic transformation: from a visual SaaS infrastructure platform with 17 employees to Swamp, a fully open-source CLI built for AI agents, maintained by a five-person team whose initials literally spell the product name. Paul Stack returns for his third appearance on the show to explain why the old model failed — and why handing an AI agent raw CLI access to your cloud is, as Andrey puts it, just "console-clicking in the terminal." The conversation gets sharp when the hosts push on what problem Swamp actually solves, whether ops teams are becoming the next bottleneck in AI-era delivery, and why Paul believes the right move is not replacing Terraform but giving AI a structured system it can reason about. Paul also drops a parting bombshell: he hasn't written a single line of code in four weeks.

Key Topics

System Initiative's pivot from visual editor to AI-first CLI

Paul Stack explains that System Initiative spent over five years iterating on a visual infrastructure tool where users could drag, drop, and connect systems. Despite the ambition, the team eventually concluded that visual composition was too slow, too cumbersome, and too alien for practitioners accustomed to code, artifacts, and reviewable changes.

The shift started in summer 2025 when Paul spiked a public OpenAPI-spec API. A customer then built an early MCP (Model Context Protocol) server on top of it — a prototype that worked but had no thought given to token usage or tool abstraction. System Initiative responded by building its own official MCP server and pairing it with a CLI. The results were dramatically better: customers could iterate easily from the command line or through AI coding tools like Claude Code.

By Christmas 2025 the writing was on the wall. The CLI-plus-agent approach was producing better outcomes, while the company was still carrying hundreds of thousands of lines of code for a distributed SaaS platform built for a previous product direction. In mid-January 2026, the company made the call to rethink everything from first principles.

The team behind the name

The restructuring was painful. System Initiative went from 17 people to five. Paul explains the reasoning candidly: when you don't know what the tool is going to be, keeping a large team around is unfair to them, bad for their careers, and expensive. The five who stayed were the CEO, VP of Business, COO, Paul (who ran product), and Nick Steinmetz, the head of infrastructure — who also happened to be System Initiative's most active internal user, having used the platform to build System Initiative itself.

Those five people's initials spell SWAMP. The name was unintentional but stuck — and Paul notes with a grin that if they ever remove the "P," it becomes "SWAM," so he's safe even if he leaves. Beyond the joke, the name fits: Swamp stores operational data in a local .swamp/ directory — not a neatly formatted data lake, but a structured store that AI agents can pull from to reason about infrastructure state and history.

Why raw AI agent access to infrastructure is dangerous

A major theme in the conversation is that letting an AI agent operate infrastructure directly — through the AWS CLI or raw API calls — is fundamentally unreliable. Andrey lays out the problem clearly: this kind of interaction is equivalent to clicking around the cloud console, just automated through a terminal. It is not repeatable, not reviewable, and inherits the non-deterministic behavior of LLMs. If the agent's context window fills up, it starts to forget earlier decisions and improvises — a terrifying prospect for production infrastructure.

What made System Initiative's earlier MCP-based direction compelling, in Andrey's view, was the combination of guardrails, repeatability, and human review. The agent generates a structured specification, a human reviews it, and only then is it applied. Paul agrees and calls this the "agentic loop with the human loop" — the strongest pattern they found.

Token costs and the case for local-first architecture

Paul shares a hard-won lesson from building MCP integrations: a poorly designed MCP server burns enormous amounts of tokens and creates unnecessary costs for users. He spent three weeks in December reworking the server to use progressive context reveal rather than flooding the model with data. Even so, the fundamental problem with a SaaS-first architecture remained — constantly transmitting context between a central API and the user's agent was expensive regardless of optimization.

That experience pushed the team toward a local-first design. Swamp keeps data on the user's machine, close to where the agent operates, giving AI the context it needs without the round-trip overhead and cost of a remote service.

What Swamp actually is

Swamp is a general-purpose, open-source CLI automation tool — not just another infrastructure-as-code framework. Its core building blocks are:

• Models: typed schemas with explicit inputs, outputs, and methods. Unlike traditional IaC resource definitions limited to CRUD operations, Swamp models can have methods like analyze or do_next, with the procedural logic living inside the method itself.
• Workflows: the orchestration layer that interacts with APIs, CLIs, or any external system. Workflows take inputs, can be composed (a workflow can orchestrate other workflows), and produce artifacts that the AI agent can inspect over time.
• Skills: Claude Code markdown files and shell scripts that teach the AI agent how to build models and workflows within Swamp's architecture.

Critically, Swamp ships with zero built-in models — no pre-packaged AWS EC2, VPC, or GCP resource definitions. Instead, the AI agent uses installed skills to generate models on the fly. Paul describes a user who joined the Discord that very morning, asked Swamp to create a schema for managing Let's Encrypt certificates, and it worked on the first attempt without writing any code.

Nick Steinmetz provides another example: he manages his homelab Proxmox hypervisor entirely through Swamp — creating and starting VMs, inspecting hypervisor state, and monitoring utilization. He recently connected it to Discord so friends can run commands like @swamp create vm to spin up Minecraft and gaming servers on demand.

How Swamp fits with AI coding tools

The hosts spend significant time pinning down where Swamp sits relative to tools like Claude Code, bash access, and existing automation. Paul is clear: Swamp is not an AI wrapper or chatbot. It is a structured runtime that gives agents guardrails and reusable patterns.

Mattias works through several analogies to help frame it — is it like n8n or Zapier for the CLI? A CLI-based Jenkins where jobs are agents? Paul settles on this: it is a workflow engine driven by typed models, where data can be chained between steps using CEL (Common Expression Language) expressions — the same dot-notation referencing used in Kubernetes API declarations. A simple example: create a VPC in step one, then reference VPC.resource.attributes.vpcid as input to a subnet model in step two.

In Paul's personal workflow, he uses Claude Code to generate models and workflows, checks them into Git for peer review, and then runs them manually or through CI at a time of his choosing. He has explicitly configured Claude with a permission deny on workflow run — the agent helps build automation but never executes it. The same CLI works whether a person or an agent runs it; the difference is timing and approval.

Reusability, composition, and Terraform interop

Swamp workflows are parameterized and reusable across environments. If they grow unwieldy, workflows can orchestrate other workflows, collect outputs, and manage success conditions — similar to GitHub Actions calling other actions.

Paul also demonstrates that Swamp can sit alongside existing tooling rather than replacing it. In a live Discord session, he built infrastructure models in Swamp and then asked the AI agent to generate the equivalent Terraform configuration. Because the agent had typed models with explicit relationships, it produced correct Terraform with proper resource dependencies. This positions Swamp less as a replacement mandate and more as a reasoning and control layer that can output to whatever format teams already use.

When one of the hosts compares Swamp to general build systems like Gradle, Paul draws a key distinction: traditional tools were designed for humans to write, review, and debate. Swamp is designed for AI agents to inspect and operate within. He references Anton Babenko's widely-used terraform-aws-vpc module — with its 237+ input variables — as an example of a human-centric design that agents struggle with due to version dependencies, module structure complexity, and stylistic decisions baked in over years. Swamp instead provides the agent with structured context, explicit typing, and historical artifacts it can query.

Open source, AGPL v3, and monetization

Paulina asks the natural question: if Swamp is fully open source under AGPL v3, how does the company make money?

Paul is candid that monetization is not the immediate priority — the focus is building a tool that resonates with users first. But he outlines a potential model: a marketplace-style ecosystem where users can publish their own models and workflows, while System Initiative offers supported, maintained, and paid-for versions of commonly needed building blocks. He draws a loose comparison to Docker Hub's model of community images alongside official ones.

The deeper argument is strategic: Paul believes there is no longer a durable moat in software. If users dislike a tool today, AI makes it increasingly feasible to build their own. Rather than trying to control all schemas and code, the team wants to make Swamp so extensible that users build on top of it rather than walking away from it.

Are ops teams becoming the next bottleneck?

Paul argues that software development productivity is accelerating so fast with AI that ops teams risk becoming the next bottleneck — echoing earlier industry transitions from physical servers to cloud and from manual provisioning to infrastructure as code. Development teams can now move at a pace that traditional infrastructure workflows cannot match.

Andrey agrees with the premise but pushes back on where the bottleneck actually sits today. In his experience — spending "day and night burning tokens" on AI-assisted development — the real constraint is testing, not deployment. He describes pipelines that can go from idea to pull request automatically, but stall without a strong test harness and end-to-end validation. Without sufficient tests, you never even reach the deployment phase.

Paul accepts the framing and says the goal of Swamp is to strip away lower-value friction — fighting with file layouts, naming conventions, writing boilerplate models — so teams can invest their time where engineering rigor still matters most: testing, validation, and production safety.

Swamp as an addition, not a forced replacement

Paul closes with an important positioning point: Swamp does not require teams to discard their Terraform, Pulumi, or existing infrastructure investments. It can be introduced alongside current tooling to interrogate infrastructure, validate what existing IaC does, and extend automation in AI-native ways. The extensibility is the point — users control when things run, what models to build, and how to integrate with their existing stack.

Highlights

"Giving an agent raw CLI access to your cloud is basically console-clicking in the terminal." — Andrey

Andrey challenges the assumption that AI-driven infrastructure is automatically safer. If an agent is just shelling out to the AWS CLI, the result may be fast — but it is non-deterministic, non-repeatable, and forget-prone once the context window fills up.

The future of infra automation needs guardrails before it needs speed. Listen to hear why structured workflows beat flashy demos.

"The best loop was the agentic loop with the human loop." — Paul Stack

The breakthrough was not autonomous infrastructure execution. It was letting the AI generate structured specs while humans stay in charge of review and execution. Paul even blocks Claude Code from running workflows directly on his machine.

If "human in the loop" sounds conservative, this episode makes the case that it is the only production-safe pattern we have. Listen for the full argument.

"There is no longer a moat in software." — Paul Stack

Paul argues that AI has changed the economics of building software so fundamentally that no team can rely on implementation complexity as a competitive advantage. If users dislike your tool, they can build their own — faster than ever before.

That belief is why Swamp is open source, extensible, and ships with zero built-in models. Listen for a candid take on product strategy when anyone can clone your work.

"Ops teams are going to become the bottlenecks that we once were." — Paul Stack

As development velocity explodes with AI, Paul warns that infrastructure teams risk slowing everything down — the same pattern that played out in the shifts from physical servers to cloud and from cloud to IaC.

Andrey fires back: the real bottleneck today is testing, not deployment. Listen for a sharp debate on where delivery pipelines are actually stuck.

"I haven't written a single line of code in four weeks." — Paul Stack

Paul reveals that the entire Swamp repository is AI-generated, with four machines running in parallel to churn out plans and implementations — including customer feature requests. The team teases a future episode to compare notes on AI-driven development workflows.

If that claim doesn't make you want to hear the follow-up, nothing will.

Resources

• Swamp CLI on GitHub — The open-source, AGPL v3 licensed CLI tool discussed in the episode. Models, workflows, and a local .swamp/ data directory designed for AI agent interaction.

• System Initiative — The company behind Swamp, originally known for its visual infrastructure platform, now pivoted to AI-native CLI automation.

• Model Context Protocol (MCP) — Anthropic's open protocol for connecting AI models to external tools and data sources. Paul discusses the challenges of building MCP servers that are token-efficient.

• Claude Code — Anthropic's agentic coding tool that runs in the terminal. Used throughout the episode as the primary AI agent interface for Swamp workflows.

• CEL — Common Expression Language — The expression language Swamp uses for chaining data between workflow steps, similar to how Kubernetes uses it for API declarations and validation policies.

• Proxmox Virtual Environment — The open-source hypervisor platform that Nick Steinmetz manages entirely through Swamp in his homelab, including Discord-driven VM creation.

• terraform-aws-modules/vpc — Anton Babenko's widely-used Terraform VPC module, referenced by Paul as an example of human-centric IaC design with 237+ inputs that agents struggle to navigate.

We kick off with a CVSS 10 in n8n, then look at self-hosted AI assistants with weak defaults and prompt injection risks. Are your API keys, inbox, and drives safe if a bot is open to the web? What should you rotate, patch, and hide behind a VPN?

 

We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

DevSecOps Talks podcast LinkedIn page

DevSecOps Talks podcast website

DevSecOps Talks podcast YouTube channel

We get into K8s vs native orchestrators. Do you still need Kubernetes when managed services cover most needs? How do cost, lock-in, and team skills change the choice? Expect a heated debate.

 

We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

DevSecOps Talks podcast LinkedIn page

DevSecOps Talks podcast website

DevSecOps Talks podcast YouTube channel

Are devs ignoring AI, misusing it, or getting real value? What happens when agents touch your env vars, repos, and pipelines? How do you share prompts, set team defaults, and keep trust? Could an AI engineer role lead culture as well as tools?

 

We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

DevSecOps Talks podcast LinkedIn page

DevSecOps Talks podcast website

DevSecOps Talks podcast YouTube channel

Which parts of AI Act, NIS2, DORA, and DSA overlap so you can cover more with less? What basics raise your baseline fast: central logs, backups, risk assessments, and human-in-the-loop governance? Could a simple mailing list make incident comms painless?

 

We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

DevSecOps Talks podcast LinkedIn page

DevSecOps Talks podcast website

DevSecOps Talks podcast YouTube channel

Want a quick map of EU compliance for engineers? How do you classify AI by risk and tell users when AI is used? When do you send a 24-hour heads-up and a one-month report after an incident? Does NIS2 make your board liable and your logs mandatory?

 

We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

DevSecOps Talks podcast LinkedIn page

DevSecOps Talks podcast website

DevSecOps Talks podcast YouTube channel

Is MCP just another server you need to threat model, patch, and monitor? How do you keep users from over-privileged access, block LLM injection, and stop blind spots? We unpack the VentureBeat article https://venturebeat.com/security/mcp-stacks-have-a-92-exploit-probability-how-10-plugins-became-enterprise with real-world tips.

 

We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

DevSecOps Talks podcast LinkedIn page

DevSecOps Talks podcast website

DevSecOps Talks podcast YouTube channel

We break down 10 years of HashiConf and this year's Terraform-heavy news. What do Terraform Actions with Ansible, Stacks GA, and HCP-only features mean for day two work? Is open source getting left behind, and is OpenTofu worth a look?

 

We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

DevSecOps Talks podcast LinkedIn page

DevSecOps Talks podcast website

DevSecOps Talks podcast YouTube channel

Can AI really help us build more secure software? What’s working in practice right now, and where do the tools still fall short? Mattias and Paulina share their views.

 

We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

DevSecOps Talks podcast LinkedIn page

DevSecOps Talks podcast website

DevSecOps Talks podcast YouTube channel