The New Security Risks of Agentic AI
Generative AI began by answering questions, summarising documents and creating content.
Agentic AI goes much further.
An AI agent can access applications, retrieve organisational data, invoke tools, update records, send emails, modify files and execute multi-step workflows on behalf of a user.
That transition—from generating information to taking action—fundamentally changes the security problem.
A compromised chatbot might produce a misleading response. A compromised AI agent could misuse credentials, extract sensitive information, alter business records or trigger an unauthorised transaction.
The question organisations must now answer is no longer simply:
“Is the AI model secure?”
It is: “What can this agent access, what actions can it perform, and who is accountable when something goes wrong?”
What Is Agentic AI?
Agentic AI refers to AI systems designed to pursue an objective with a degree of autonomy.
Instead of waiting for individual prompts, an AI agent may:
- Break an objective into smaller tasks
- Decide which tools or applications to use
- Retrieve information from multiple systems
- Maintain contextual memory
- Communicate with other agents
- Execute actions
- Evaluate results and modify its approach
For example, an HR agent might review résumés, access candidate data, schedule interviews and send communications.
A security agent might investigate an alert, query endpoint telemetry, analyse identities, isolate a device and create an incident ticket.
These capabilities offer significant operational value—but they also create a new category of machine identity with access to real systems and data.
Why Traditional AI Security Is No Longer Enough
Traditional generative AI security has largely concentrated on areas such as:
- Data leakage
- Model manipulation
- Insecure output handling
- Hallucinations
- Prompt injection
- Training-data poisoning
- Intellectual-property exposure
These risks continue to exist in agentic systems. However, autonomy increases their potential impact.
Consider an indirect prompt-injection attack.
A malicious instruction may be hidden inside a document, webpage, email or data source that an AI system is asked to process.
A conventional AI assistant might follow the instruction and generate a manipulated answer.
An agentic system could follow the same hidden instruction and then:
- Retrieve confidential files
- Forward information externally
- Change a system configuration
- Create a new user
- Approve a workflow
- Execute a malicious command
The weakness may begin at the prompt layer, but the damage is determined by the agent’s permissions and connected tools.
Seven Critical Security Risks in Agentic AI
1. Excessive Agent Permissions
An AI agent is often granted broad access so that it can complete different tasks without interruption.
This may include access to email, cloud storage, source-code repositories, customer databases, HR platforms or administrative interfaces.
These permissions can create a dangerous blast radius.
An agent that only needs to read support tickets should not be able to delete them. An agent responsible for drafting an email should not automatically be permitted to send it externally.
Every permission granted to an agent represents a potential attack path.
The principle of least privilege must therefore apply to AI agents just as strictly as it applies to employees, applications and service accounts.
2. Prompt Injection Leading to Tool Misuse
Prompt injection becomes considerably more dangerous when an agent can invoke tools.
An attacker may embed an instruction inside content that the agent is expected to read. If the agent treats that untrusted content as an authoritative command, it may misuse an approved tool.
The tool itself may not be compromised. The agent may technically be operating as designed.
The failure occurs because the system does not reliably separate:
- The user’s original objective
- System-level instructions
- Retrieved external content
- Tool output
- Potentially malicious instructions
Organisations must assume that any content retrieved from an external or user-controlled source could contain adversarial instructions.
3. Insecure MCP Servers and Tool Connections
The Model Context Protocol, or MCP, allows AI applications to connect with tools and data sources through a standardised interface.
This can accelerate integration, but it also creates an important security boundary.
An insecure or misconfigured MCP server may expose sensitive organisational capabilities without adequate authentication or authorisation.
Potential risks include:
- Unauthenticated access
- Overprivileged tool execution
- Malicious or manipulated tool descriptions
- Sensitive data exposure
- Inadequate user-context enforcement
- Supply-chain compromise
- Remote execution through connected tools
Microsoft reported observing remotely exposed MCP servers that permitted unauthenticated interaction with internal tools and sensitive data. This demonstrates why MCP servers must be treated as production-grade application infrastructure—not harmless AI plugins.
4. Agent Identity and Accountability Gaps
Human users normally have identifiable accounts, assigned roles and established authentication controls.
AI agents may operate through:
- Shared service accounts
- Application credentials
- User-delegated tokens
- API keys
- Embedded secrets
- Temporary cloud identities
If several agents use the same identity, investigators may not be able to determine which agent performed a specific action.
Every production agent should have a unique, manageable and auditable identity.
Security teams must be able to answer:
- Which agent performed the action?
- Who owns that agent?
- Which user or business process authorised it?
- What permissions did it use?
- Which data sources influenced its decision?
- Can its access be immediately revoked?
Without these answers, agent activity becomes difficult to govern, investigate and contain.
5. Memory Poisoning
Many AI agents retain information from earlier interactions to improve continuity and performance.
If untrusted or manipulated information enters this memory, it can influence future decisions long after the original interaction has ended.
An attacker may attempt to make an agent remember:
- A fraudulent approval rule
- A malicious destination
- An incorrect system instruction
- A fake identity relationship
- A dangerous operational preference
Memory must therefore be treated as a sensitive data store.
Organisations need controls for memory validation, retention, access, monitoring and deletion. Agents should not permanently trust information simply because it appeared in an earlier interaction.
6. Multi-Agent Trust Failures
In a multi-agent architecture, one agent may delegate a task to another specialised agent.
For example:
- A planning agent defines the objective
- A research agent gathers information
- An execution agent performs an action
- A validation agent checks the result
This structure can improve performance, but it also creates complex trust relationships.
A compromised agent could pass malicious instructions or false information to another agent. The receiving agent may act on that information because it assumes another internal agent is trustworthy.
Communication between agents must be authenticated, authorised, validated and logged.
An instruction should not automatically become trusted merely because it originated from another AI agent.
7. Human Oversight That Exists Only on Paper
Many organisations claim that a human remains “in the loop.”
However, a confirmation button alone does not create meaningful oversight.
If an employee receives hundreds of approval requests, cannot see the reasoning behind an action or does not understand its potential impact, the approval becomes a formality.
Effective human oversight should provide:
- A clear description of the intended action
- The systems and data involved
- The potential consequences
- The identity under which the action will run
- The ability to modify, reject or reverse the action
- Additional approval for high-risk activities
Human approval must be informed, deterministic and proportionate to the risk.
A Zero-Trust Approach to AI Agents
AI agents should not be trusted because they operate inside the organisation or use an approved model.
Zero Trust principles remain highly relevant:
Verify Explicitly
Authenticate the agent, user, device, workload and requesting context before permitting access.
Use Least-Privilege Access
Grant only the minimum permissions required for the current task. Separate read, write, delete and administrative privileges.
Assume Breach
Design the system on the assumption that an agent, prompt, tool or data source could be compromised.
Limit the Blast Radius
Use isolated environments, scoped credentials, transaction limits and restricted tool sets.
Continuously Monitor Behaviour
Detect unusual access, unexpected tool usage, privilege escalation, abnormal data movement and deviation from approved workflows.
Practical Controls for Securing Agentic AI
Organisations preparing to deploy AI agents should establish the following controls.
Maintain an Agent Inventory
Document every deployed agent, including:
- Business purpose
- Owner
- Model and framework
- Connected tools
- Data sources
- Identity
- Permissions
- Operational environment
- Risk classification
- Review date
Unknown or abandoned agents can become the AI equivalent of shadow IT.
Assign a Unique Identity to Every Agent
Avoid shared credentials wherever possible.
Use managed identities, short-lived tokens and centrally controlled secrets. Connect each agent’s activity to its owner and the initiating user or process.
Enforce Least Privilege
An agent should receive the minimum access required for a specific task and duration.
High-risk permissions should be granted temporarily rather than permanently.
Separate Planning from Execution
Do not allow the same uncontrolled component to interpret untrusted content, plan an action and execute it with privileged access.
Introduce policy checks and deterministic control points between these stages.
Require Approval for High-Impact Actions
Human approval should be mandatory for activities such as:
- Financial transactions
- External communications
- Privilege changes
- Deletion of data
- Production modifications
- Disclosure of sensitive information
- Legal or compliance decisions
Validate Tools and MCP Servers
Security teams should assess:
- Authentication and authorisation
- Transport encryption
- Tool definitions and metadata
- Data exposure
- Input and output validation
- Secret management
- User-context enforcement
- Logging and monitoring
- Dependency and supply-chain risk
Create Complete Audit Trails
Logs should capture more than the final action.
They should include:
- User objective
- Agent identity
- Retrieved information
- Tools invoked
- Permission used
- Approval decision
- Action performed
- Result
- Errors and retries
Sensitive reasoning data should be handled carefully, but security teams still need sufficient context to reconstruct an incident.
Build an Agent Kill Switch
Organisations must be able to:
- Disable an agent
- Revoke its credentials
- Terminate active sessions
- Block specific tools
- Stop ongoing workflows
- Isolate affected systems
- Preserve evidence for investigation
Containment should not depend on waiting for the development team to modify the agent’s code.
What Security Teams Should Ask Before Deployment
Before an AI agent enters production, ask:
- What exact business objective does the agent serve?
- What data can it access?
- Which tools can it invoke?
- Can it modify or delete information?
- Does it have a unique identity?
- Are its permissions task-specific?
- Can untrusted content influence its instructions?
- Which actions require human approval?
- Are all decisions and tool calls logged?
- How will anomalous behaviour be detected?
- Can the agent’s access be revoked immediately?
- Who is accountable for its actions?
If these questions cannot be answered clearly, the agent is not ready for uncontrolled production use.
The Growing Role of Cybersecurity Professionals
Agentic AI will not remove the need for cybersecurity professionals. It will expand their responsibilities.
IAM teams will need to manage agent identities and delegated permissions.
SOC teams will need to monitor agent behaviour and investigate agent-driven incidents.
Application-security professionals will need to test prompt boundaries, tool integrations and execution workflows.
GRC teams will need policies covering accountability, risk acceptance and third-party agents.
Privacy professionals will need to assess how agents collect, retain, infer and disclose personal data.
Incident responders will need methods for preserving agent logs, reconstructing decisions and containing autonomous workflows.
The future security workforce will not only defend users, devices and applications. It will also govern digital actors capable of making and executing decisions.
Final Thoughts
The biggest risk in agentic AI is not simply that an agent may produce the wrong answer.
It is that the wrong answer may automatically become an action.
Organisations should treat every AI agent as a powerful digital identity operating across applications, data and business processes.
The fundamental security questions remain familiar:
Who are you?
What are you allowed to access?
What are you allowed to do?
How do we verify your behaviour?
How do we stop you when something goes wrong?
Agentic AI may be new, but secure adoption will still depend on disciplined identity management, least privilege, defence in depth, continuous monitoring and accountable human governance.The organisations that answer these questions early will be better positioned to benefit from AI autonomy without losing control of it.
