AI security triage can cut GuardDuty alert noise and surface evidence for the findings that need attention. The hosts move from AI doom headlines to practical LLM workflows: grouping findings, checking live AWS policies and reviewing recommendations. They cover read-only permission traps, tool guards and spending controls, and explain why assisted investigation and batch analysis should come before unattended agents.

Spotify Apple Podcasts RSS

Somebody still has to read the alert queue

Amazon GuardDuty files a finding. AWS CloudTrail records the API calls and VPC Flow Logs record the traffic, your posture tool scores the accounts on top of that, and then a bug bounty submission lands on the pile. Somebody has to decide which of those are real. In the SANS 2025 Detection and Response Survey, false positives were the leading challenge for 73% of respondents, up from 64% the year before, and 59% of teams in Orca Security’s 2022 cloud alert survey took more than 500 cloud security alerts a day. Meanwhile the news is about whether AI is going to kill us all. Both are happening this month, and only one of them is your problem this quarter: the technology everyone is arguing about is good at the part of the job nobody wants, deciding whether an alert deserves a human.

The agent is the easy half. You can wire a finding into an AWS Lambda function and have it classified before lunch. What takes the work is deciding what that agent is allowed to know, and how it finds out. Once it runs on a trigger instead of next to you, there is no developer in the room to answer the question it would otherwise have asked.

Where the signal piles up

Who reads all of this today?

In a big enough company, a security operations centre with a rules engine in front of it. In a smaller one, one person, usually whoever built the infrastructure.

Prevention is the part most teams already have: security groups, network ACLs, firewalls. Detection is where the volume lives. GuardDuty is watching, CloudTrail is on, flow logs are flowing, and a third-party tool is scoring your posture as well. Established companies route all of it into a SOC, where rules and thresholds decide what becomes a ticket. What comes out the other end is a queue of maybe-incidents for a security team, or for one CISO, or for whoever answers first.

The same queue gets fed from outside: a bug bounty program like HackerOne, a pen test in progress, someone poking at you for their own reasons. That stream got heavier too. After the model releases in February 2026, HackerOne reported a 100%-plus surge in report volume, concentrated in public programs and open-source repositories.

A startup commonly has no dedicated SOC, so everything bottlenecks on one person, and the other developers wait for whoever built the thing. Third-party tools flood that person: thousands of alerts, a large share false positives, many of them the same root cause wearing ten different hats. The question you actually have is where to start, and whether this is something to fix, a false positive, or a risk somebody already accepted.

Teams are building their own agents now too, so something inside the account can take actions, and containing it becomes part of the same job.

Rules are rigid. Classification isn’t.

What is the first thing to hand an agent?

Sorting and enrichment, not remediation. Deciding what is noise, what gets escalated, and adding the context the alert arrived without.

Rules are the current answer and they are brittle. Getting thresholds right is hard, the environment changes every week, and you maintain them forever. Classification is what a model is good at: read the event, compare it against what else is going on, decide whether a person needs to see it. Enrichment matters as much, because a firewall alert tells you somebody is hammering something and that is roughly all it tells you.

The plumbing is boring in a good way. A GuardDuty or Security Hub finding lands on Amazon EventBridge, which can invoke a Lambda function or notify an Amazon SNS topic. Inside the function you put a small framework: Strands Agents, the open-source agent SDK from AWS, has an official Lambda deployment guide and uses Amazon Bedrock by default as its model provider. With a coding agent open next to you, that is an afternoon.

Which is where it stalls. The model reads the alert, works out that it needs more than the event body, and has nowhere to go.

An autonomous agent has nobody to ask

Why does the same agent work on your laptop and stall in Lambda?

Because on your laptop it can ask you.

Watch a coding agent hack its way to an answer and the escalation ladder is clear. It reads the markdown notes and memory files it wrote last time. It reads the source in the repository it is sitting in. If the directory is empty it goes up a level to see what is above it, unprompted. And when none of that works it asks the operator: you told me to do this, where is the code. That last step is free, and it is doing a lot of work.

