This post is based on Mackenzie's conversation with Abdel Sghiouar on The Secure Disclosure podcast. Listen to the full episode or watch below.
If you give an agent the run of your cluster, it can trace a problem through every layer of the stack faster than any on-call engineer. But that same reach makes the agent worth hijacking. Taking away its write access stops it from breaking the cluster, but a read-only agent can still read every secret the cluster will show it, and a hijacked one can be made to leak it.
Abdel Sghiouar has spent 13 years at Google and is now a senior cloud developer advocate focused on Kubernetes and cloud native. He thinks that prompt injection doesn't capture the full scope of the vulnerability for agents. Prompt poisoning is his word of choice. Mackenzie sat down with him to talk about AI agent security in Kubernetes, and what changes once an agent is the one at the helm.
Abdel's answer is to trust but verify, though he admits the trust half is still an open problem.
What can an AI agent reach in your cluster?
Once an agent is involved, the first question is whether it has the right level of permission. In Kubernetes, that comes down to role-based access control (RBAC). An operations agent usually ends up with broad read access because it needs signals from across the cluster to do its job, and that access is exactly what an attacker goes after.
Abdel sees two ways an attacker can turn that access against you. The first is poisoning what the agent reads. Application logs are one of the signals an operations agent pulls in, so an attacker who can get text into those logs can get text into the agent's prompt. "The application would receive the data, it would write all that stuff to disk, and then the agent would read it."
This is why Abdel prefers the term prompt poisoning. Prompt injection invites comparisons to SQL injection, which is solvable with parameterized queries, but a large language model has no equivalent way to keep instructions and input apart. It processes the system prompt, the user's instructions, the conversation history, and whatever it has pulled into context at the same moment, so a log line written by an attacker can carry the same weight as an instruction from the operator.
The second risk is what the agent can read once it has been turned. If its permissions cover everything the pod can see, "it can read secrets, it can read environment variables," and it’s all exposed the moment the agent follows the wrong instruction. Poisoning gets the attacker into the agent's head, and over-broad read access decides how much they walk away with.
Why read-only access isn't enough
Most of the teams Abdel has seen running Kubernetes with agents start them in read-only mode. That protects the cluster, since an agent that can only read can't delete a deployment or drain a node. And, as Mackenzie pointed out, without read access, the agent is barely useful. More importantly, a read-only agent still reads the secrets, and it still ingests whatever poison made it into the logs.
Mackenzie pointed to the same pattern outside the cluster. Aikido Security found a prompt injection (or prompt poisoning) in the GitHub workflow Google uses to triage issues on its Gemini CLI repository, where a crafted issue could get the agent to hand over the environment variables it had access to. Google’s fix stopped the agent from handing those variables back, which closed that particular leak, but left it open to poisoning in the first place.
Abdel's view is that the security mechanisms teams already rely on "still apply to agents." What changes is that you now have a component making decisions you can't take at face value. A language model can hallucinate, so "you can't completely trust that the reasoning of the agent is correct." His answer is to trust but verify, with a human in the loop checking what the agent does, though he's candid that this is "one of the biggest problems going forward" and something the industry hasn't solved yet.
Where Aikido Security fits
Aikido AI Pentesting can test AI capabilities. It feeds poisoned input through retrieved documents and tool output to see whether any of it overrides the agent's instructions, and whether a poisoned agent can be pushed into calling tools or reaching systems it shouldn't. It also tells you whether your agent can be talked into working for someone else.
The rest comes down to how much that agent can reach if it's been turned. Infrastructure as code checks catch an overly broad ClusterRole or cloud identity and access management role in the pull request, including ones the agent proposes itself, and secrets scanning finds hardcoded credentials before they end up in an environment variable the agent can read. Container image scanning covers the workloads your agent trusts as well as the agent's own image, flagging vulnerable packages and malware in both.
Once the agent is running, Aikido Cloud checks the permissions it holds, which aren't always the ones the pull request granted. It flags Kubernetes RBAC bindings that give the agent more reach than its job needs, and posture checks catch when the agent's workload identity maps to a cloud role with admin rights. Reachability and attack path analysis then tie those findings together, showing which ones an agent could chain to get from its pod to something that matters, such as a production database or a cloud admin credential.
{{cta}}
