For the first couple of years, the security question about language models was whether they would say something wrong. Now they are being given tools, and the question is whether they will do something wrong.
That shift changes the risk model completely, and most of the answers come from security principles that are decades old.
What an Agent Actually Is
Strip away the marketing and an agent is a loop. A model receives a goal, decides on an action, calls a tool, reads the result, and decides again until it thinks it is done.
The tools are ordinary software: an API call, a database query, a file write, a shell command, an email send. Standardized connector interfaces such as the Model Context Protocol have made attaching those tools much easier, which is why this pattern spread quickly.
So the security question is not mysterious. It is the same question you would ask about any process running in your environment: what can it reach, what can it do, who authorized it, and what is recorded.
The Confused Deputy Problem, Restated
A confused deputy is a program with more privilege than its caller that can be tricked into using that privilege on the caller's behalf. It is a well understood class of flaw from the 1980s.
An AI agent is close to an ideal confused deputy. It holds credentials, it acts on instructions, and it cannot reliably tell instructions from data because both arrive as text.
Combine that with indirect prompt injection and you have the core threat: content the agent reads tells it to do something, and it has the permissions to comply.
Permission Design
Give each agent its own identity, not a shared service account and definitely not a human's credentials. You need to be able to see what the agent did as distinct from what a person did.
Scope permissions to the specific task, and prefer read only wherever the job allows it. The most common real world mistake is granting broad access during a proof of concept and never narrowing it afterwards.
Use short lived credentials. If an agent's token is captured, the exposure window should be measured in minutes.
Separate agents by trust level. An agent that reads public web content should not be the same agent that has write access to production.
Approval Gates for Consequential Actions
Split actions into tiers. Reading is one tier. Writing, sending, paying, deleting, and changing permissions are another.
For the second tier, require human approval, and make the approval prompt show the actual action with its actual parameters. An approval screen that says the agent would like to complete your request is worthless. It needs to say it will send this specific message to this specific address, or transfer this amount to this account.
Watch for approval fatigue. If the gate fires forty times a day, people will click through it without reading. Tune it so it fires on things that genuinely matter.
Boundaries Around Execution
If an agent runs code, run it somewhere disposable with no network access it does not need and no credentials sitting in the environment. This is standard sandboxing and it applies unchanged.
If an agent browses the web, treat everything it reads as hostile input. Consider restricting which domains it may fetch, particularly for agents that also hold internal permissions.
If an agent writes to a system of record, constrain what it can write. Schema validation and business rule checks on the write path catch a lot, and they do not depend on the model behaving.
Logging and Investigation
Log the goal it was given, the context it retrieved, every tool call with parameters, every result, and the final output. Without that chain you cannot answer the only question that matters after an incident, which is why did it do that.
Feed those logs into your SIEM like any other application. Agent activity is exactly the kind of thing that should be alertable: an agent that suddenly starts calling a tool it has never used, or accessing a data set outside its normal pattern, is a detection opportunity.
Connectors Are Third Parties
Every connector and integration is code from someone else running with access to your data. The ecosystem around agent tooling has grown quickly, with a lot of community published connectors and uneven review.
Apply third party risk thinking: who maintains it, what permissions does it request, is the source available, is it pinned to a version, and what happens if it is compromised. Auto updating a connector that holds credentials is a supply chain risk in the same category as any other dependency.
A Short Checklist
Own identity per agent. Least privilege, read only by default. Short lived credentials. Untrusted content isolated from privileged tools. Human approval on consequential actions, showing real parameters. Sandboxed execution. Full logging into the SIEM. Connectors reviewed and pinned. A kill switch you have actually tested.
None of that is novel. It is the same set of controls you would apply to any automated process with production access, which is the right way to think about it. See zero trust for the general principle.
Learn This at HackRange
The mentorship treats AI systems as ordinary systems with unusual inputs. That framing is what makes the security work tractable.