Last year your AI work was a chat window. Someone typed a question, read the answer, decided what to do next. The blast radius of a bad output was one person's attention span.
This year you gave it a keycard.
Your agent reads the ticket queue. It writes to the repo. It queries the customer database, files the expense, updates the HR record, sends the email. Nobody held a meeting about it. An engineer wired up a tool call on a Thursday because the demo looked good, and now a non-deterministic system has write access to systems your auditors care about.
I've watched three teams do this in the last six months. Not one of them ran a threat model first. Every one of them had a security review process for human access. None of it applied, because the agent wasn't a person and wasn't a service, so it fell between the two forms.
Your threat model is from the era before the model talked back
Classic application security assumes a boundary between code and data. Code runs. Data gets read. A SQL injection bug happens when someone smuggles code through the data channel, and we spent twenty years learning to parameterize our way out of it.
Language models erased the boundary on purpose. Instructions and content arrive through the same door, in the same format, and the model weighs them the same way. Text in a support ticket carries the same authority as your system prompt if the model finds it convincing.
This is why prompt injection sits at number one on the OWASP Top 10 for LLM Applications, listed as LLM01. Not number four. First. And it stays first because there's no parameterized query equivalent waiting to rescue you. You mitigate. You don't solve.
Here's what makes agents different from a chatbot. A chatbot fooled by a poisoned document tells one person something wrong. An agent fooled by a poisoned document goes and does something. The content it reads is attacker-controlled, and the tools it holds are yours.
Think about the paths into your agent right now. Inbound email. Web pages it fetches. Uploaded CVs. Jira comments from a contractor. Wiki pages anyone edits. Every one of those is an instruction channel wearing a costume.
OWASP took this seriously enough to publish a separate Top 10 for Agentic Applications on December 9, 2025, built with more than 100 contributors. When a standards body forks its own list, the shape of the problem has changed.
Excessive agency is a management decision wearing a technical costume
OWASP's sixth item, LLM06, goes by the name Excessive Agency. Too much permission, too much autonomy, too much reach.
Read the failure again and notice something: no software defect appears anywhere in it. The model behaved as designed. The tool worked as documented. The credential was valid. The damage happened because somebody chose the scope of the credential, and chose it wide.
Wide scope is the default everywhere. The service account with full table access, because narrowing it takes an afternoon. The API token with write permission, because read-only broke a feature once. The agent with unattended approval rights over refunds, because a human in the loop slows the demo down.
Nobody wrote "give the robot the master key" in a design document. It arrived through a hundred small convenience choices, each one defensible alone.
I keep meeting engineering leaders who treat this as their security team's problem. It isn't. Scope of authority is a leadership question. You'd never hand a new starter unrestricted production access on day one and call it an engineering detail. Do the same thinking here.
The money has already started talking
IBM's Cost of a Data Breach Report puts the 2026 global average at $4.99M, a 12% rise on the prior year and a record. AI-driven attacks rose 56%, led by deepfake impersonation and AI-enabled malware. An AI model inversion attack averages $6M.
One number in the report cuts the other way. Organizations running extensive AI and automation inside their security function save $1.93M per breach against organizations running none.
Read those together and you get the whole argument in two lines. Attackers reached for this technology first. Defenders who reached back are measurably better off. Sitting still is the expensive option.
What to change before Friday
None of this argues for banning agents. I've written before about how banning AI doesn't stop your team, it means you're the last to know. Ban the tool and you lose visibility, not usage.
Five changes, in the order I'd make them.
1. Write down what each agent is allowed to touch. One page per agent. Systems, credentials, irreversible operations. Most teams find the act of writing it uncomfortable, which tells you the exercise is working.
2. Scope credentials to the task, not to the team. The agent handling refunds needs refund permission under a cap. It does not need the customer table. Separate identity per agent, separate audit trail, separate revocation.
3. Put a gate in front of irreversible actions. Sending money, deleting records, emailing outside the company, changing access rights. Human approval on those four. Everything reversible runs free.
4. Log the reasoning, not only the result. When an agent does something odd, "refund issued" tells you nothing. The input it read, the tool it picked, the arguments it passed... those turn a mystery into a five-minute investigation.
5. Run the drill. Plant a hostile instruction in a document your agent reads. A line telling it to email its context to an external address works well. See how far it travels. I've never seen a team run this exercise and come away relaxed.
None of the five needs new tooling. All five need someone with authority to say the word no.
The part nobody wants to own
Security teams see the risk and lack the mandate. Engineering ships the integration and inherits a governance problem nobody scoped. Leadership hears "we're doing AI" in a board update and stops asking questions.
My own research on workplace culture found 99.5% of survey respondents reported one or more types of bad boss. The pattern behind most of those stories is the same: a decision left unmade, then blamed downward when the consequence arrived. Agent permissions are heading for exactly the same treatment, and the incident review will find an engineer who wired up a tool call rather than a leader who never set the boundary. I write more about the leadership side of this at Step It Up HR.
The technology is fine. The models do what the words in front of them suggest, and we knew this before we handed them credentials.
So here's the question I'd take into your next leadership meeting. If your agent were a new hire on day one, what would you let it do unsupervised? Now go and check what you've granted it. If the two lists differ, you have your Monday morning.