Giving a language model the ability to call tools, read internal systems and take multi-step action changes its risk profile fundamentally. A chatbot that gives a wrong answer is an inconvenience. An agent with write access to a ticketing system, a payments API or a customer database that is manipulated into misusing that access is an incident. As agentic systems move from pilot to production across enterprises, security teams are discovering that the controls built for conventional applications, and even the controls built for earlier generative AI deployments, do not fully cover the new attack surface an autonomous agent introduces.
Prompt injection is a live threat, not a theoretical one
The most distinctive risk in agentic systems is indirect prompt injection: instructions hidden in content the agent processes, an email, a web page, a document, a support ticket, that are designed to hijack its behaviour. Because agents are built to follow instructions in their context, and because the boundary between "trusted instruction from the operator" and "untrusted content the agent is processing" is not enforced by the model itself, a sufficiently crafted piece of content can redirect an agent's actions without any conventional exploit.
This is not a hypothetical concern; documented cases have already shown agents tricked into exfiltrating data, approving fraudulent transactions, or executing commands embedded in seemingly benign inputs. The mitigation is architectural rather than purely a model capability question: treat every piece of content the agent ingests from outside the trusted operator boundary, web results, email bodies, uploaded files, third-party API responses, as untrusted input, and constrain what actions the agent can take as a direct consequence of processing it.
Scoping tool access to the task, not the role
The default temptation when building an agent is to grant it broad access so it can handle whatever the user asks. This is precisely backwards from a security standpoint. Every tool and every permission an agent holds is available to an attacker who successfully manipulates it, whether through prompt injection, a compromised upstream data source, or a flaw in the agent's own reasoning. The tool surface should be scoped to the narrowest set that the specific task requires, not the broadest set that might be convenient.
In practice this means decomposing agents by function rather than building one agent with access to everything. An agent that drafts customer responses does not need write access to the billing system. An agent that triages infrastructure alerts does not need the ability to modify user permissions. Where a workflow genuinely requires broad capability, break it into narrower agents that hand off to each other with limited, auditable scopes, rather than granting one agent standing access to all of it.
Treating agent identity as a first-class problem
Many early agent deployments authenticate to downstream systems using a shared service account or, worse, a human operator's own credentials borrowed for convenience. This makes it impossible to answer basic security questions after an incident: which agent instance took this action, under what task, on whose authority. As agent deployments multiply across a business, this identity gap becomes the single biggest obstacle to both security and auditability.
Enterprises further along in agent security have adopted a workload identity model for agents: each agent, or each agent instance handling a given task, has its own scoped, short-lived credential, distinct from any human user, tied to a specific permission set and logged as a distinct principal in every downstream system it touches. This is more infrastructure to build up front, but it is the only way to make agent actions attributable, revocable, and bounded once something goes wrong.
Human checkpoints where consequence is irreversible
Not every agent action needs a human in the loop, and requiring approval for everything defeats the purpose of automation. The judgement call is identifying which actions are reversible and low-consequence, which the agent can take autonomously, and which are irreversible or high-consequence, a payment, a permission change, a customer communication, a production deployment, which should require human confirmation before execution regardless of how confident the agent's reasoning appears.
This threshold should be set deliberately during design, tied to the actual business impact of the action rather than to a generic sense of caution, and it should be enforced as a system control rather than as a prompt instruction the model is merely asked to follow. An instruction telling a model to "always ask before sending payments" is a suggestion the model can be talked out of under the right adversarial pressure. A system that will not execute a payment API call without a separate, cryptographically verified human approval is a control.
Monitoring for behaviour, not just output
Conventional application monitoring watches for errors and performance degradation. Agent monitoring needs an additional layer: watching for behavioural drift, an agent taking action sequences it has not taken before, invoking tools outside its normal pattern, or processing content that trips known injection heuristics. Because agent failures often look like confident, well-formed reasoning rather than an obvious crash, the signal that something has gone wrong is frequently behavioural rather than technical.
Building this monitoring means logging not just the agent's final output but its full action trace: which tools it called, with what parameters, in response to what input, and why, captured from the model's own reasoning where available. This trace is what allows a security team to reconstruct what happened during an incident, and it is also the raw material for tuning the guardrails and permission scopes as the agent's real-world behaviour becomes better understood.
An agent security checklist
- Treat all content an agent ingests from outside the trusted operator boundary as untrusted input, and design for indirect prompt injection accordingly.
- Scope each agent's tool access to the narrowest set its specific task requires, decomposing broad workflows into narrower, purpose-built agents.
- Give every agent instance its own scoped, short-lived, attributable identity rather than a shared service account or borrowed human credentials.
- Define irreversible or high-consequence actions in advance and enforce human approval as a system control, not a prompt instruction.
- Log full agent action traces, not just outputs, so behaviour can be reconstructed and reviewed after an incident.
- Monitor for behavioural drift, unusual tool sequences and injection heuristics, not only conventional application errors.
What good looks like
Mature agent security programmes can name, for every agent in production, exactly which tools it can call, under what identity, and which of its actions require human sign-off before execution. When something goes wrong, the action trace makes root cause analysis a matter of minutes rather than a forensic exercise. And the security model has been designed assuming an attacker can influence some of the content the agent processes, rather than assuming the agent's inputs are inherently trustworthy.
The organisations exposed by this new attack surface will not be the ones that moved slowly. They will be the ones that treated agent security as an extension of existing application security controls, rather than recognising that autonomous, tool-using systems need a security model built for their specific failure modes.
Agentic AI creates real value, but only when its security model is built for how these systems actually fail. If you are deploying agents into production and want a second opinion on the guardrails, email sales@halfteck.com.