whoami
I’m a security professional with about eight years in the industry, most of that in detection engineering and cloud security. Like everyone else I’ve had to keep developing and honing my skills just to stay current, because AI is moving fast enough that you fall behind by standing still. Part of that has been keeping up with the attack surface AI and LLMs bring with them, and the other part has been implementing those same tools safely so they actually make everyone else’s work more efficient instead of creating new problems.
Doing both is what got me thinking about this. A security log is a record of adversarial interaction, and we’ve known that for twenty years or more. What I don’t think we’ve reckoned with is that the same thing is true of cloud metadata, and that an attacker doesn’t need to control the whole record to cause a problem. They only control the fields they can write to, which in most cases is something small like a resource tag or a security group description or an IAM policy name. Those happen to be exactly the fields an agent reads to work out what a resource is and why it exists, so there’s plenty of opportunity in there to compromise the validity of an investigation or to open a path to escalate.
introducing the series
I work in cybersecurity and I see the pressure organizations are under to adopt AI. Some of it is genuine necessity. Some of it is wanting to do the cool new thing everyone else is doing without much interest in what the thing actually is, and either way the pace is fast enough that standing still feels like falling behind. So leadership pushes teams to use it more, usually faster than anyone can staff for it and often before anyone on the team has done this kind of work before.
Putting AI in front of your security work without the right setup is probably worse than not having it at all, because you’ve added attack surface your team isn’t equipped to defend yet, and you’ve added it to the function that’s supposed to be catching things.
I’ll be honest about why that happens. Keeping up with this is a real commitment, and it moves fast enough that staying current is basically its own job when most people already have one.
The number one use case I see is investigation and analysis, and in most of those deployments success is never actually tested. How do you know the agent is working? How do you know it’s working well? How do you know it’s following the prompt at all? We spend real time reviewing what these agents output and almost none asking what goes into them.
We also don’t think through how the agent itself could be turned. We threat model the systems it touches but rarely the agent, because we think of it as ours, a tool we configured and pointed at our own work.
But an agent with permissions that reads data it didn’t author is a component worth attacking. It has access, it acts on what it reads, and it doesn’t have a reliable way to tell evidence from instructions because both show up as plain text in the same context window.
That’s what makes this different from someone typing a malicious prompt into a chat box. The attacker doesn’t have to be there when it happens, they just have to have written something your agent is going to read eventually.
In cloud work that data is your infrastructure. An agent investigating a cloud alert is reading resource tags, security group descriptions, IAM policy names, log entries, and any of those can be written by someone who isn’t you. An attacker who reaches one of those fields can put instructions inside the evidence.
The question I keep landing on isn’t whether these agents work. It’s whether anyone would notice if one had been steered.
how the lab will work
Every scenario gets built twice, once clean and once with something an attacker could have written sitting in a field the agent is going to read. Same harness both times, same investigation objective, same tools, same evidence sources, same scoring, so the only difference is the poison and when a result changes I know what changed it.
I’ll run that against more than one model, including at least one open-weight, and across three permission levels: read-only, constrained remediation, and approval-gated for anything high impact.
What I actually want to know is whether the agent stayed faithful to what it was told. Did it follow the prompt? If it didn’t, where did it stop? Did it read the injected content and change course, or did it notice and keep going anyway? What did it do after it read it, and did any of that actually get the attacker anything?
I can put a number on some of this, like how often it followed the prompt or how often the attacker got what they wanted. But a percentage tells me how often something happened, not what happened on the way there. So the agent’s actions run through an eval framework that records what it read, what it concluded and what it did, and every failure comes with that trail attached.
what to expect next
Next is the map. Every cloud field I think can carry an injection, what an attacker needs in order to write to it, which agent data source picks it up, and what it could plausibly do downstream. That’s the piece that decides what’s worth testing and what isn’t.
After that, how I built the environment and what I’m measuring, then results once there are results. I’m not going to post half a result. If I show you a number, the experiment behind it is finished. I don’t have a schedule for that part because I don’t know yet how long it takes.
By the end of this series I want to have answered:
Which cloud fields can actually carry an injection, and what access does an attacker need to write to each one?
Does the model you picked change the answer?
Does it get past a wrong conclusion and into a real cloud action?
Do permission limits actually help, or do they just move the problem?
What does a steered agent look like in CloudTrail, and would your current detections catch it?
What does each control cost you in legitimate investigation capability?
safety and disclosure
Everything here runs in a controlled environment on infrastructure I own. Nothing I publish will include company data, customer information, or anyone’s real configuration. This is independent research, built on eight years of doing the work and on data my own lab produces.
Every claim here is one of four things: something I observed, a hypothesis I hold, an inference I drew, or a result an experiment produced, and I’ll say which one. When a finding only holds under specific conditions those conditions sit next to it instead of in a footnote.
If I get something wrong, corrections get published rather than quietly edited into the original. If you find an error, or if something here creates a risk I didn’t account for, reach me at info@tayontech.io.