An AI agent can now find a vulnerability, exploit it, and keep going. No human required at any step.
That’s the line that stuck with our team after AWS’s “Build Secure Applications Faster with AI-Native Defenses” workshop last Thursday. Three of our engineers from the Philippines team, Cedric, Melisa, and Alliyah, spent the day chasing one question: AI has changed how security works for both attackers and defenders, so what does that actually mean for how we build and protect our own applications? The day split into a strategy briefing on AI-related security risk and a hands-on session building and locking down an actual AI agent. What came back to the team afterward wasn’t a stack of AWS product notes so much as a sharper way of thinking about a problem we’re already living with.
Threats vs. vulnerabilities: why the line matters now
Alliyah walked away with a distinction that reframed everything else the workshop covered. Threats sit outside our control, and we need to detect and respond to them fast. Vulnerabilities are the weaknesses we introduce ourselves, and we’re the ones responsible for fixing them.
It sounds simple. It isn’t, once AI is on both sides of that line.
Security used to move at human speed: configure, scan, review, fix. Now defenders can automate detection and response just as easily as attackers can automate exploitation. Attackers can even study the patterns people leave online (the way we write, the tools we use, the systems we touch) to make phishing and social engineering far more convincing than a generic scam email. Cedric put it plainly: AI isn’t just a tool anymore. It’s also a weapon, depending on who’s holding it.
AI doesn’t just find the gap. It walks through it.
Here’s the part that should change how every team thinks about its own exposure: finding a weakness and exploiting it used to take two different skill sets, and often two different people. Not anymore.
Attackers use AI to turn up things that might take a human days to find: an old API still wired to a live database, a system that got exposed and nobody noticed. That part isn’t new. What’s new is what happens next. The same agent that finds the gap can now configure an exploit and use it, with no person in the loop at any stage. Defense used to move at human speed. AI broke that assumption on both sides.
Building the lock, one layer at a time
The second half of the day was hands-on: building a small AI agent using a framework called Strands, then securing it layer by layer. Melisa put it well: like building a house and adding locks, cameras, and an alarm one at a time.
The agent lived in its own sandbox (Bedrock AgentCore Runtime), so it couldn’t reach anything outside its lane. It could only talk to its tools through one clearly defined door, using a standard called MCP, instead of everything being bundled together loosely. Every one of those doors ran through a single, well-guarded gateway, with the real tool logic sitting safely behind it in Lambda. Nobody got in without logging in first, through Cognito and OAuth 2.0. And the system checked every incoming request for anything suspicious, scrubbing sensitive data before sending anything back out.
What didn’t make it into the live session but matters just as much: giving people different levels of access based on who they are, using a policy engine to enforce it, and logging everything so the team could trace any issue back to exactly what happened and who touched it.
The detail that stayed with Melisa wasn’t any single layer. It was the order. Each layer only worked because the one before it was already in place. There was no way to skip a step or shortcut it. As she put it: security has to be designed in, not bolted on later. More access for an AI agent shouldn’t mean more exposure for us.
What happens when you try to break it
The workshop also ran a live demo: an AI agent reviewing code for vulnerabilities against a set of security requirements. Cedric watched it work. It caught real issues, but took longer than people might expect, about two hours for a small project. Scale that up to a real production codebase, and the time cost stops being a footnote and becomes a real design question.
The full penetration test wasn’t something attendees got to run themselves (setting up the credentials and access an agent needs for that kind of test takes real setup), but the demo account’s earlier results were detailed enough to show what’s coming. Cedric’s take on all of it was refreshingly practical: in theory, you don’t need to buy a specific vendor’s service to get this benefit. Give an agent the same security requirements and point it at your own code, and you get most of the value yourself.
Melisa’s sharpest observation was less about tools and more about what AI security failures actually look like: the scariest ones don’t look like failures at all. A blocked action can still look like a success on the surface. Normal monitoring won’t catch it unless you know exactly where to look. Assuming “no errors” means “nothing bad happened” is exactly the gap attackers count on.
This isn’t someone else’s job
The idea that came up most across all three of their notes: security can’t sit with one team anymore. It has to be something the whole company carries, built into how every team designs, builds, and delivers, rather than a checklist added at the end.
That’s not a new principle for us. At Human Managed, security has never been handed off to a separate team to worry about. Every engineer owns it, because that’s how the team is built. Cedric pointed to a real example running in our own beta app: CI jobs that check every push for exposed secrets and known code vulnerabilities before anything reaches beta, let alone production. Catching the issue during a pull request instead of after launch is what the workshop called “shifting left.” Our engineers were already doing it before they had a name for it.
Where this leaves us
The tools on display were AWS’s. The principles underneath them weren’t new: least privilege, defense in depth, audit trails. What’s changed is the surface those principles now have to cover: a faster-moving, more autonomous one, where the systems making decisions aren’t always human.
Given where Human Managed is already headed with automation and agent-driven tooling, this isn’t a hypothetical for us. It’s the framework we’ll want in place before we hand our own agents (or help a client hand theirs) real access to production data. The workshop didn’t hand our team a finished playbook so much as a sharper set of questions to ask about the systems we’re already building, which is usually where the more useful work begins.