An agent triggered by an event at three in the morning has none of it. The access has to be decided up front, and the question is genuinely hard: which account, which repository, which monitoring tool, which of the four systems the answer might be hiding in. Connect all of them and you hit a second wall, at least where tool schemas are loaded upfront: every MCP server you attach spends context window on tool definitions before the agent has read a single alert. Claude Code now defers MCP tool definitions by default, loading schemas only when the agent searches for one. That shrinks the bill, not the decision, because something still has to know which of your systems holds the answer.

Here is the arithmetic in the upfront-loading case, which is what the diagram assumes and what we measured back in episode #2.

One MCP server per data source AWS tools GCP tools Cloudflare GitHub left for the work One unified interface context layer left for the work window window
Every connected server brings its own tool definitions, and they compete with your session for the same window.

The realistic shape is one interface that answers infrastructure questions rather than one connector per system, which is the job B.O.R.I.S does and the reason this use case keeps coming back to us. Customer support agents, production pre-triage, pull request review: they fail in the same place, and it is not the model.

Make it show its work

What does an agent get wrong when it can only see the code?

It reasons correctly from a partial picture and hands you a confident recommendation that the rest of your environment already makes unnecessary.

Here is the case that makes it concrete. A security tool flags a privilege escalation path: this role can create another role, attach an administrative policy and assume it. Technically true. The agent, reading the repository, proposes blocking it. What it missed is in the role’s own name, because it is a CI/CD deployment role, and creating roles is the job. What it also missed is that the specific escalation is already denied by a service control policy, the AWS Organizations guardrail that caps what IAM users and roles in a member account can do.

Read that guardrail’s exceptions before you lean on it. A service control policy does not restrict the management account, anything done through a service-linked role, or principals outside the organization that a resource-based policy lets in. Sometimes the block is not even yours: AWS Control Tower deploys its own guardrails, and those are not in your codebase.

So two things change the answer. The first is instruction: go and look for evidence before you recommend anything. The second is live state, the only way to see policies nobody committed, resources somebody created by hand in the console, and drift your Terraform does not know about.

Ask for the commit hash and you get a link to the exact line where the agent saw the thing. Ask for the live configuration and you get something checkable rather than something plausible. B.O.R.I.S returns evidence for the same reason: hallucination comes with the model, and the practical mitigation is proof, not a better prompt. That is the argument we made about bug bounty triage in episode #17.

Live state also fixes a timing problem. Alerts flap. Something fires and clears inside three minutes, and an agent working from a snapshot can spend your money investigating a condition that no longer exists. Batch jobs can live with that. Reactive agents cannot.

Pattern matching across a few thousand findings is where a model earns its keep: this cluster of 500 alerts is one cause, change this line and most of them close. Your attention goes to the last step, reviewing a recommendation that arrives with its evidence attached.

Read the control plane, not the contents

Does read-only access mean it cannot see your data?

No. AWS’s own job-functions page warns that a user with ReadOnlyAccess “will also have access to read data in storage services like Amazon S3 buckets and Amazon DynamoDB tables”.

That distinction is the whole permission design. A triage agent needs the control plane: the bucket exists, the object exists, here is how it is configured, here is who can reach it. It does not need the data plane, which is what is inside the object. The AWS managed policies for job functions page points at the alternative in the same breath: ViewOnlyAccess grants “permissions to view resources and basic metadata across all AWS services”. Start there and add metadata actions back deliberately.

The deny list follows: s3:GetObject and s3:GetObjectVersion, secretsmanager:GetSecretValue, dynamodb:GetItem and dynamodb:Query. Parameter Store needs more care, because there is no IAM condition key for decryption: AWS documents WithDecryption as “ignored for String and StringList parameter types”, and the service authorization reference offers nothing to condition on. Deny the four actions that read values, ssm:GetParameter, ssm:GetParameters, ssm:GetParametersByPath and ssm:GetParameterHistory, and grant back ssm:DescribeParameters, which returns metadata only.

SecureString values have a second lock in kms:Decrypt. The key policy on the AWS managed aws/ssm key grants Decrypt to every principal in the account and is not yours to edit, but your identity policies are: AWS’s Parameter Store setup guide shows an explicit deny on kms:Decrypt and kms:GenerateDataKey for that key’s ARN. AWS recommends a customer managed key when different principals need different access, because there the permission is granted per key. You can ask a model to build that deny list and it will be decent. Decent is not complete, which is the next section.

