How to Secure Enterprise Agentic AI Ambition

How to Execute

• Embedded: AI automation features within existing enterprise applications (e.g., CRM, ERM, office suite), with data sensitivity and agency determined by the host application.
• Stand-alone: AI agents developed internally, deployed locally or adopted as third-party SaaS applications (e.g., n8n, manus.ai, ChatGPT Agent, Claude Code).
• Multiagent system: Groups of AI agents that interact to automate complex workflows (see also Innovation Insight: Multiagent Systems [MAS]).

• Task-driven agents: Simple agents, designed to perform specific tasks, such as report generation or alert enrichment, with risks tied closely to data sensitivity.
• Goal-driven agents: Built on foundation models (e.g., a large language model) to orchestrate complex workflows and access diverse tools and resources, introducing new attack surfaces and amplifying potential harm. Their risks relate more to the breadth of their agency.

Figure 1: AI Agent Discovery and Initial Risk Assessment

Figure 2: The Five Workstreams of an Agentic AI Cybersecurity Program

• Inventory high-risk AI agents by mobilizing all relevant teams with a “track back” approach for sensitive enterprise applications and a complete picture of employees’ shadow AI.
• Implement access modeling with identity and application teams to grant just-enough and just-in-time privileged access to AI agents.
• Champion scoped agency, implementing least-privilege agency through AI agent tool minimization and containment among architecture and software engineering teams.
• Manage model risks by coordinating red team and application security efforts to test AI models and implement runtime controls supporting intent-based policies.
• Shorten the threat exposure window by supplementing existing incident response practices with intent-based behavioral analytics and specialized cross-team playbooks.

1. Inventory High-Risk AI Agents by Mobilizing All Relevant Teams

The number of agent-washed software solutions is exponentially higher than the number of problematic AI agents within the enterprise. Discovery of AI agents is only the first, not the greatest, challenge for cybersecurity teams, and it will overwhelm many organizations.

• Business and project owners who would decide to build or procure AI agents.
• Procurement who has visibility over new subscriptions that would enable embedded agentic features within existing enterprise applications.
• Endpoint management to automatically scan for agentic applications deployed on the endpoints.
• Identity and access management to leverage existing tools to discover agents through their use of access credentials or as part of existing identity management tools.
• Architecture, software engineering and application leads who might supervise the conversion of existing custom-built applications into AI agents.
• Network and security operation teams to customize logging systems and SIEM in order to identify network activities from AI agents, such as model context protocol (MCP) or Agent2Agent (A2A) protocols.
• Vulnerability and exposure management teams who can leverage vulnerability scanning data for additional asset discovery and provide a first assessment of their risks.

• Combine automated discovery initiatives with a “track back” approach, reusing existing risk assessment to prioritize higher risks use cases:
  • Detect new access to sensitive data.
  • Track new AI and automation features in high-risk enterprise applications.
  • Identify new sources connecting to the most sensitive enterprise APIs.
  • Monitor higher-risk employees’ access to stand-alone SaaS AI agents, AI agent platforms and remote MCP servers.
• Collaborate with IT, business and procurement to determine the rollout plan of embedded AI agents in already identified higher-risk enterprise applications and assess existing hardening options.
• Gain a complete picture of employees’ shadow AI that is under the organization’s control by combining automated technical discovery (e.g., AI usage control, MCP protocol detection) with an open and trusting employee feedback loop.
• Leverage code repository, network monitoring, workload instrumentation and project lead interviews to catch AI application transformation into custom-built AI agents.
• Influence custom-built AI agent design guidelines to favor multiple narrower-scoped AI agents rather than broader generalist AI agents, as it will be easier to apply stronger controls and monitor resources and tools.
• Map agent dependencies to identify critical tools, resources, infrastructure and development platforms, helping to prioritize cybersecurity investments.

• CISOs Must Bring Shadow AI Into the Light
• Innovation Insight for AI Usage Control
• Governance Challenges and Solutions for AI Agents

2. Implement Agent Access Modeling With Identity and Application Teams

Identity and access management leaders must work with other teams to uniquely identify each AI agent and enforce least privilege by modeling the access each agent needs to do its job.

