Agentic AI Security: What Changes When Your AI Takes Actions in the World

The distinction between a generative AI system and an agentic AI system is not always obvious from the user interface, but it is fundamental from a security perspective. A system that generates text in response to a query can produce harmful outputs, but the harm requires a human to act on those outputs. An AI agent that can send emails, make API calls, execute code, query databases, and interact with external services can cause harm directly, without a human intermediary. The blast radius is dramatically different.

Agentic AI deployments are growing quickly. Organisations are building AI systems that autonomously draft and send customer communications, book calendar events, update CRM records, execute trades, manage file systems, and orchestrate sequences of actions across multiple systems in response to a single natural language instruction. Each of these capabilities extends the potential impact of a security failure from "the AI said something it should not have said" to "the AI did something it should not have done, across multiple systems, potentially irreversibly."

How the Threat Model Changes

For a text-generation system, the primary threats are output quality failures and information disclosure. For an agentic system, the threat model expands substantially. Prompt injection, already a significant concern in text-generation systems, becomes an access control problem when the agent has tools. An indirect prompt injection attack that causes an agent to send an email on behalf of a user, delete files, or make external API calls is not just an embarrassing output. It is an unauthorised action with real-world consequences.

The threat model also expands to include privilege escalation, tool misuse, and multi-step attack chains. An agent that has access to a database and a file system and an email interface creates an attack surface where those three capabilities can be chained together. A successful injection might cause the agent to query the database, write results to a file, and then email that file to an attacker-specified address. No single tool capability is catastrophic in isolation; the combination is. Attackers with access to the agent's input can reason about the tool set and design attack sequences that exploit the combinations.

Least Privilege for AI Agents

The principle of least privilege, giving a system only the access it needs to perform its intended function, is well established in traditional security. It applies to AI agents, but its implementation requires deliberate design choices that are easy to overlook. An agent built to help users manage their email might be granted access to the user's full inbox, calendar, contacts, and file storage "for convenience." That access profile is far broader than necessary for most email management tasks, and it creates a much larger blast radius if the agent is compromised.

Designing AI agents with least privilege means identifying the minimum tool set required for each task the agent is expected to perform, restricting tool access to that minimum, implementing confirmation steps for high-impact actions, and designing agents that escalate to human review for actions that are unusual, irreversible, or above defined impact thresholds. These design choices reduce the impact of a successful attack significantly. An agent that can read emails but not send them, or that requires explicit user confirmation before any write action, is a much harder target than one with unrestricted tool access.

Monitoring, Logging, and Human Oversight

Agentic AI systems should be designed with the assumption that they will, at some point, take actions that were not intended. This might be the result of a prompt injection attack, a jailbreak, an unexpected input that causes the model to reason incorrectly about its tool use, or simply a bug in the orchestration layer. The question is not just how to prevent unintended actions but how to detect them quickly and, where possible, reverse them.

Comprehensive action logging is essential. Every tool call an agent makes should be logged with the context that prompted it, the parameters it used, and the result it received. This logging serves two purposes: it enables post-incident analysis to understand what happened and how, and it provides the data needed to detect anomalous behaviour through monitoring. Alerts on unexpected action patterns (an agent making an unusually large number of external API calls, writing to file paths outside its expected scope, or taking actions at times inconsistent with user activity) can surface a compromise in progress. Human escalation pathways for high-impact or unusual actions are not just a safety measure; they are a security control.

• Agentic systems can take real-world actions, not just generate text -- the blast radius of compromise is larger
• Prompt injection in an agentic system becomes an access control failure, not just an output quality failure
• Multi-tool chaining creates attack paths that are not obvious from looking at individual tool capabilities
• Least privilege design -- restricting agents to the minimum tool set needed -- is a primary risk control
• Confirmation steps and human escalation for high-impact actions are security controls, not just UX choices
• Comprehensive action logging is necessary for detection and post-incident analysis

If your organisation is deploying agentic AI systems and wants to assess the security architecture and threat model, Cyberlinx can help. Contact us at info@cyberlinx.com.au.