Adarsh's Guide to Cybersecurity, AI and CAREER Advancement

A few weeks back, one of my mentees — sharp engineer, three years into her career — proudly showed me the agent her team had just shipped. It could read support tickets, pull customer data, open a fix, and push it to staging on its own. No human in the loop until the final merge.

My first question wasn’t “how does it perform.” It was: “what happens if someone feeds it a ticket designed to make it misbehave?”

She didn’t have an answer. Neither did her team.

That conversation is why I’m writing this post.

We spent two years worried about the wrong thing

For a while, the AI risk conversation was mostly about chatbots saying something embarrassing. Wrong facts, a rude reply, maybe a PR headache. Annoying, sure. Survivable.

That’s not where we are anymore.

Walk into almost any mid-size or enterprise IT shop right now and you’ll find agents that don’t just suggest — they act. They file the ticket. They touch the database. They push the code. They move money between systems. The chatbot-with-a-personality era is over; we’re in the agent-with-a-permission-set era, and permissions are a very different kind of risk than a bad sentence.

I didn’t fully appreciate how fast this shifted until I noticed something new showing up in vendor pitches this year: companies selling red-team testing specifically for AI agents — throwing messy inputs, manipulation attempts, and weird multi-step conversations at them to see what breaks. Eighteen months ago that category barely existed. It exists now because agents earned it the hard way.

Three ways this bites you, in plain terms

I’m not going to give you a sanitized “consider the following framework” list. Here’s what actually worries me, from someone who’s spent two decades cleaning up after security assumptions that didn’t hold.

The content itself can steer the agent. Not the user typing at it — the document it reads, the ticket it processes, the webpage it fetches. If your agent has tool access and reads untrusted content, that content can carry instructions your agent will happily follow. This is the new phishing email, except it’s aimed at software, not people.

Everyone over-permissions, always. I’ve watched this pattern for twenty years across every new technology: give the new thing broad access “just to get it working,” fix the scoping later. Later rarely comes. An agent with more access than its job requires isn’t a hypothetical — it’s the default, and it’s exactly what turns one bad interaction into a lateral-movement incident.

Nobody can explain what the agent did, or why. When a person makes a bad call, you sit them down and ask. When an agent chains together six tool calls across three systems, reconstructing the “why” — for your own postmortem, let alone for an auditor — is a genuinely hard problem most teams haven’t solved yet. I’d bet money this is the detail that makes the first big agent-related headline ugly: not the breach itself, but not being able to explain it afterward.

If you’re building your career around this — good instinct

Here’s the part I actually want you to walk away with, because I talk to a lot of engineers trying to figure out where to point their next year of learning.

If you’re on the security side: “AI agent security” is a specialization that essentially didn’t exist a year ago. It’s showing up in job descriptions now at banks, cloud providers, and companies you’d expect to be conservative. Get there early.

If you’re on the AI/ML side: knowing how to scope an agent’s permissions and handle untrusted input will make you more valuable than being able to quote the latest benchmark score. Anyone can cite a leaderboard. Fewer people can say “here’s why this agent can’t be tricked into wiring itself extra access.”

Three things I’d actually do this month, not just nod along to:

• Pick one agent-security incident writeup a week and read it like a case study, not news scroll.
• Before deploying or evaluating any agent, write down the smallest set of permissions it needs — then cut it further.
• Practice thinking about slow manipulation across a long conversation, not just one bad prompt. The interesting failures aren’t a single injected instruction; they’re an agent talked into something over ten patient turns.

Back to my mentee

I told her the same thing I’m telling you: shipping the agent wasn’t the mistake. Shipping it without asking what it’s allowed to do, and what happens when someone tests that boundary on purpose, was.

That question is cheap to ask now. It gets a lot more expensive to ask after the fact.

If your team has already run this exercise — scoping an agent’s permissions, red-teaming its inputs — I’d genuinely like to hear how you approached it. Drop it in the comments.

— Adarsh