Figure 3: Access Modeling for AI Agents

• Input (1): In the case of a fully autonomous agent, the input might be services or other AI agents.
• Model (3): When using a commercial model, access credential might take the form of API token (or worse, static credential).
• Resource (4): Enforcing least privilege to each resource could require defining and enforcing new access rules. This is important as many organizations deploy internal MCP servers to expose access to resources.
• Tool instrumentation (5): If the AI agent actions are internal to the agent, they will often use the agent core identity (1 or 2), but when instrumenting third-party tools, the agent might require a different account for each tool provider.
• Tool (6): The AI agent has access to a variety of tools that can provide a range of actions that go beyond what the agent should do.
• Tool proxy (7) such as MCP servers might instrument other tools in the back end (e.g., an API).
• Computer use (8), while limited and happening in a sandboxed environment today, may allow some AI agents to grant access to high-agency workloads, requiring limitations on that access.
• Internet (9): The AI agent will, by default, browse the internet with its own identity, but websites and SaaS applications might require the user or the agent to enter other access credentials.

• Assign each AI agent a single, unique identity
• Enforce least privilege principle with “just enough” access to tools and resources
• Enable just-in-time privilege elevation
• Integrate human-in-the-loop (HitL) to review and approve sensitive operations or review generated output
• Govern agent identities through sustainable inventory and registration mechanisms
• Manage the entire access life cycle
• Log all actions for full traceability

• Configuration hardening: The ability to create an agent policy for embedded AI agents entirely depends on the flexibility of the enterprise applications. It might be limited or granular, enable access delegation or force user identity.
  • Work with procurement and software management teams to identify initial policy options and feature upgrades enabling new possibilities.
• AI agent scope: Generalist and broad-scoped agents might leverage broader access depending on the tasks they execute and the resources they access, creating high risks, especially when sharing data of different sensitivity.
  • Work with the architecture team to scope custom-built AI agents in a way that facilitates the implementation of least-privilege access policies and minimize access to data and tools with different security requirements.
• Resource and tools: In addition to the impact of the AI agent scope, minimizing access to resources and tools to what is necessary only might require specific API access, new enforcement policies on an API gateway, or even building a new API matching the exact requirements of the AI agent.
  • Work with application, architecture and product owners to determine the right access to each tool.

• Agent identity and access governance: Beyond the initial effort, identity governance leverages up-to-date inventory and, in some cases, agent registries to maintain visibility.
• Identity and access life cycles: Implement short-span authorization when achievable and apply identity governance to detect and decommission dormant agent accounts, for example, in the case of project abandonment.

• How to Securely Delegate Access From Humans to AI Agents
• IAM for LLM-Based AI Agents
• Act Now: Implement Comprehensive AI Agent Identity Measures to Navigate Automation Trends
• Strategic Roadmap for Modern Machine IAM
• Innovation Insight: Improve Security With Machine Identity and Access Management

3. Champion Scoped Agency Through Tool Containment Among Architecture and Software Engineering Teams

To mitigate excessive agency, define agent scope early, narrow it during design, contain tool access in development and enforce boundaries at runtime.

Figure 4: Tool Containment Options When Scoping Agency

• Cybersecurity leaders must work with enterprise architecture teams to create guiding principles supporting the adoption and creation of narrower scoped AI agents that are easier to test and secure.
• When designing and developing AI agents, application and software engineering leaders must:
  • Inventory and limit tool functionalities leveraging available means building tool containment.
  • Offer a prescriptive list of available actions rather than broader tools when coding or using an agent development platform.
  • Balance technical debt and security improvement when deciding to use a standard tool or building a custom one with better controlled scope.
  • Implement mechanisms to require human review (“human-in-the-loop”) before allowing sensitive operations or releasing sensitive outputs from tools.
• During deployment:
  • Implement mechanism to enforce parameter limits (e.g., API schema enforcement).
  • Consider how existing infrastructure security tools can help you enforce policies related to acceptable tools.
