DEV Community

Cover image for Always-On AI Agents Create a Security Problem We Have Barely Started Testing
Konstantin Klyagin
Konstantin Klyagin

Posted on

Always-On AI Agents Create a Security Problem We Have Barely Started Testing

AI agents are turning from tools we open for a single task into coworkers that never clock out. WIRED reported that OpenAI is testing a "persistent" mode for Codex in which the agent will "continue working until put to sleep," and that same week Cisco handed MyAgent to all 90,000 of its employees.

My teams use AI assistants every day, and I'm not about to take them away. Still, after more than a decade of running a QA company, I see a gap only few CTOs I talk to discuss: we test these agents one task at a time, while the real risk builds up over weeks as their permissions, memory and goals gradually go stale. Here's where I see things breaking and what I'd test before trusting an agent for months.

Where Access Control Breaks

In my long career, I've seen how predictable access control can be: a user logs into the VPN, does their work, and logs off, while automated scripts only touch the systems they are set up for. An always-on agent can grab a request from a Slack thread and keep acting on it long after the project has wrapped up and the requester changed teams.

NIST's identity specialists seem to share my unease, noting in a recent post that early agent rollouts are repeating the old habit of “prioritizing feature development and immediate value over security”.

Six Ways a Long-Running Agent Goes Wrong

Take permission drift first. A project manager hooks an agent up to a client's Jira board, moves to another account, and the agent carries on posting updates in her name, since nobody revoked its token along with her access. In an agency where people hop between client projects all the time, I'd bet on this showing up early.

Context contamination is the worrying part for the legal team, taking into account all the NDAs companies sign with their partners. An agent that skimmed a private HR thread about a hiring freeze during a budget memo can drop a hint about it into a company newsletter weeks later.

Intent decay would be funny if it weren't so risky: I ask for a few notes before a client call, and somewhere along the way the agent has emailed the client a follow-up and nudged the deal to “closed” in our CRM. A keen junior hire might do something similar, but at least they'd ping me first.

Offboarding is where I'd expect the most expensive surprises. IT wipes a departing engineer's laptop, yet the OAuth token their agent uses for GitHub keeps working. Intuit's CIO and CISO Atticus Tysen described this risk, warning that agents “get orphaned, and then they become an attack vector”.

Memory poisoning is another grey area, because one webpage with a hidden instruction, read once during research, can get stored as a “user preference” and nudge the agent for ages. OWASP's Idan Habler nailed it when he wrote that persistent memory “becomes a security-relevant state”.

Then there are mistakes that never throw an error, like an agent misreading a renewal date in a vendor contract and building every forecast on top of it until finance's numbers stop adding up. In my experience, quiet data problems like this one have cost clients far more money than crashes ever did.

From Onboarding to Offboarding

We'd never test a user account only on the day it's created, since role changes and offboarding are exactly where access bugs love to hide.

Ownership is a problem too, since QA looks at features, security at access and IAM at identities, and each assumes somebody else is watching the agent. Without one named owner, the responsibility gap in AI agent governance just keeps widening.

When my team runs AI agent testing for clients, these are the checks I look for in any plan for a long-running agent:

  • Pulling a permission halfway through a workflow and making sure the next step fails cleanly.
  • Changing the owner's role during a multi-day task to see if the agent notices.
  • Offboarding the owner and checking that every token and scheduled job goes with them.
  • Picking something the agent did last week and asking the team to explain why.

This last point is far from hypothetical. With NIST already working on auditing standards for AI agents, you can't just shrug and say "the model decided" when a client wants to know why your agent emailed the wrong person. That's why I fold AI audit readiness into testing.

A couple of cheap habits help right away, starting with an expiry date for every agent, like a contractor's badge that expires with the contract. It's also worth following OpenAI's own advice for ChatGPT agent and connecting only the apps a task needs, since each extra connector opens a door for prompt injection.

The Six-Month Problem

We're pretty good at testing software that runs for an hour. We're much less practiced at testing a digital coworker that keeps its memory, access and initiative for half a year. I suspect plenty of companies will learn about permission drift from an incident report, and I'd rather my teams and clients learn it from a test plan.

Top comments (0)