Agentic AI Security: 10 Risks Australian Organisations Need to Understand in 2026

What Is Agentic AI?

Traditional generative AI generally follows a simple pattern:

Agentic systems introduce planning, memory, tools and the ability to act:

An AI assistant might be authorised to search corporate documents, read email, query databases, create support tickets, update customer records, interact with Microsoft 365, execute scripts, query cloud environments, use security tools or communicate with other AI agents.

The model is no longer simply processing information. It is operating as part of the application. That distinction matters.

In July 2026, the Australian Signals Directorate highlighted the opportunities and risks associated with increasingly capable agentic AI. ASD recommends strict privilege controls, monitoring, human oversight, clear operating constraints and a measured rollout that begins with lower-risk use cases. See ASD's Careful adoption of Agentic AI in cyber defence and the joint Careful adoption of agentic AI services guidance.

The OWASP Top 10 for Agentic Applications for 2026 also identifies risks extending beyond traditional prompt injection. The ten risks below draw on that work, ASD guidance and established application-security principles.

1. Agent Goal Hijacking

One of the fundamental risks in an agentic system is manipulating what the agent believes it is supposed to do. This can occur through direct prompt injection, but the more concerning scenario is indirect prompt injection.

Consider an AI agent tasked with reviewing incoming documents. An attacker places hidden instructions inside a document. The agent retrieves the document and processes its contents as context. Those instructions attempt to convince the agent to perform an unintended action.

If the agent also has access to tools, the attack may progress beyond manipulating the model's response. The attacker may try to retrieve sensitive files, call another API, modify a record, disclose information, execute a command or contact another system.

OWASP categorises this as ASI01: Agent Goal Hijack. The security boundary cannot rely on the model correctly distinguishing trusted instructions from untrusted content. Applications need deterministic controls around what actions are permitted.

2. Tool Misuse

Tools are what make AI agents useful. They are also what turn a model-level security issue into a system-level security issue.

An agent may be able to search documents, send email, create users, query databases, execute code, update tickets or delete files. Each tool becomes part of the attack surface.

An attacker does not necessarily need to compromise the underlying API if they can manipulate an authorised agent into invoking it incorrectly. This is why agent security must include traditional application-security controls such as input validation, authorisation, allowlisting, rate limiting, transaction boundaries and output validation.

OWASP categorises this as ASI02: Tool Misuse and Exploitation. Tool calls should never be considered trustworthy simply because they originated from an AI model.

3. Excessive Permissions

One of the easiest ways to increase the impact of an AI security failure is to give an agent more access than it requires.

An internal AI assistant does not necessarily need the same permissions as the employee using it. An agent responsible for searching documents may only require read access. An agent generating a proposed firewall rule does not necessarily need permission to deploy it. An agent helping investigate an identity event should not automatically receive administrative access to the identity platform.

ASD recommends limiting agent permissions to the minimum required for approved tasks. For security teams, this means applying familiar principles: least privilege, least functionality, separation of duties and just-in-time access.

These principles become even more important when the identity using the privileges can make autonomous decisions.

4. Agent Identity and Credential Abuse

AI agents increasingly require their own identities. Those identities may hold API keys, OAuth tokens, service accounts, database credentials, cloud identities, secrets or delegated user permissions.

This creates an important architectural question: who is actually performing the action?

If an AI agent uses a shared privileged service account, attribution becomes difficult. If an agent inherits the full permissions of a user, compromise of the agent may provide access to everything available to that user.

Agent identities should be treated as machine identities with strict lifecycle controls. Organisations should consider unique identities, short-lived credentials, tightly scoped OAuth permissions, managed identities, secret rotation, conditional access and detailed attribution of actions.

OWASP categorises this as ASI03: Identity and Privilege Abuse. It should also form part of an organisation's broader identity and access management design.

5. Memory and Context Poisoning

Many AI agents maintain memory. That memory allows an agent to retain information from previous interactions and use it in later decisions. It also creates a persistent attack surface.

If malicious information enters long-term memory, an attacker may influence future behaviour without repeating the original attack. Data entering agent memory should not automatically become trusted.

OWASP categorises this as ASI06: Memory and Context Poisoning. Security testing should examine what information enters memory, who can modify it, how long it persists, whether it crosses user boundaries, whether malicious entries can be removed and whether stored context can influence privileged actions.

6. Agentic Supply-Chain Attacks

Modern AI applications depend on large ecosystems that may include foundation models, AI frameworks, plugins, Model Context Protocol servers, vector databases, embedding models, third-party APIs, open-source packages and orchestration frameworks.

Every component introduces another trust relationship. Model Context Protocol, or MCP, is particularly important because it allows AI applications to discover and interact with external tools and data sources. A compromised or malicious MCP server may expose an agent to unsafe functionality or manipulated information.

Agentic supply-chain security should include approved tool registries, dependency pinning, code review, package-integrity verification, MCP server assessment, tool provenance, network restrictions and monitoring for unexpected tool changes.