• At runtime:
  • Leverage available technologies such as AI usage control, but also API, AI and MCP gateways can go beyond discovery to help enforce tool containment policies.
  • When connecting to third-party tools, consider parsing tool inputs and outputs with deterministic controls, such as rule-based policies and supervised machine learning algorithms, to detect deviation from expected tool invocation and tool results.

• How to Choose the Right Architecture to Build AI Agents
• How to Secure Custom-Built AI Agents
• Innovation Insight: MCP Gateways

4. Manage Model Risks by Coordinating Red Team and Application Security Efforts to Test AI Models and Implement Runtime Controls

Direct and indirect prompt injections are the main threats to AI agent models. Differences in inputs and outputs turn prompt injections into instruction injections, requiring new design principles, control enforcements and behavioral detections.

Figure 5: Instruction Injections: AI Agents Key Attack Surfaces and Entry Points

• Product and engineering teams should promote and evangelize safe design practices, such as combining lower privilege and higher privilege models.²
• AI teams must include AI and cybersecurity risk evaluation during model selection, with limited trust in available model benchmarks and including nontechnical risks such as copyright risks.
• Cybersecurity teams should prioritize a “test and contain” strategy over a “detect and response” only approach by:
  • Using AI red teaming to probe AI guardrails with emerging offensive security testing tools that integrate with runtime control policies.
  • Including indirect attack surfaces, such as AI agent memory or MCP server description.
  • Testing multiturn scenarios that will defeat most cybersecurity technologies available today.
  • Refining tool containment and limiting resource access based on model flaws uncovered during testing.
• Cybersecurity and application teams must choose runtime controls that:
  • Monitor all communication paths: human to agent, agent to resources, agent to tools, agent to agent and agent to human.
  • Provides low latency, granular alerting and blocking options.
  • Implement intent-based policies, analyzing the queries and responses to detect malicious or harmful human interactions, such as prompt injection, jailbreak attempt or toxic output, but also agent-to-tool and agent-to-agent intent, such as rogue behavior or tool manipulation.
  • Offer some resistance to multiturn attacks.
• Cybersecurity and legal teams must define rules for handling AI agent outputs, whether the AI agent is internal only, or part of multiagent systems involving third parties. If an organization’s agent compromises third-party components, regulators, partners or clients may hold the organization responsible. Coordinated actions should define:
  • Rules of engagements for participation in a multiagent system, such contracts and agreements to set limits, metrics and liabilities.
  • Quality assurance, monitoring and control enforcement requirements.
  • Other legal safeguards (indemnities, acceptable use policies).

• How to Build Reliable Agents Using Composite AI

5. Reduce Threat Exposure Window With Intent-Based Analytics and Cross-Team Incident Response

1. Scalability: The potential sheer volume of logs coming from a high number of recurring automations is likely to exceed the organization’s capacity and budgets. This results in logging gaps and data retention limitations, preventing incident response teams from getting appropriate context.
2. Fragmentation: Embedded agent logs remain confined to the host application, but stand-alone multiagent systems logs split between the agent logs and separate model, resource or tool logs.
3. Actionability: Logs often lack the depth needed to diagnose issues in complex, goal-driven workflows, especially in custom-built AI agents.

With fully autonomous AI agents, time-based service-level agreements become irrelevant. Automated intent-based analytics become necessary, making false positive rate the key quality metrics for incident response.

Figure 6: Building Actionable AI-Agent Logging and Alerting

• Review their existing coverage for automated software workflow, especially when embedded in enterprise software. Key triggers for updating logging policies include shifts from deterministic to nondeterministic automations.
• Determine logging possibilities and restrictions due to privacy regulations.
• Partner with infrastructure, cloud and application operations team to develop new incident response playbooks based on the type of incidents. They should evaluate the different organizations that could apply, including new specialized AI incident responders or fusion teams.
• Evaluate the integration of intent-based analytics, directly within the systems generating alerts, or as an embedded module in the incident response and threat hunting tools.
• Assess the organization’s risk tolerance and acceptable latency penalties before implementing in-line cybersecurity controls and choosing between automated blocking and detection-only modes.

• Adopt Log Management for Security Operations Use Cases
• Innovation Insight: AI SOC Agents