Agents are reaching production faster than anyone is reviewing what they can reach. The usual pattern is a service account with broad permissions, a set of tools wired up during a proof of concept, and a model deciding at runtime which of them to call.
That last part is what separates this from ordinary application security. The instructions an agent follows arrive as text, e.g. from a support ticket, a web page or an uploaded document, and anything that reaches the context window can end up functioning as an instruction. Whatever access you have given the agent is therefore available to whoever manages to get text in front of it.
The questions are close to the ones we ask on a penetration test. What can this agent reach? If it is handed a malicious instruction, what can it do with it? Who approved the tools it is able to call, and could you reconstruct afterwards what it did?
Where we help
- Establishing what your agents can actually reach in terms of identities, credentials, tools and data, which is usually more than the design says
- Reducing agent permissions to what the task needs, with a human in the loop for anything that is hard to reverse
- Building the testing into how agents are developed, so that prompt injection and tool misuse are caught while an agent is being built rather than after it ships
- Getting the logging and audit trail right, so that you can reconstruct what an agent did and on whose behalf
- Setting guardrails for the teams building agents, so that the next one starts somewhere sensible
We are not going to tell you to stop building agents, since most of this is solvable with controls you can put in place now.
Agents run on Azure, AWS, Google Cloud, OCI and Kubernetes, and they tend to fail for the same reasons cloud workloads have always failed, which is broad permissions, identities being reused, not enough logging, and nobody having thought about blast radius.