You trained your people to spot a suspicious link. Then an engineer connected an AI agent to a repo and a Slack channel. That agent never clicks a link, but it follows instructions hidden in tickets and documents.
Your awareness program covers people only. The attack surface is no longer static, and it just grew.
This post busts three common myths, compares a tested agent with an untested one, and lists practical steps to measure agent risk.
Three Myths About Agent Risk
Myth: “A sandbox keeps the agent contained”
A sandbox limits what the runtime can touch. It does not limit what a well-instructed agent is willing to do. If a hidden prompt convinces the agent to share data or change a permission, the damage happens through allowed API calls.
Myth: “Our SIEM will catch it”
Maybe. But only if the agent’s actions are logged, the logs are shipped, and a detection rule exists for that exact behavior. Many teams have none of the three yet. The gap between the instruction and the alert is where the damage sits.
Myth: “Better system prompts fix prompt injection”
A better prompt does not stop an attacker who hides a payload in a document the agent is built to read. Treat this as an authority and input problem, not a wording problem. Teams that rely on agentic AI security as a prompt-tuning task fix the wrong thing.
Tested Agent Versus Untested Agent
| Area | Untested agent | Tested agent |
|---|---|---|
| Hidden instructions | Follows them if the source looks trusted | Probed with adversarial playbooks before an attacker tries |
| Authority | Obeys anyone who claims to be an admin | Tested against authority impersonation |
| After a failure | A ticket waits in a backlog | Hardening steps are generated and a one-click re-test follows |
| Visibility | A conversation, not a metric | One risk index covers people and agents |
Prompt injection is phishing for machines. The target changed. The trick did not: give it a believable instruction inside a trusted channel.
How to Start Testing Your Agents
- Build an agent inventory. List every agent, what it connects to, and whose access it uses. You cannot test an agent you cannot name.
- Map inherited authority. Every agent an engineer connects to a repo or an MCP server inherits that engineer’s access. The agent’s exposure is that person’s exposure.
- Run adversarial playbooks. Cover prompt extraction, boundary probing and authority impersonation. A structured program of AI agent red teaming beats a few ad hoc jailbreak attempts.
- Fix and re-test. Turn each failure into a hardening step. Then re-run the same test and confirm the fix worked.
- Merge the scores. Put agent results on the same index as human risk, so the board and the SOC see one number.
Frequently Asked Questions
Is there such a thing as an AI agent?
Yes. An AI agent is software that takes on real work, such as reading tickets or acting in a repo, with the access of the person who set it up. That access is what makes it a target.
What is artificial intelligence security?
It is the practice of protecting AI systems from misuse and attack. For agents, that means testing how they respond to hostile instructions and limiting what they can do with inherited access.
How do you measure the risk of an AI agent?
You measure what the agent can reach and whose authority it carries. Cimento offers agent inventory, adversarial playbooks and one-click re-tests, and it is in early access with design partners.
Can agent risk sit in the same program as employee phishing?
Yes. Both involve an entity that receives an instruction and decides to act. One workforce risk index for humans and machines gives you one answer to a single question: how likely is a successful attack right now?
The Cost of Leaving Agents Untested
An untested agent is an open door that nobody has tried. It holds real access and reads content that anyone can write. When an attacker finds the door first, you learn about it from the damage, not from a test report. Each week you wait adds more agents, more access and more unmeasured exposure.