OWASP categorises this as ASI04: Agentic Supply Chain Vulnerabilities.

7. Unexpected Code Execution

Some agents can generate and execute code. That capability requires particularly careful security architecture.

A developer agent might inspect a repository, generate a script, execute it, install dependencies, connect to external services and modify source files. If untrusted content can influence that workflow, code execution becomes an obvious risk.

Agent-generated code should be treated as untrusted code. Controls may include sandboxing, isolated execution environments, filesystem restrictions, network egress controls, execution time limits, CPU and memory limits, dependency restrictions and human approval for high-impact commands.

OWASP categorises this as ASI05: Unexpected Code Execution. Application-specific assurance may also require source code review and testing of the surrounding execution environment.

8. Insecure Communication Between Agents

Agentic architectures may contain more than one agent. A coordinator may delegate work to research, security, finance or deployment agents. This introduces another trust boundary.

One agent may trust information received from another without independently verifying it. Attackers may attempt to impersonate an agent, manipulate messages, replay instructions, inject false task results, alter shared context or exploit differences in privilege.

Agent-to-agent communication needs the same security considerations as service-to-service communication. Identity, authentication, authorisation and message integrity still matter.

OWASP categorises this as ASI07: Insecure Inter-Agent Communication.

9. Cascading Failures

Automation can multiply both successful actions and mistakes. Imagine an AI security agent incorrectly identifies a legitimate system as compromised. It tells another agent to disable the associated identity. Another agent blocks its network access. A third revokes credentials. A fourth opens an incident and isolates related systems.

One incorrect decision has now created an operational outage. OWASP categorises this as ASI08: Cascading Failures.

High-impact autonomous actions need defined boundaries. An agent may be informational, advisory, approval-based or autonomous. Not every workflow should reach the final category.

10. Human Trust in AI Agents

A final risk does not require exploiting the model itself. People may simply trust it too much.

An AI system can produce an answer that appears confident, detailed and technically plausible while still being wrong. That becomes dangerous when a human operator approves an action because the AI recommended it.

Security controls should account for automation bias. Approval mechanisms only provide protection when the approver has enough information to make an independent decision.

Instead of asking only whether an action should be approved, a secure system should explain what will happen, which systems will be affected, what permissions are being used, why the action was selected, what data influenced the decision and whether the action is reversible.

OWASP categorises this as ASI09: Human-Agent Trust Exploitation.

How Organisations Can Secure Agentic AI

Agentic AI does not require abandoning existing cyber security principles. In many cases, the fundamentals become more important.

A secure architecture should assume that agent instructions, retrieved content, tool responses and model outputs may all be untrusted. Controls should be enforced outside the model wherever possible.

1. User and input layer: classify and validate information entering the system.
2. AI agent: define objectives, constraints, memory rules and permitted planning behaviour.
3. Security control layer: enforce identity, authorisation, policy validation, tool restrictions, approval gates and logging.
4. Approved tools: expose only scoped, reviewed capabilities with deterministic safeguards.
5. Business systems: preserve downstream access controls, monitoring and recovery mechanisms.

Organisations designing these systems should also review their broader security architecture, not only the prompt and model configuration.

Testing Agentic AI Systems

Traditional penetration testing remains important, but agentic applications require additional testing. An AI security assessment should examine the complete system rather than focusing only on prompts.

Testing may include:

• Direct and indirect prompt injection
• Agent goal manipulation and tool invocation abuse
• Permissions, authentication, authorisation and credential exposure
• Sensitive information disclosure
• Memory poisoning and retrieval-augmented generation manipulation
• MCP server and supply-chain security
• Inter-agent communication
• Code execution boundaries and sandbox escape paths
• Network egress and destructive-action controls
• Monitoring, logging and human approval mechanisms

OWASP's 2026 work reflects the same shift. Its Q1 2026 exploit round-up notes that many AI security events arise from misconfiguration, architectural design and data flows rather than discrete software vulnerabilities.

Start With Limited Autonomy

Agentic AI is likely to become a normal part of enterprise technology. That does not mean every agent needs unrestricted access to production systems.

ASD's advice to Australian organisations is practical: begin with clearly defined, lower-risk use cases, establish controls and monitoring, validate how the system behaves, and increase permissions or autonomy only as confidence and assurance mature.

The organisations that adopt agentic AI securely will not be those that attempt to eliminate every possible AI failure. They will be those that design systems so an AI failure cannot automatically become a security incident.

Assessing Your Agentic AI Attack Surface

Organisations developing or deploying AI agents should understand exactly what those agents can access, what can influence their decisions and what actions they can perform.

An effective agentic AI security assessment should review the entire architecture, including models, prompts, identities, permissions, tools, MCP integrations, retrieval pipelines, memory, APIs, execution environments and downstream systems.

As AI moves from generating answers to taking actions, securing the agent itself is only one part of the problem. The real security boundary is everything the agent is allowed to touch.