Securing Agentic AI: Strategies for Enterprise Protection

Artificial intelligence is moving beyond suggestion towards direct action. Traditional generative AI produces responses, while agentic systems can interpret information, use tools, access business systems and complete tasks with limited human intervention.

This shift can improve efficiency, but it also changes the security challenge. An agent with access to email, customer records, financial systems or internal applications can turn a manipulated instruction into a real business action. Prompt injection, excessive permissions, poor data controls and weak monitoring may lead to unauthorised access, data exposure or operational errors.

Moving from AI pilots to production requires more than selecting a capable model. Organisations need to govern identity, instructions, data, tools and outcomes across the agent’s lifecycle. Existing Microsoft security investments can support this approach when they are configured with suitable telemetry, clear ownership and an effective response process.

Defining Agentic AI Security

Agentic AI security is the practice of protecting AI systems that can interpret information, make decisions and take actions through connected tools or services. It covers the full lifecycle of an agent, including its model, instructions, memory, identity, data access, tool permissions and operating environment.

A conventional generative AI application may produce a response for a user to review. An agent may instead retrieve information, update a record, send a message or initiate a workflow. The security consequences depend on the agent’s permissions and the controls around each action.

A practical security model should address three areas:

• Identity governance, to establish which agent is acting and what it is allowed to access.
• Action monitoring, to record and assess tool calls, decisions and unusual behaviour.
• Data protection, to control which information an agent can retrieve, process or share.

Why Autonomous Agents Require Additional Controls

Traditional perimeter controls are not enough when an agent can operate with user or service permissions. The system may be technically authenticated but still make an unsafe decision because it received malicious content, misunderstood an instruction or used a tool outside its intended purpose.

Security teams therefore need to govern more than access. They also need to consider instructions, context, tool use and outcomes. High-impact actions such as financial transfers, changes to production systems or deletion of records should require appropriate approval and monitoring.

This does not mean every agent must be manually supervised at every step. Lower-risk tasks can remain automated when their permissions, boundaries and recovery options are clear. The level of oversight should reflect the sensitivity and reversibility of the action.

Identity & Access Management for AI Agents

Treat AI agents as distinct non-human identities rather than as anonymous software processes. In Microsoft environments, Microsoft Entra ID can support identity and access controls for applications, service principals and managed identities. CyberOne provides further context on securing agentic AI through identity governance. 

Apply least privilege to each agent. Restrict access to the APIs, databases, files and actions required for its approved purpose. Separate development, testing and production identities, and avoid using highly privileged accounts for routine automation.

Access should also be reviewed when an agent’s purpose changes. An agent originally designed to summarise internal documents may require very different controls if it later gains the ability to update customer records or initiate transactions.

A structured assessment can help organisations map agent identities to business objectives, data classifications and risk ownership. The assessment should result in clear actions rather than simply a list of technical findings.

Key Threats to Autonomous Agents

Agentic systems can be manipulated through malicious inputs, excessive permissions, insecure integrations or weaknesses in the surrounding application. Important risks include:

• Indirect prompt injection
• Unauthorised tool use
• Privilege escalation
• Sensitive data disclosure
• Insecure API calls
• Excessive resource consumption
• Weak logging and delayed incident detection

These risks do not exist in isolation. An agent with limited permissions may cause little harm if manipulated. The same instruction could have serious consequences if the agent can access confidential data or perform irreversible actions.

Indirect Prompt Injection

Indirect prompt injection occurs when an agent processes untrusted content containing instructions that attempt to influence its behaviour. The content might come from an email, web page, document, support ticket or supplier record.

For example, an agent instructed to summarise supplier documents may encounter text that tells it to ignore its original task and disclose information from another source. Whether the attempt succeeds depends on the agent’s design, permissions, content controls and output validation.

Organisations should treat external content as untrusted input. Controls may include content filtering, separation of instructions from retrieved data, tool restrictions, output validation and approval for sensitive actions. Testing should use realistic documents and workflows rather than relying only on simple prompt examples.

Tool Call Manipulation & API Security

The tool layer converts an agent’s reasoning into an API call or system action. Weak validation at this point can allow an agent to send data to an unintended destination, call an unauthorised function or use parameters outside the approved scope.

Each tool should have a defined purpose, permitted input, permitted output and clear owner. APIs should validate requests independently rather than assuming that an authenticated agent has made a safe decision. Sensitive actions should generate logs that can be reviewed by security and operational teams.