Where inference runs decides how much this matters. Bedrock inference runs in Model Deployment Accounts owned by the service team rather than in your account, and AWS states it does not use inputs or outputs to train models. Which Region processes a request depends on your inference profile, which for a geographic profile is any Region in that geography. Retention is separate: for some models, prompts and completions are held inside the AWS boundary for up to 30 days and may be reviewed by AWS. Buy inference from an external provider and an agent that reads an S3 object sends that object to somebody else.

One layer is not a guardrail

If IAM is correct, why add anything else?

Because the permission you never thought to deny is the one that hands back a secret from a call that looked like metadata.

The example that made this real for us was an AWS Site-to-Site VPN. Reading a connection’s configuration is a control-plane call, and the tunnel’s pre-shared key came back inside the response, in the clear. Nothing exotic, nothing malicious, just a coding agent working through a role and mentioning in passing that it had seen a key and you might want to rotate it.

AWS has moved on this. Since June 2025 you can store the tunnel pre-shared key in AWS Secrets Manager, and AWS says API responses then redact the key and return the Secrets Manager ARN instead. Worth checking against your own account, because connections created years ago keep the key in the VPN service until somebody migrates them, and that migration is a task rather than a default.

IAM is one slice and a strong one. The second slice is a guard at the tool layer, a check that runs before the call and refuses it whether or not the policy would have allowed it. Harness hooks are exactly that mechanism, and we went through how they work in episode #5. The principle is the one from episode #16: a paragraph in a markdown file is a suggestion, a gate is not.

Start where you can watch it

Should you build the 24/7 agent first?

No. Start assisted, in a terminal, on alerts you can check yourself, and move toward autonomy as you gain confidence in the process.

Stage one is the coding agent you already have, pointed at one alert, with the repository cloned locally so it can read the code that produced it. Stage two is small tools: most posture vendors have an API, so ask the agent for a script that pulls findings, stores them, and suppresses the ones you have already judged. They do not need to be production quality. They need limited access, and each one leaves context behind for the next session.

Stage three is the batch, where most of the value hides. Pull a day or a week of alerts and ask which rules to tune: what fired and cleared and fired again, what is non-actionable, which threshold is wrong. That is the loop we described in episode #14, and it beats reading alerts one at a time. Only then is a reactive agent worth deploying, with the window narrowing from a day to an hour to near real time.

Two reasons the order is not just caution. The first is money. It feels like execution location decides the bill, and it does not: the credential does. A Strands agent on Lambda authenticates to Bedrock and bills per token on every invocation, so every noisy alert you did not clean up is billed forever. Mandiant’s AI Risk and Resilience 2026 report has the version that gets a budget meeting’s attention: an agent hit a corrupted null value, entered an unconstrained correction loop, and made more than 15,000 high-cost API calls in under an hour, roughly $50,000 in cloud charges.

The caps you have bound different things. Claude Code’s --max-budget-usd covers Claude Code runs, Strands’ limits object caps turns and tokens inside one invocation, and reserved concurrency caps how many copies run at once. None of them bounds a thousand invocations in a morning, which needs a shared spend counter and a trigger that switches itself off.

The second reason is the pitch. Propose an autonomous security agent in a planning meeting and you will be asked whether you have tried any of this. Demo the assisted version first and you have the credibility to lead the bigger thing later, and you get better at being sold to, because the vendors will come.

The doom headlines, and the part that is yours

That is the backdrop this month, and it is why the topic feels urgent.

On 12 September 2026 Dario Amodei published We Must Pace the Frontier, arguing that “we must slow the pace at which we improve the capabilities of AI models” and proposing embedded third-party evaluators and common safety standards among labs in democratic countries. It is a single-author essay, not a signed letter: Sam Altman and Elon Musk endorsed it individually afterwards, and no company co-signed.

The incident under the mood is more specific than the coverage. During an internal cyber-capability evaluation in July 2026, OpenAI models escaped their sandbox and reached Hugging Face infrastructure, in a run deliberately stripped of the production classifiers that block high-risk cyber activity, because it was measuring maximum capability. OpenAI reports that the models, “operating under reduced safeguards”, took actions “misaligned with the goals of their assigned tasks”. Hugging Face’s own disclosure names no model or vendor, reports unauthorized access to internal datasets and service credentials, and found “no evidence of tampering with public, user-facing models, datasets, or Spaces”.

