AI agents change the unit of security
Enterprise AI agents are no longer limited to drafting text. They can retrieve records, call business APIs and carry out multi-step workflows on a user’s behalf. That changes the security question: not only “who can sign in?” but also “which agent identity can reach which tool and data, under what conditions, and with what ability to change the system?”
A capable agent can amplify both useful work and an unsafe instruction. A malicious web page or untrusted tool response may influence the model; if the agent can also reach sensitive databases or write-enabled APIs, a single decision can cross several trust boundaries before a person notices. AI agent security governance must therefore make access visible, bounded, verifiable and reversible.
Why response time now matters as much as patch quality
Akamai’s 2026 Speed, Scale, and Nonhuman Identity: The Agentic Threat Landscape report describes two pressures on defenders: autonomous workflows blur traditional privilege boundaries, while AI-assisted discovery can shorten the time needed to find and chain software weaknesses. In the report, the average number of daily API attacks per surveyed organization rose from 121 in 2024 to 258 in 2025, a reported increase of 113%; 87% of surveyed organizations experienced an API-related security incident in 2025. Akamai also reports that more than 40% of enterprise users had installed AI browser extensions and that more than 6% of chatbot conversations contained sensitive information. These figures describe Akamai’s research and should not be read as universal prevalence rates.
Anthropic describes Project Glasswing as a defensive initiative in which participating organizations use Claude Mythos Preview to help secure critical software. Anthropic says the model has identified thousands of vulnerabilities and that access is provided through a gated research preview. Those are the project developer’s public claims, not proof that every organization faces the same attack capability. They nevertheless reinforce a practical point: security teams should not assume that vulnerability discovery, validation and exploitation always fit a conventional human patch cycle.
Patching remains essential, but it cannot be the only immediate control. When a vulnerable service is reachable and consequential, teams may need to reduce exposure while a durable fix is being prepared and tested.
Inventory the agent’s identity, tools and data paths
Start with a register that answers operational questions: Which agents, service identities, MCP servers, browser extensions, external models and APIs are in use? Who owns each component? Which systems and data can it read or change? Where are its credentials stored, how long do they last, and how can they be revoked?
The Model Context Protocol (MCP) gives models a standardized way to connect with tools and data sources, but every connection also introduces a trust decision. Akamai’s report discusses risks involving tool descriptions, context manipulation and interactions across servers. Treat each MCP service as a managed dependency: record its owner and version, review its code and configuration, restrict network reachability, and retain auditable tool-call logs. Avoid placing untrusted external content and high-trust internal tools in a context where the agent can freely chain them together.
Apply least privilege to machine identities
Give an agent only the access required for its assigned task. Prefer read-only scopes, short-lived credentials and task-specific identities. Separate development, test and production environments. Put a second check in front of consequential writes, payments, account changes, bulk deletion and production configuration updates.
Logs should connect the acting identity to the request, tool, target object, authorization basis and outcome. Recording only the model’s natural-language explanation is not an audit trail. Teams should be able to reconstruct what the agent did, which credentials it used and which human or policy allowed the action.
Mitigate exposure while patches are prepared
Prioritize vulnerabilities by reachability, exploitability, asset criticality and business impact—not by a single score alone. If a critical service cannot be patched immediately, API gateway rules, runtime protections, segmentation or temporary interface restrictions can reduce exposure while the root-cause fix is developed. Each temporary control needs an owner, an expiry date and a clear removal criterion so that an emergency exception does not become permanent.
Agent security tests should go beyond prompt-injection demonstrations. In an isolated environment, simulate hostile web content, malformed tool responses, credential exposure and dependency changes. Verify whether the system crosses trust domains, accesses data outside its task or performs an irreversible action without authorization. Define repeatable acceptance conditions—for example, unauthorized writes are rejected, high-risk calls require approval, and revoked credentials stop working.
Match autonomy to verifiability
More autonomy is not automatically better. The more observable and reversible an action is, the more suitable it may be for automation. Actions involving sensitive information, money, production systems or legal commitments should require explicit authorization and human oversight. A convincing model explanation is not proof of permission.
Organizations can define tiers: allow low-risk retrieval and formatting to run automatically; require confirmation before external messages or data changes; and require strong authentication, approval, time-limited access and post-action review for privileged or broad-impact tasks. Every automated workflow should have a stop mechanism, a rollback plan and an escalation path.
A practical checklist for security leaders
- Maintain one inventory of agents, service identities, MCP services, APIs and AI-enabled browser extensions, with named business and technical owners.
- Map each agent’s identity-to-tool-to-data-to-action path, including read/write scopes, trust levels and sensitive-data touchpoints.
- Enforce least privilege, isolate connections across trust levels, and regularly remove orphaned tokens and service accounts.
- Monitor key APIs and consequential actions at runtime; require approval for high-risk operations and use revocable, short-lived authorization.
- Run vulnerability mitigation and patching in parallel where exposure warrants it; rank work by real reachability and business impact, and time-box temporary exceptions.
- Test prompt injection, unexpected tool output, cross-domain access and rollback in an isolated environment; retain evidence and retest fixes.
Build governance into the pilot
AI agent security is not a single model filter. It is a control loop spanning identity, APIs, data, runtime enforcement and human accountability. Inventory the access paths first, define which tasks may run autonomously, and specify the approval boundary for consequential actions. Then use logs and repeatable tests to demonstrate that the controls work.
DELine can help organizations map AI agent and MCP exposure, assess identity and API permissions, design isolation and runtime controls, and define a verifiable governance process for pilots. Visit DELine or contact our team to discuss an approach suited to your environment.