Implementing Governance & Security Controls

Effective governance combines human oversight, automated enforcement and ongoing testing. Begin by classifying actions according to their potential impact.

Low-risk actions, such as drafting a response or organising approved information, may be suitable for controlled automation. Higher-risk actions, such as changing access rights, making payments or deleting records, should require approval or additional verification.

Red-team testing can help identify weaknesses in instructions, memory, tool permissions and recovery processes. Testing should cover both direct attacks and realistic business scenarios involving emails, documents, web content and connected applications.

Document who owns each agent, what it is allowed to do, which data it can access and how it should be disabled. Without clear ownership, incidents may be delayed because responsibility is divided between the AI team, application owner, infrastructure team and security operations centre.

Governing Data with Microsoft Purview

Data governance is central to agentic AI security. An agent cannot protect information appropriately if the organisation does not know where sensitive data is stored, who owns it or how it can be used.

Microsoft Purview may support data discovery, classification, sensitivity labelling, data loss prevention and governance activities, subject to the organisation’s licensing and configuration. These controls can help define how sensitive information is accessed and shared across users, applications and AI-enabled workflows.

Policies should reflect the agent’s purpose. An agent that handles internal documentation may need access to selected business records, but not to personal data, privileged legal material or unrestricted customer information. Data controls should also account for retention, logging and downstream systems.

CyberOne’s guidance on using Microsoft Purview to govern AI activity and protect enterprise data provides additional context for organisations building data governance around AI adoption.

Monitoring Agent Activity in Microsoft Sentinel

Microsoft Sentinel can support monitoring when agent activity, identity events, API calls and connected system logs are available. Security teams may use this telemetry to investigate unusual access, unexpected tool calls, authentication changes, data transfers and activity outside normal patterns.

Custom analytics and Kusto Query Language queries can help identify suspicious events, but Microsoft Sentinel does not independently understand an agent’s intent or prove that a decision was safe. Detection quality depends on log coverage, useful baselines, detection logic and the organisation’s response process.

CyberOne’s guide to detecting AI threats with Microsoft Sentinel explains how monitoring depends on relevant identity, application, API, cloud and AI-related telemetry.

Microsoft Defender for Cloud may support security monitoring for relevant cloud workloads and infrastructure. The precise controls available will depend on the architecture, connected services and configuration. A complete approach should cover the agent, its host environment, identity, data sources and connected tools.

Managed Detection & Response for Agentic AI

Agents may operate outside normal business hours, which can increase the time available for an attack or error to cause harm. Managed detection and response can provide additional monitoring, investigation and escalation when internal teams do not have the capacity to operate continuously.

Managed services do not remove the need for good agent design. They are most effective when the organisation has defined owners, suitable logs, documented response procedures and clear thresholds for escalation.

CyberOne can support organisations by assessing AI-related control gaps, connecting them with wider cyber maturity priorities and helping to operationalise Microsoft security capabilities. The appropriate service should be positioned according to the confirmed scope of the engagement.

The AssureAI Framework for Secure Innovation

An AI security assessment can help organisations examine identity management, data protection, model use, tool permissions, monitoring and incident response. The output should be a prioritised roadmap linked to business risk rather than a general statement of compliance.

CyberOne’s AssureAI readiness review and roadmap assesses AI usage, identity, data security, device management, governance, monitoring and attack-surface exposure. [cyberone.security]

Where the assessment includes stress testing of agent reasoning or tool access, those activities should be explained clearly so buyers understand the outcome they can expect.

The goal is not to eliminate all risk from autonomous systems. It is to make risk visible, limit the potential impact of failure and provide a practical route to recovery.

Building a Resilient Foundation

Moving from AI pilots to production agents requires organisations to govern how systems reason, what they can access and which actions they can take. Identity controls, data governance, tool validation, human approval and continuous monitoring should work together.

Microsoft Entra ID, Microsoft Purview and Microsoft Sentinel can form part of this architecture where they match the organisation’s requirements and are configured with appropriate controls. They should be supported by secure development, supplier assurance, testing and incident response planning.

CyberOne can help organisations assess readiness, prioritise improvements and operate security controls across their Microsoft environment. The next step may be an AI-focused assessment, a review of agent permissions or a broader cyber maturity assessment through AssureMAP, depending on the organisation’s current position.

Contact a CyberOne expert for an assessment.

Frequently Asked Questions