Cybersecurity • 1 day ago • Shruti Das
For years, enterprise AI security was largely framed around a familiar question: what happens when employees put sensitive information into an AI model? That question is no longer enough. The more consequential shift is happening as enterprises move from AI that answers questions to AI that takes action. Agentic AI systems can retrieve information, call APIs, interact with applications, execute workflows, write and run code, and make decisions across multiple steps with limited human intervention. As these systems move deeper into enterprise environments, they are becoming something security teams have not traditionally had to manage at this scale: software that can reason, act and operate across systems on behalf of a user or organization.
That shift is already showing up in the threat landscape. Google Threat Intelligence Group reported in September 2026 that adversaries are moving from basic prompting toward agentic AI workflows and AI-enabled automation. In one observed campaign, attackers compromised a cloud resource and then used it to plan, build and execute a mass credential-harvesting operation in less than six hours. Anthropic’s latest threat intelligence report similarly describes cyber operations in which AI was used not merely as an assistant, but as an orchestrator across reconnaissance, exploitation, persistence and data exfiltration.
For enterprises, the implication is bigger than the possibility of an AI model being manipulated. The emerging concern is that AI systems with access to enterprise resources can themselves become part of the attack chain. When an agent can interact with applications, access data and invoke tools, a successful attack no longer needs to stop at the model. It can potentially move through the agent’s permissions and connections into the wider enterprise environment.
The Attack Surface Is Moving Beyond the Model
Traditional AI security discussions tend to focus on the model itself: prompt injection, malicious inputs, model manipulation, data leakage and unsafe outputs. Those risks remain important, but an enterprise AI agent is more than a model. It typically operates through a broader software layer that connects the model to enterprise data, applications, APIs, tools, memory and external services.
That surrounding layer is becoming an increasingly important security boundary. The Australian Signals Directorate’s September 2026 guidance on agentic AI specifically highlights the security implications of the agentic AI harness—the software layer that allows a model to interact with organizational data, tools and systems. The guidance identifies risks spanning privilege, design and configuration, behavior, system structure and accountability, while recommending controls such as least-privilege access, monitoring, audit logging and human oversight for high-impact actions.
This distinction matters because compromising an isolated chatbot and compromising an AI agent connected to an organization’s CRM, cloud environment or internal knowledge base are fundamentally different security events. In the second scenario, the attacker gains something considerably more valuable than access to a model: capability. The agent already has the tools and permissions needed to perform useful work, and those same capabilities can become pathways for abuse if the surrounding controls are weak.
The Real Problem Is What an Agent Is Allowed to Do
An AI agent does not need malicious intent to become a security risk. An enterprise might give an agent permission to access customer records because it needs that information to resolve support requests, or allow it to interact with an internal repository so it can summarize documents. Another agent might be permitted to create tickets, update databases, change cloud configurations or invoke APIs as part of an automated workflow.
The security implications emerge when those legitimate permissions intersect with manipulated instructions, poisoned data, compromised connectors or malicious external inputs. Imagine an enterprise deploying an agent that monitors customer-support requests, retrieves account information and updates a CRM. If an attacker manages to introduce malicious instructions into a source that the agent is authorized to access, the agent may interpret those instructions as part of its task, retrieve information it should not expose and pass the result into another connected system. The underlying model may not have been directly compromised; the agent may simply have followed instructions inside an environment where trust boundaries were poorly defined.
That is one of the defining security challenges of agentic AI. The very capability that makes agents attractive to enterprises—their ability to interpret information and take actions across multiple systems—is also what can allow an attack to propagate further than a conventional AI interaction.
Identity Becomes an Agentic AI Problem
Enterprise security has spent decades building controls around human identities. Employees authenticate, receive permissions and are monitored as they interact with corporate systems. AI agents complicate that model because they may operate using delegated user credentials, dedicated machine identities, API keys or combinations of permissions across multiple services.
This creates a new layer of identity questions for security teams. Who owns an agent’s identity? What permissions should it receive? How long should those permissions remain valid? Can security teams distinguish an agent’s actions from those of the human who initiated a workflow? Can one agent invoke another with a different set of privileges? And what happens when an agent’s credentials are compromised?
These questions make the principle of least privilege particularly important. An agent that can perform ten different tasks does not necessarily need unrestricted access to everything required for those tasks at all times. A more defensible approach is to make permissions task-specific, time-bound and observable, with access determined by the agent’s intended function rather than by the maximum level of access that might make deployment easier.
This is also why agent identity should increasingly be treated as part of enterprise identity and access management rather than as a separate AI governance problem. Australia’s updated system-access guidance, for example, explicitly notes that controls for identifying, authenticating, authorizing and monitoring users also apply to non-human entities such as services, applications, workloads and AI agents.
Machine-Speed Attacks Change the Defensive Equation
The second major challenge is speed. Human attackers already use automation for reconnaissance, credential theft and exploitation, but agentic AI can connect those activities into more adaptive workflows. Instead of using AI to help with one stage of an attack, threat actors can increasingly use multiple agents to perform different tasks in parallel, allowing reconnaissance, exploitation, data processing and other activities to proceed with considerably less human intervention.
Anthropic’s September 2026 threat intelligence report describes this transition as a move from AI acting as an assistant toward AI acting as an orchestrator. Its investigations found operations in which multi-agent frameworks were used for activities including reconnaissance, exploitation and data exfiltration, with some workflows running for extended periods and maintaining campaign context across sessions.
This creates an uncomfortable asymmetry for defenders. An enterprise might have strong controls across its endpoint, network, identity and cloud environments, yet still struggle if its detection and response processes depend heavily on humans reviewing alerts sequentially while attackers automate reconnaissance and decision-making. Google Threat Intelligence Group has described this as a reduction in human-in-the-loop latency, effectively compressing the traditional window available to defenders.
The response cannot simply be to deploy more AI tools. Security teams need better visibility into what autonomous systems are doing, which resources they are touching and why they are taking particular actions.
Agent Observability Needs to Become a Security Control
Traditional application monitoring is primarily concerned with whether a system is functioning correctly. Agent observability needs to go further because understanding the outcome of an action may not be enough to determine whether the action itself was appropriate.
Security teams increasingly need to establish an audit trail around the complete agent workflow, including:
- Which agent initiated an action?
- Which user, application or system authorized it?
- What data did the agent access?
- Which tools and APIs did it invoke?
- What instructions or external inputs influenced its behavior?
- Did its actions deviate from its normal operating pattern?
- Did it attempt to access resources outside its assigned scope?
- Which downstream systems were affected?
This becomes particularly important because an agent can execute a sequence of individually legitimate actions that becomes suspicious only when viewed as a whole. A single API call may look completely normal, while dozens of calls across several systems followed by an unusual data transfer could indicate that an agent’s permissions or behavior have been abused.
That means enterprise security teams will increasingly need behavioral visibility across the entire agent workflow, rather than relying exclusively on individual application, network or endpoint controls.
Governance Cannot Remain a Policy Document
As agentic AI adoption accelerates, many organizations will respond by creating acceptable-use policies and AI governance frameworks. Those are useful foundations, but policy alone cannot prevent an agent from taking an unsafe action.
The controls need to exist where the agent actually operates. Enterprises should consider guardrails around identity, permissions, connectors, data access, tool invocation and runtime behavior, while high-impact actions may require explicit human approval. The important distinction is that not every action needs the same level of oversight.
An agent that summarizes internal documents does not necessarily need the same controls as an agent capable of changing production infrastructure or initiating financial transactions. Organizations therefore need to establish which actions can be autonomous and which actions require escalation, based on potential impact rather than simply on whether the workflow involves AI.
This approach also avoids one of the less practical responses to agentic AI: putting a human in the loop for every decision. Excessive approval requirements can remove much of the efficiency that makes agents valuable in the first place. The objective should instead be controlled autonomy, where the system can move quickly within clearly defined boundaries and escalate when it reaches a high-risk decision.
Security Architecture Needs to Evolve With Agentic Adoption
The rise of agentic AI does not make existing cybersecurity controls obsolete. Zero-trust principles, identity governance, endpoint protection, application security, data security and network controls remain fundamental. What changes is how these controls need to interact when autonomous systems begin operating across multiple enterprise environments.
AI agents create another layer of activity across the enterprise. They can cross application boundaries, consume information from multiple data sources and invoke services on behalf of users or other systems. Security architecture therefore needs to recognize the agent as an operational entity rather than treating it simply as another feature inside an application.
Organizations deploying agents should maintain clear inventories of where agents exist, what they can access, which identities they use, what tools they can invoke and what decisions they are permitted to make. Without that visibility, enterprises risk creating a form of agentic shadow IT in which autonomous systems become embedded in business processes without security teams having a complete understanding of their capabilities or dependencies.
The challenge becomes particularly significant when agents are connected to third-party services. A seemingly low-risk agent may inherit risk from a connector, plugin, external data source or software dependency. Google’s September 2026 AI Risk and Resilience report notes that attack vectors are expanding from direct prompts toward indirect prompt injection and targeted AI supply-chain compromise, illustrating why the security boundary cannot stop at the model.
The Enterprise Question Is No Longer Whether to Adopt Agents
For many organizations, the question of whether AI agents will become part of enterprise operations is already becoming less relevant. Agents are moving into software development, customer service, IT operations, security operations, finance and other business workflows because they can coordinate tasks that previously required people to move between multiple applications and systems.
The more important question is whether enterprises can create an environment in which autonomous systems are useful without becoming uncontrollable. That requires a shift in how organizations think about AI security. Securing the model remains important, but it is only one part of the problem. The agent’s identity, permissions, tools, data, memory, connectors and runtime behavior all need to be considered as part of the security architecture.
Cybersecurity teams also cannot assume that an agent will always behave like conventional software. Agents can interpret instructions, adapt their actions and respond to changing information in ways that are difficult to capture through static rules alone. As a result, security programs will need to combine conventional preventive controls with stronger identity management, behavioral monitoring, runtime enforcement and clear accountability for autonomous actions.
The organizations that address these requirements will not necessarily be the ones with the most restrictive AI policies. They will be the ones that can establish enough visibility and control to let agents operate with clearly defined boundaries while preserving the speed and flexibility that make them valuable.
The agentic enterprise is arriving quickly. The security perimeter needs to evolve with it.
Key Takeaways
- Agentic AI expands the enterprise attack surface beyond the model itself. Agents can access data, invoke tools, call APIs and interact with business applications, creating new pathways for attacks to move through an organization.
- Identity and permissions are becoming central AI security concerns. Every autonomous agent needs clearly defined, least-privilege access, with permissions that can be monitored, restricted and revoked.
- AI-enabled attacks can operate at machine speed. As attackers use increasingly autonomous workflows for reconnaissance, exploitation and credential theft, organizations may have less time to detect and respond.
- Agent observability needs to become a security control. Security teams need visibility into an agent’s actions, data access, tool usage, instructions and downstream effects—not just whether the application is functioning.
- AI governance must move from policy to runtime controls. Enterprises need to determine which actions agents can perform autonomously and which require human approval based on their potential business impact.
- Securing agentic AI requires an architectural approach. Model security alone is insufficient; identity, data, connectors, APIs, memory, tools and runtime behavior all need to be considered as part of the security boundary.