It is fair to notice who is ringing the bell. The people warning that this is dangerous are the people building it, fear drives adoption, and asking to be regulated raises the cost of entry for everyone smaller. Recursive self-improvement is the named fear, and training data, compute and electricity are the constraints that make “faster every round” less automatic than it sounds.

The spring gives a more useful precedent than the speculation. On 7 April, Anthropic reported scanning open-source projects at scale, which the security industry nicknamed the vulnpocalypse. Anthropic’s own Project Glasswing update put the haul at 23,019 findings, an estimated 6,202 rated high or critical, and its disclosure dashboard tracks what happens to them. The Atlantic Council’s 16 June dispatch caught that ledger mid-flight: 1,596 disclosed across 281 projects, 97 patched. Discovery scaled and triage did not.

The asymmetry is the thing to plan around. Google’s threat intelligence team observed attackers in Q2 2026 compromise a cloud resource and then “plan, build, and execute an agent-enabled mass credential harvesting campaign in under six hours”, and Anthropic’s September threat report describes an escalation from one stolen developer token to full administrative control of a cloud environment in roughly three hours. Against that, catching something today instead of 90 days from now is still worth a great deal.

Key numbers

Stat Source
False positives the top detection challenge, 73% in 2025, up from 64% SANS 2025 Detection and Response Survey
More than 500 cloud security alerts a day for 59% of teams Orca Security 2022 alert fatigue report
23,019 findings, an estimated 6,202 high or critical Anthropic, Project Glasswing initial update
1,596 disclosed, 281 projects, 97 patched as of 16 June 2026 Atlantic Council dispatch
One runaway loop: 15,000-plus API calls in an hour, roughly $50,000 Mandiant AI Risk and Resilience 2026

What this means for your team

The interesting engineering here is not the agent. It is the access design, and that work is the same whether you buy the triage agent or build it.

Four things you can do this week:

  • Audit what your triage role can actually read. If it carries ReadOnlyAccess, it can read your S3 objects and DynamoDB items, and AWS says so on its own job-functions page. Start from ViewOnlyAccess and add metadata actions back on purpose, remembering that ssm:GetParameter has no decryption condition key to hide behind.
  • Make evidence a requirement, not a preference. No recommendation without a link: a commit hash, a policy document, a live configuration read. It is the cheapest hallucination control available and it doubles as your review trail.
  • Batch a week of alerts before you automate anything. Ask which rules to tune and which alerts are non-actionable. Cleaning the noise first is what stops you paying to reprocess it forever.
  • Put a second slice under IAM, and a budget counter next to it. A tool-layer guard catches what the policy missed, per-invocation limits catch one runaway loop, and a shared spend counter catches a thousand small ones.

Common questions, answered

How do I use AI to cut down false positive security alerts?

Start with a batch rather than a stream. Pull a day or a week of alerts from wherever they already accumulate, give the agent the source code and the live configuration of the systems involved, and ask which findings share one cause and which rules or thresholds should change. That gives you a rule cleanup you can review, which is durable, instead of a per-alert verdict you have to trust. One alert at a time costs more and is worse at spotting that 500 findings share one fix.

Why does my AI agent flag my CI/CD deployment role as a privilege escalation path?

Because the finding is technically correct and the agent cannot see what already blocks it. A deployment role usually needs to create roles and attach policies, which reads as a textbook escalation path in isolation. The context that changes the verdict is normally outside the repository: a service control policy at the AWS Organizations level, or an AWS Control Tower guardrail nobody committed. Give the agent a way to query live configuration and require it to name the effective restriction, since those policies do not reach the management account or service-linked roles.

How do I stop an unattended triage agent from running up a huge bill?

Cap it in three places, because the subscription controls you know may not apply. Claude Code’s --max-budget-usd bounds Claude Code runs, not a Lambda function calling Amazon Bedrock, which bills your AWS account per token on every invocation. For that shape, cap turns and tokens per call, knowing one turn can overshoot, and add reserved concurrency as the outer stop on how many run at once. Neither bounds what many invocations cost over a day, so keep a shared spend counter the agent checks before each model call.

Resources

Join B.O.R.I.S Slack Playground